I decided to create applications direct with Notepad + GCC Compiler (and the entire Mingw environment).
Well I started by creating a simple Win32 application (a simple window). The file is only 4 Kb (which, with an IDE like C:B or VS is about 8 kb.
Anyway, my problem is that the window is displayed but also a window console. Well, I don't want the console to appear but only the GUI window. I think this is achieved by creating manifest files or something like that, of which I don't know much about, as this is the first time I am trying this. How do I tell GCC that it shouldn't create a console window - just a GUI window?
Thanks!
You need to create an executable that targets the GUI subsystem rather than the console subsystem. In the MS tools the normal way to indicate that is to use a different form of main function:
int WINAPI WinMain(HINSTANCE hThisInstance,
HINSTANCE hPrevInstance,
LPSTR lpszArgument,
int nCmdShow)
I believe that mingw supports the same convention.
Yeah, -mwindows can solve the problem. And I found another option, passing -Wl,--subsystem,windows when using gcc to compile. Both of them are OK.
I found out how to do it. For anyone having the same question: use -mwindows in your command line, when compiling the code with GCC. Thanks!
Related
I've got a Windows application with a GUI written in Rust and winapi. Despite its GUI, it behaves like a console application. When the exe file is started, a Command Prompt window pops up, and the application is run from it. This is not what I want; a main window should open instead, as in all real desktop apps. How can I achieve this goal in Rust with winapi?
I've investigated some options. You can develop Windows desktop applications using Tauri or gtk-rs, but both of these techniques have drawbacks when used for Windows apps. More options may be found here. I've also tried the windows-rs samples available on the internet, but they're all console apps with a graphical user interface, which isn't what I'm looking for.
I also note that C++ desktop applications use the function int APIENTRY wWinMain(...) as the entry point while console applications use int main(...), and wWinMain doesn't seem available in rust winapi.
Whether the system allocates a console for a newly created process is controlled by the Subsystem field in the Windows-specific optional PE header. The field is populated through the linker's /SUBSYSTEM command line option. The only relevant arguments for desktop applications are CONSOLE and WINDOWS. The former instructs the system to allocate a console on launch, whereas the latter won't.
You can instruct the linker to target the WINDOWS subsystem from Rust code by placing the per-module
#![windows_subsystem = "windows"]
attribute (see windows-subsystem) inside the main module of your application.
You'll find an example of this in the core_app sample of the windows crate.
This is the most convenient way to target the WINDOWS subsystem. You can also explicitly pass the linker flag along, e.g. by placing the following override into .cargo/config.toml:
[build]
rustflags = [
"-C", "link-arg=/SUBSYSTEM:WINDOWS",
]
This may or may not work, depending on the linker you happen to be using. Since the linker isn't part of the Rust toolchain, making sure that this works and has the intended effect is on you.
A note on the entry point's function name: It is irrelevant as far as the OS loader is concerned. It never even makes it into the final executable image anyway. The PE image only stores the (image-base-relative) AddressOfEntryPoint, and that symbol could have been named anything.
The concrete name is only relevant to the build tools involved in generating the respective linker input.
More info here: WinMain is just the conventional name for the Win32 process entry point. The underlying principles apply to Rust just the same, particularly the aspect that the user-defined entry point (fn main()) isn't actually the executable's entry point.
I am currently working on WinAPI Gui application under MinGW. In debug version I want to open console and redirect stdin/stdout streams to it, so I can see diagnostic messages being printed in debug. I followed this article:
http://justcheckingonall.wordpress.com/2008/08/29/console-window-win32-app/
It works under Visual Studio, but when compiled on MinGW it spits this message, even if stdio.h is included:
error: '_fdopen' was not declared in this scope
Arguments for MinGW:
mingw32-g++.exe -march=pentium4 -std=c++11 -w -fpermissive -fno-strict-aliasing -D__STDC_CONSTANT_MACROS -D_WINDOWS -DUNICODE -D_UNICODE -g -D_DEBUG
I've googled a lot and it seems to be a bug in MinGW, there is no _fdopen defined in header if C++11 is used. Since I rely on C++11 features, I cannot turn it off, so I am looking for alternatives - is there any way to open console on Windows and redirect stdin/stdout that does not rely on fdopen? If not, are there any other solutions to my problem?
I tried also to manually declare _fdopen (or fdopen), but then it didn't pass the linking phase
MinGW version: 4.7.1
From some brief research, it is my understanding that you should be able to use _fdopen/fdopen in GNU C++11 with the right configuration settings (i.e., by enabling POSIX functions) but that there is a long-standing bug in the Windows implementations. Whether you can directly work around this issue presumably depends on which runtime library you're using.
However, there are various other potential workarounds depending on the scenario:
In your particular case, since you're making the decision at build time, you can simply build the debug version as a console application and let Windows do the work.
It should be possible (again, depending on the runtime library) to configure the build so that some code of yours runs before the runtime library initialization; hopefully, if the console is already present the runtime library will import the standard streams during initialization.
You should be able to open CONIN$ and/or CONOUT$ using fopen so as to obtain FILE objects directly, rather than using GetStdHandle to obtain Windows handles. This is probably the most general solution.
Is it possible, to in Windows, create a GUI program, which has it's entry point in 'main()'? How do I do this?
My use for this is that I want a cross-platform application, with one uniform entry point.
Write your application using main() and all the GUI calls in there that you would have used in WinMain. This will create an application with both a GUI and a console window.
Use the Windows SDK tool editbin /SUBSYSTEM:WINDOWS appname.exe to change the subsystem flag in the PE header, so Windows won't create a console window automatically.
If you want to have a working stdout for debug message or the like, you can either use freopen to direct stdout to a file, or AllocConsole when you decide a console window is needed (for example, after an error occurs).
BTW: This thread indicates that the DMD compiler will prefer main() over WinMain() anyway if it finds both.
Is there a way of dynamically running a DLL at a remote Windows box?
Say a user wants to send a his own DLL file to a remote server and run a function in that DLL at the remote site. The user may be able to provide function entry points as well as required parameters, but no more. (e.g. no header file)
I am thinking of setting up an agent executable at the remote site that can (1) dynamically load and bind a unknown DLL and (2) run a function with parameters. Is this a good a approach, or is such an executable possible?
You can use a technique of Dynamically loading your DLL's.
Normally you use a DLL by statically linking a .LIB into your project and compiling it. To load a DLL dynamically at runtime you use the following WIN32 API functions and a few other tricks.
LoadLibaray();
LoadLibarayEx();
GetProcAddress();
FreeLibrary();
There are some other tricks involved
You need to declare the dll functions as export'ed.
In c++ you need to use extern "C" to prevent name mangling of your functions.
FARPROC ... with GetProcAddress
It is all explained in the following wiki article - http://en.wikipedia.org/wiki/Dynamic-link_library
Your idea of installing an executable on the remote machine is a good one. So long as you agree on the function names and parameters with the user. If the dll complies with this then the dll can be changed at any time without requiring you EXE to be changed. Once set up and working it is simple to add extra functions.
Yes you could write small program that runs the DLL function using this information and call it remotely using the something like PSEXEC from sysinternals.
PsExec is a light-weight
telnet-replacement that lets you
execute processes on other systems,
complete with full interactivity for
console applications, without having
to manually install client softwareto manually install client software
Andrew Cash's reply is sound for unmanaged code. The technique he describes around GetProcAddress is essentially what RunDll32.exe does. RunDll32.exe is part of Windows and specializes at loading arbitrary DLLs and executing their code. You can run it like this:
RUNDLL32.EXE [dllfile],[entrypoint] [optional arguments]
When you do this, RunDll32 will call LoadLibrary on the DLL and then GetProcAddress on the entrypoint name you give it. If all that goes well then it calls the entry point function.
For this to actually work the entrypoint function needs to be exported. It must also be declared like this:
void CALLBACK MyEntryPoint(
HWND hwnd,
HINSTANCE hinst,
LPSTR lpszCmdLine,
int nCmdShow);
I guess it is impossible, but I will ask it anyway. I have a Windows application that executes BeginUpdateResource / UpdateResource / EndUpdateResource
Can I somehow execute this on Linux/Unix? Its server-side, so no GUI emulator could be running.
I am not sure exactly what can be achieved with Wine, but that might be a way to go if you have the source code for the application you want to run. See also Will Wine run only under X, or can it run in character mode?.
Another alternative is to re-write the functionality.
I would not recommend it unless you are using Wine which is not an emulator but a re-implementation/binding of the Win32 API on Linux and a handler for Windows executables.
If you want to do things like this, port your application to C#/.NET and use the Mono runtime on the Linux system..
In short, dont