Re: detecting running environment, windows

[BrowserUk]

in reply to detecting running environment, windows

I have a gui shell for my application, using wxPerl... when the GUI application is linked as a textmode app

Your gui is a compiled executable?

And by "linked as a textmode application", you mean you use /SUBSYSTEM:console when building the executable?

What linker options are you using when you "linked as a GUI app"?

If you are using /SUBSYSTEM:windows, then that might start to explain your symptoms (MSVC link.exe docs):

WINDOWS Application does not require a console, probably because it creates its own windows for interaction with the user.

Note: that "Application does not require a console," means when the application is loaded, no console is allocated to it. Of itself that is probably not a problem, but it ccan also mean that processes started by that application may inherit that trait.

if I don't link the UI as a gui application, then when launched from the gui windows explorer, the textmode box appears when the gui is started instead..

Probably your best solution would be to drop IPC::Run3 (on Windows at least), and use Win32::Process to start your subprocess(es).

This has options to control the creation of consoles (CREATE_NEW_CONSOLE) and console windows (CREATE_NO_WINDOW) and background processes (DETACHED_PROCESS) etc.

It's not clear to me how you are creating your perl application as a linked executable, so this is more a list of things to investigate rather than a definitive solution.

[sdetweil]

thanks that really clear up a bunch of things.. the Subsytem attribute on the executable is set to Windows as you suspected.. and the key thing there is that this application does HAVE a stdin for Run3 to dup and use. thank you.. I probably should be able to tell if handle 0 is valid or not.