In my line of work I use msconfig a lot and I'm wanting to create a tool with various buttons on it so I can easily access my most commonly used programs. I'm using the Win32API to create the GUI and buttons, however I am having trouble getting msconfig to run. In my program I have
void callMsconfig()
{
ShellExecute(NULL,(LPCWSTR)L"open", (LPCWSTR)L"C:\\Windows\\System32\\msconfig.exe", NULL, NULL, SW_SHOWDEFAULT);
}
and an action statement so when the button is pressed the function is called. I've tried replacing ShellExecute() with system() and CreateProcess(). I've also replaced "open" with "runas" and the most I've gotten is the error saying C:\Windows\System32\msconfig.exe cannot be found when I know it is there because I've checked. What am I doing wrong? I'm using Windows 10 Home if that helps any.
If you have created a 32bit app that is running inside of the WOW64 emulator on 64bit systems, the C:\Windows\System32\ folder is silently redirected by WOW64 to the C:\Windows\SysWOW64\ folder, which does not have an msconfig.exe file. You need to account for that. Either create a 64bit executable, or use the Sysnative alias in 32bit code that runs inside of WOW64. Sysnative is documented on MSDN:
File System Redirector:
32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. This mechanism is flexible and easy to use, therefore, it is the recommended mechanism to bypass file system redirection. Note that 64-bit applications cannot use the Sysnative alias as it is a virtual directory not a real one.
Try something more like this:
#include <shlwapi.h>
void callMsconfig()
{
BOOL IsWow64 = FALSE;
WCHAR szCmdLine[MAX_PATH] = {0};
IsWow64Process(GetCurrentProcess(), &IsWow64);
if (IsWow64)
{
GetWindowsDirectoryW(szCmdLine, MAX_PATH);
PathAppendW(szCmdLine, L"Sysnative");
}
else
{
GetSystemDirectoryW(szCmdLine, MAX_PATH);
}
PathAppendW(szCmdLine, L"msconfig.exe");
ShellExecuteW(NULL, NULL, szCmdLine, NULL, NULL, SW_SHOWDEFAULT);
}
However, do note that if UAC is enabled and you try to launch msconfig.exe from a 32bit process running inside of WOW64, the 32bit process MUST be running elevated or else ShellExecute() (and CreateProcess()) will fail to find the file correctly. I don't know why, but that is how it works. UAC Elevation is not required when launching msconfig.exe from a 64bit process.
If you don't want to elevate your entire program, you will have to make it launch a separate elevated process that can then launch msconfig.exe. You could just have the program launch a second copy of itself with a command-line parameter so it knows to just launch msconfig.exe and then exit itself. To launch an elevated process, you can use ShellExecute() specifying the runas verb.
Related
I have the following C code that should run the default Windows program changepk.exe with an UAC prompt
ShellExecute(NULL, "runas", "C:\\Windows\\System32\\changepk.exe", 0, 0, SW_SHOWNORMAL);
(Side note that the output of the ShellExecute is 2).
However, when I try to execute the 'changepk.exe' with these lines nothing happens at all, but for 'notepad.exe' instead of 'changepk.exe' it works and gives me an UAC prompt. What could be the issue here and what are the potential ways around it?
Error 2 is ERROR_FILE_NOT_FOUND. Make sure that changepk.exe actually exists on your machine at that path.
More importantly, if your app is a 32bit EXE running on a 64bit Windows, then you are likely encountering the File System Redirector at work, which will redirect "C:\\Windows\\System32\\..." to "C:\\Windows\\SysWOW64\\..." for 32bit processes.
If that is the case, try using WOW64's sysnative alias to reach the 64bit System32 folder from a 32bit app, eg:
ShellExecute(NULL, "runas", "C:\\Windows\\Sysnative\\changepk.exe", 0, 0, SW_SHOWNORMAL);
Or, you can disable the redirector temporarily by using Wow64DisableWow64FsRedirection(), eg:
PVOID oldValue;
Wow64DisableWow64FsRedirection(&oldValue);
ShellExecute(NULL, "runas", "C:\\Windows\\System32\\changepk.exe", 0, 0, SW_SHOWNORMAL);
Wow64RevertWow64FsRedirection(oldValue);
The reason why NotePad works is because a 64bit Windows provides both 32bit and 64bit versions of NotePad, so you end up running the correct one regardless of where "C:\\Windows\\System32\\notepad.exe" actually maps to.
On Windows I normally create a Windows Desktop Application, this is because console applications display a brief black box on the screen.
I am using CodeBlocks on Linux Mint, how could I do the equivalent of the above but on Linux?
I do not want to hide the terminal window after it has been displayed.
Linux does not have the same "subsystem" concept as windows: there is no difference or separation between console and desktop applications. When you start an application on Linux, it will not open a console window, unless the programmer explicitly programmed it to open one.
If the application writes anything to stdout or stderr, what happens with that depends on how exactly the application got started. By default, the application inherits the stdout and stderr of its parent process. If the application is being started from a terminal, the output will be visible on the terminal. If the application was started by the desktop environment from a menu entry, the output may go to a log file or it may be lost.
If you see a terminal window open when you run your program from the IDE, that's something that the IDE is doing for you, it's not your application. If it bothers your, I would think that the IDE has a way to disable this behavior in settings.
Look into QT. It is a GUI framework that works on Linux.
You can write your code without creating a main window (or maybe you have to have a main window but it can be always hidden... it's been a while since I've used it).
Be aware though, that you may run into usability issues with this type of design... the user has no way of knowing if your app was launched or if it succeeded, when it's completed, etc.
The simple way is to use (e.g.) xterm [or gnome-terminal] to get a terminal window.
Then, invoke your program from the shell [manually]:
/path_to_my_program
You may be able to configure codeblocks to do this for you.
Or, you could add some code that holds the default window open:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
int main()
{
pid_t pid = fork();
if (pid != 0) {
waitpid(pid,NULL,0);
while (1) sleep(1);
}
long double n;
n=5;
printf("n= %Lf\n",n);
return 0;
}
UPDATE:
The invocation command can be controlled from: Settings -> Environment -> General Settings
The default is to invoke in an xterm sub-window [popup]. You may be able to change the settings to (re)use an existing [terminal] window.
Note that [a codeblocks program] cb_console_runner is used. You may be able to replace this with something more to your liking.
I do not want a GUI nor a terminal popup...
You'll need some sort of terminal to run the command in. This could be a script that diverts stdin/stdout/stderr as appropriate [and suppresses the invocation of a sub-window], so you'll have to experiment a bit.
As I mentioned above, you can just open a terminal window outside of codeblocks and then run the command manually inside it. Technically, this is not a popup. But, you lose the [automatic] debugger invocation.
I am currently writing a DLL injection program (C++) which adds specified certificate to certmgr.exe.
I wrote the whole thing connected with injection (OpenProcess, etc.). When I am executing it - attached to svchost - my DLL is not loading since it seems that it doesn't have such rights as svchost has.
How can I pass rights?
In my DLL file, I am using system("certmgr.exe -add ....") and I think this might be the problem because the command line opens as a separate program (as if I opened it via start).
Use ShellExecute() using the "runas" argument, which will make it try to run as administrator
ShellExecuteA( NULL,
"runas",
"c:\\windows\\certmgr.exe",
"-add ....",
NULL,
SW_SHOWNORMAL
);
I want to make a console application in C++ and then when the information is displayed, close the console and run in background. Is this possible? Is another way to do that? Python maybe?
You will have to either close the console window while the process is still running, which is system dependent, or start another process, and even though the standard library offers the system function to do that, its argument is a system dependent command line.
So the upshot is: this is system dependent.
In Windows the full-version of Microsoft's Visual Studio IDE has always, as far back as I can remember, used a peculiar approach for this, with two executable files devenv.com and devenv.exe. The former is a console subsystem executable, which by default runs the latter, which is a GUI subsystem executable:
[C:\]
> where devenv
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.com
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe
[C:\]
> _
The basic idea here is that for historical reasons the command interpreter's search for an executable finds the .com file first, so the command devenv just works, either for starting the IDE or just getting the help text via the /? option.
Yes, this is possible with a small variant:
fork another process. But this is heavily system dependent:
posix/linux allow to simply clone the process;
windows requires new process to be created from an executable. You then have to communicate the state. Its less trivial as explained in this article, in the paragraph on porting fork())
then exit the program (it's the only way to give back control to the console).
On Windows use ShowWindow(FindWindowA("ConsoleWindowClass", NULL), false) to hide the console window. It will still be running in the background and is not visible on the taskbar.
However you will have to run a task manager like Taskmgr.exe to find it and shut it down.
#include <windows.h>
#include <iostream>
using namespace std;
int main () {
cout<<"Some information is displayed.. \n\n";
Sleep(5000);
cout<<"wait.. the console is going to hide and run in background.. \n";
Sleep(5000);
ShowWindow(FindWindowA("ConsoleWindowClass", NULL), false);
while(true) {
// Do your hidden stuff in here
}
return 0;
}
The other answers given here overcomplicate things. The most easy way to close the console window in Windows is to simply detach from it. Once the last user of a console window datached, the console window gets closed.
If you start a program from a CLI (e.g. cmd.exe) then this CLI is also attaches to to the console and thus the console window will not close.
Anyway, detaching from a console is as simple as calling
FreeConsole();
… done!
Also you can attach to a newly created console at any time using AttachConsole, which takes a process ID. Now in a CLI situation the parent will usually be the CLI shell, so you may want to attach to the console of that.
From wxWidgets application I try to run installer, made with NSIS, in silent mode (/S flag). Got this error:
Execution of command: "C:\somecommand.exe" failed (error 0: Операция
завершена успешно / Successful).
When I run installer silently from command line, I got UAC popup, but when I execute it from wxWidget application I got only this error. And what this error means? Like "Fatal Error: All is fine".
In NSIS script I have RequestExecutionLevel admin, because I really need it to have ability to install program in directories like Program Files.
To start a Windows application that requires elevation you must use ShellExecute and not CreateProcess, CreateProcess will just fail with a elevation required error.
I would imagine that wxLaunchDefaultApplication uses ShellExecute internally but it seems a bit risky to rely on that so you might as well use a ifdef:
#ifdef __WINDOWS__ // __WXMSW__
ShellExecute(0, 0, pathtoexe, parameters, 0, SW_SHOW);
#else
wxExecute(something);
#endif