Detection of Windows GUI from a DOS application

[Sfor]

I'm looking for the best way to test a DOS real mode application is runing Windows GUI.

I've been testing for DOS LFN extension services, so far. But, with the presence of the LFNDOS driver, it is possible to have LFN support without Windows GUI running.

My application is a core of a backup/restore system and it should be aware if the GUI is present, before running any windows GUI utility. It is possible to run a WIN32 application waiting for an error result, but such a methode looks a bit crude. Some iterrupt based solution should be much more effective, I think.

[electroglyph]

there must be a simple way to do it by checking environment variables...

just found this:

http://www.freedos.org/freedos/news/technote/118.html

Edited July 23, 2007 by electroglyph

[Sfor]

Checking for %windir% enviroment variable is woking quite good.

It does have just one weak point. The %windir% variable is set during winstart.bat call. The Windows kernel works, but the GUI is still down, then. So, it is not possible to run a WIN32 application, then.

It's a very good solution, anyway.

[Sfor]

The %windir% variable checking works very good with a Windows 9x. But, I found some problems with Windows 2000 and XP.

The SET command displays the presence of the %windir% variable on 9x, 2000 and XP. But, a 16 bit application compiled with Borland Pascal does not detect the variable in windows 2000 and XP. I do not know where this strange phenomenon comes from.

[Glenn9999]

The SET command displays the presence of the %windir% variable on 9x, 2000 and XP. But, a 16 bit application compiled with Borland Pascal does not detect the variable in windows 2000 and XP. I do not know where this strange phenomenon comes from.

It's because those two OSes do not run true DOS, but they run a subset. In essence, anything resembling DOS (if it will even run, a lot of my DOS stuff won't even run on XP) is emulated. Therefore great pains were made to try and keep the DOS apps from detecting the underlying system.

What are those pains? Look at COMSPEC. Usually for Win32 Command-line apps, NT based operating systems will use cmd.exe, but it will use a version of command.com. So to your DOS app (if it even runs), it thinks it's running on MS-DOS 5.00, and consequently will not have the same environment settings as the main command-line session.

My thought to see if you're running in an XP system. Look for cmd.exe (it's real command-line interpreter) in c:\Windows\system32 (if it lets you). That would be a start anyway, at least until I can think of something better to suggest.

[Sfor]

It doesn't make any sense to me, still. As, any DOS application can test for OS=Windows_NT enviroment variable. Also Windows 9x systems did not hide the %windir% variable, so hidding it in a newer systems does not seem to be a logical action. Going towards DOS 5 compatibility leaving DOS 9x system compatibility behind is a bad idea, I believe.

It would be easier to test for just one variable, but testing for both %windir% and %OS% seems to work good enough.