There are many users struggling with UAC prompts opening in background instead of foreground. Well, I want to do exactly the opposite, ie having the UAC prompt flash on the taskbar and waiting for my attention instead of dimming my whole screen and messing my workflow.
Here's my setup: I'm working on a Win7 x64 machine, and I placed this link in my Startup folder:
C:\CLUs\chp.exe "apps.bat"
chp.exe is an utility that loads batch files without showing the command prompt.
apps.bat calls several unelevated programs (easier to manage apps in this way rather than putting a bunch of links in Startup). The last line of such bat is
elevate chp "elevapps.bat"
elevate.exe is an utility that, as the name says, elevates whatever is called with issuing an UAC prompt. And, clearly, elevapps.bat contains another bunch of programs that require admin rights to start properly.
Now, for a number of reasons I'd like the UAC prompt to start minimized/in background. Ie, once I've logged in Windows, all I want to see is the taskbar containing the flashing icon of the UAC, but no dimmed screen.
Is this possible with batch files? All I know is that UAC "smartly" detects whether it is stealing focus or not and (doesn't) show up accordingly. And clearly during the startup there's nothing to steal focus from, so looks like I'm having no luck. However it also seems that badly coded software (namely not assigning HWNDs somewhere, see here and here) precisely produces this effect. Is there a way to reproduce this "bug" (I'd call it a feature, in my case) with some code in a batch file? Also using a third party utility would be fine, however I'm not a programmer.
I solved the problem by using winapiexec.exe, an utility that allows (as per site) to run WinAPI functions through command line parameters.
winapiexec shell32.dll#ShellExecuteW NULL "runas" "chp" "elevapps.bat" NULL 7
Related
I'm trying to make a C program that modifies my host file, but I can't just straight up open the file with the program, because Windows blocks it. Is there any way that I can make the program request administrative privileges within the code, or any script I can use to start the program in admin mode?
Right clicking is a solution that allows you to run any program with Administrator privileges. That includes ticking the box in "Properties".
On Windows 7 and later, you can also rename your program so that its name contains setup (like hosts_setup.exe), and it'll automatically be run in Administrator mode (brings up the UAC prompt) if double-clicked in Explorer. Note this only works from double-clicking in Explorer.
You can also take a look at How can I run a child process that requires elevation and wait? . It calls WinAPI and is a fairly native approach. The best solution is to add it in menifest so your program requests Admin at startup.
Shoot, okay, seconds after posting this question, I found a solution. It turns out that you can right click the executable, click properties, and on the compatibility tab, select "Run this program as administrator". Just in case anyone else needed this information.
I was just wondering if there is a code that can remove the "close" button on a batch file. (The minimize and expand buttons isn't important so it is ok if they will be disabled or will stay enabled) That is all. I can't seem to find any answer anywhere.
Thanks.
A batch file is nothing more that a script that another program must execute.
When you double-click a .bat file in Explorer, cmd.exe launches and "opens" the file, running the script. So your question is: can you remove the close button from cmd.exe? Good luck.
You don't want to be doing that. You should make your script NOT show a window to begin with.
If the window is shown, a user can always Ctrl + C to stop the script mid-stream.
There is a number of ways you can make the window hidden (also called "running a script silently"). See the following links:
Run a completely hidden batch file
Solved: HowTo run a batch file without it showing
Eric Helps
Or just google for "batch file silent" or "batch file hide console".
Just a side note: if you have seen this behavior before, chances are that it is not a batch file, but another programming language, and probably not using cmd.exe. C# can let you make a console program app which you can manipulate the title, but even still you cannot change the control buttons on the window. It is simply not within c# or a batch file's scope.
For years now my Windows C tagging/scoping solution has almost worked. I can build the filelist, build the tags (via Exuberant Ctags) for vim/gvim navigation, build cscope.out, and tag around within gvim.exe windows I launch by clicking on C source files.
The final piece that eludes me is that I can't seem to get cscope in cmd.exe to launch my editor when I select an item. I made sure gvim.exe is in my Path environment variable. I made sure the CSCOPE_EDITOR environment variable is set (more on that below). But when I select a line item from within cscope the editor is not launched. Instead I get one of the two following failures:
If CSCOPE_EDITOR is either gvim.exe -f or "gvim.exe -f" then I see that printed at the top of the cmd.exe window followed by the line offset and the filename (e.g. "gvim.exe -f +72 myfile.c") and then it quickly returns to cscope without the editor ever popping.
If CSCOPE_EDITOR is gvim.exe (without the -f option) then a gvim.exe process is kicked off (I see it in Windows Task Manager under Processes) but it never comes to the foreground as an application. Furthermore, the cscope window in cmd.exe goes blank and is unresponsive until I manually kill the gvim.exe process that was spawned.
For reference:
cscope -V returns "cscope: version 15.8a" and was downloaded from this site: http://code.google.com/p/cscope-win32/
My version of gvim.exe is 7.3 which the latest available from http://www.vim.org/
Also, I have tagged this post with "C" because, while this is not a C language question, cscope and ctags are primarily used for C programming and thus I think the C tag is relevant. (Thought I'd point that out before someone comes along and removes the tag and says this isn't a C question, since C programmers are the most likely people to have the answer.)
With help from #mattn and #mMontu and a lot of trial-and-error and an ugly but simple hack I finally have this working. Here are the problems I encountered:
cscope-win32 does not handle spaces in the EDITOR or CSCOPE_EDITOR environment variables. I tried every space-escape trick I could think of (single-quotes, double-quotes, backslash escapes) and nothing worked.
When gvim.exe is successfully launched by cscope-win32, if that gvim.exe tries to add the same cscope.out database (via cs add cscope.out) the add command hangs. If the add is part of a vimrc file then the editor will hang during opening (with the gvim.exe and cscope.exe processes starting but the application window never appearing). If the add is done after the editor window opens then the window will hang. This appears related to multiple cscope-win32 processes being attempted in the same process tree, but I have no actual proof of that.
Here's my solution to the problem. Like I said, it is an ugly but simple hack.
Create a wrapper batch file. I named mine gvim_cscope.bat. Make sure it is in a directory that exists in your PATH environment variable. You can verify this in a cmd.exe shell by calling "where gvim_cscope.bat".
Edit the batch file and add your editor command but precede it with the windows start command. For example, my batch file contains the following:
start gvim.exe %*
Create/Update your CSCOPE_EDITOR environment variable to be "gvim_cscope.bat". In case you've never modified a Windows environment variable before, you can get to them (on Windows 7 anyway) via Start -> right-click Computer -> Properties -> Advanced System Settings -> Environment Variables.
That's all I needed to get things working. Open a new cmd.exe window (so the updated environment variable is pulled in) and open cscope.exe and everything works. I am able to pop multiple gvim.exe windows from within cscope.exe, each with its own connection to the cscope.out database. The first problem is avoided by using the wrapper batch file (no more spaces in the command) and the second problem is avoided by using the windows start command so that gvim.exe is started as a separate process.
Thanks for the help #mattn and #mMontu. So nice to have things working right!
I know this is not ideal, but my constraint is that I have a legacy application written in Clipper.
I want to launch a new, WinForms/WPF application from inside the application (to ease transition). This legacy application written in Clipper launches using:
SwpRunCmd("C:\MyApp\MyBat.bat",0)
The batch file contains something like this command:
C:\PROGRA~1\INTERN~1\iexplore "http://QASVR/MyApp/AppWin/MyCompany.MyApp.AppWin.application#MyCompany.MyApp.AppWin.application"
It is launching a WinForms/WPF app that is we deploy via ClickOnce. Everything has been going well until we introduced WPF into the application. We were able to easily launch from the legacy application.
Since we have introduced WPF, however, we have the following behavior. If we launch via the Clipper application first, we get an exception when launching the application. The error text is:
The type initializer for 'System.Windows.FrameworkElement' threw an exception.
at System.Windows.FrameworkElement..ctor()
at System.Windows.Controls.Panel..ctor()
at System.Windows.Controls.DockPanel..ctor()
at System.Windows.Forms.Integration.AvalonAdapter..ctor(ElementHost hostControl)
at System.Windows.Forms.Integration.ElementHost..ctor()
at MyCompany.MyApp.AppWin.Main.InitializeComponent()
at MyCompany.MyApp.AppWin.Main..ctor(String[] args)
at MyCompany.MyApp.AppWin.Program.Main(String[] args)
The type initializer for 'System.Windows.Documents.TextElement' threw an exception.
at System.Windows.FrameworkElement..cctor()
The type initializer for 'System.Windows.Media.FontFamily' threw an exception.
at System.Windows.Media.FontFamily..ctor(String familyName)
at System.Windows.SystemFonts.get_MessageFontFamily()
at System.Windows.Documents.TextElement..cctor()
The type initializer for 'MS.Internal.FontCache.Util' threw an exception.
at MS.Internal.FontCache.Util.get_WindowsFontsUriObject()
at System.Windows.Media.FontFamily.PreCreateDefaultFamilyCollection()
at System.Windows.Media.FontFamily..cctor()
Invalid URI: The format of the URI could not be determined.
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
at System.Uri..ctor(String uriString, UriKind uriKind)
at MS.Internal.FontCache.Util..cctor()
If we launch the application via the URL (in IE) or via the icon on the desktop first, we do not get the exception and application launches as expected.
The neat thing is that whatever we launch with first determines whether the app will launch at all. So, if we launch with legacy first, it breaks right away and we can't get the app to run even if we launch with the otherwise successful URL or icon. To get it to work, we have to logout and log back in and start it from the URL or icon.
If we first use the URL or the icon, we have no problem launching from the legacy application from that point forward (until we logout and come back in).
One other piece of information is that we are able to simulate the problem in the following fashion. If we enter a command prompt using "cmd.exe" and execute a statement to launch from a URL, we are successful. If, however, we enter a command prompt using "command.com" and we execute that same statement, we experience the breaking behavior.
We assume it is because the legacy application in Clipper uses the equivalent of command.com to create the shell to spawn the other app. We have tried a bunch of hacks like having command.com run cmd.exe or psexec and then executing, but nothing seems to work.
We have some ideas for workarounds (like making the app launch on startup so we force the successful launch from a URL, making all subsequent launches successful), but they all are sub-optimal even though we have a great deal of control over our workstations.
To reduce the chance that this is related to permissions, we have given the launching account administrative rights (as well as non-administrative rights in case that made a difference).
Any ideas would be greatly-appreciate. Like I said, we have some work arounds, but I would love to avoid them.
Thanks!
It sounds like the Presentation Font Cache service has trouble starting when the app is launched in this way.
If you have control over the client environment, you could try setting the Windows Presentation Font Cache startup to automatic instead of manual.
This is a shot in the dark made with incomplete information:
command.com and cmd.exe are quite different. AFAIK, command.com exists for legacy compatibility, so applications you run from it will run differently. I can't test anything to complete my post because I believe that command.com runs in 16-bit mode and 64bit versions of Windows (on which I'm running) don't support that mode anymore so no more command.com for me.
That being said, there should be no difference when trying to run 32-bit applications (including managed applications).
I'm not aware of what are the limitations of your environment, but some things you may try are:
Rename you .bat into .cmd to make sure it starts with cmd.exe rather than command.com
Make your .bat start the program using the start console command
Have a non-WPF program to invoke your WPF one with a more sane environment
The problem is that the windir environmental variable is not set when using command.com.
So, in your case, adding the line set windir=C:\Windows to the beginning of the bat file will solve the problem (assuming that you have your Windows instalation in C:\Windows.
An additional issue might be that the host application is running command.com in compatibility mode. The best is to list all the environmental variables after running cmd.exe (using the set command) and comparing it to the output of the set command that you set in your bat file
I'm not sure if this is technically a Kiosk, but it's basically the same idea. I have a program that runs full screen all the time from boot to shutdown to control a machine that the computer is hooked to.
Right now I just have a shortcut to the exe in the Startup folder so it starts when the system boots up and logs in. Is there any better way to do this? I'd really like the user to never see the Windows environment (just the windows loading progress bar on boot) if at all possible, but I'm guessing that's not possible.
Just thought I'd ask and see if there is a better way to do this than putting it in the startup folder?
The best option is to use Windows Embedded. This gives you much more control over the shell, and what is run and installed with the system.
If you have to do this with a consumer OS, you can try to bypass the login prompts to auto-login your user, and have your program setup in the registry to startup. Disable any other services you don't need. That will minimize the time the shell is displayed (but it's very difficult to remove it).