Detecting Windows from a dos box... 
Author Message
 Detecting Windows from a dos box...

Hi,
I have some BP7.01 programs that I need to run under dos as well as within
windows dos boxes (Win311 up to Win2000). Since the routines I use are time
sensitive (if not critical) I need different strategies to establish good timing
depending on whether I am within a dos box or not.
However, I can not find a way to reliably detect that I am within a dos box.
GetDosVersion always reports MS-DOS 5.0 from within a DOS box (haha...) and the
environment strings vary depending on the windows version. - Is there any call
or function that I can use to reliably detect that windows is running?
TIA,
Ingmar Gutberlet

  gutberle.vcf
< 1K Download


Wed, 18 Jun 1902 08:00:00 GMT  
 Detecting Windows from a dos box...

Quote:

> I have some BP7.01 programs that I need to run under dos as well as within
> windows dos boxes (Win311 up to Win2000). Since the routines I use are time
> sensitive (if not critical) I need different strategies to establish good timing
> depending on whether I am within a dos box or not.
> However, I can not find a way to reliably detect that I am within a dos box.
> GetDosVersion always reports MS-DOS 5.0 from within a DOS box (haha...) and the
> environment strings vary depending on the windows version. - Is there any call
> or function that I can use to reliably detect that windows is running?

Try this:

function WindowsActive: boolean; assembler;
asm
  mov  ax, 160Ah
  int  2Fh
  sub  ax, 0
   db  0Fh
   dw  0C094h
end;



Wed, 18 Jun 1902 08:00:00 GMT  
 Detecting Windows from a dos box...

Thanks for the quick reply. Unfortunately this call only checks for Win3 active.
Actually there is quit a number of Windows related calls in the multiplex int
group, but all i tried don't work beyond Win95 - most even report not being
supported under NT. I understand that WinNT would not deem such checks
necessary, since the chasm between DOS and WIN was closed, but as long as I can
reboot my computer into DOS this thinking falls short of reality.
Maybe somebody else would know something... - Thanks anyway!
Ingmar

Quote:


> > I have some BP7.01 programs that I need to run under dos as well as within
> > windows dos boxes (Win311 up to Win2000). Since the routines I use are time
> > sensitive (if not critical) I need different strategies to establish good timing
> > depending on whether I am within a dos box or not.
> > However, I can not find a way to reliably detect that I am within a dos box.
> > GetDosVersion always reports MS-DOS 5.0 from within a DOS box (haha...) and the
> > environment strings vary depending on the windows version. - Is there any call
> > or function that I can use to reliably detect that windows is running?

> Try this:

> function WindowsActive: boolean; assembler;
> asm
>   mov  ax, 160Ah
>   int  2Fh
>   sub  ax, 0
>    db  0Fh
>    dw  0C094h
> end;

  gutberle.vcf
< 1K Download


Wed, 18 Jun 1902 08:00:00 GMT  
 Detecting Windows from a dos box...


Quote:
>Thanks for the quick reply. Unfortunately this call only checks for Win3
>active. Actually there is quit a number of Windows related calls in the
>multiplex int group, but all i tried don't work beyond Win95 - most even
>report not being supported under NT.

Ingmar,

I asked the same question in this newsgroup a while ago
and got the same answer you did.  So I did a little
research and found a different method:

http://www.deja.com/=dnc/getdoc.xp?AN=627421423&fmt=text

This works for all flavors of Windows including NT.

It didn't generate much interest here but it was exactly
what I needed.

Since what you are really interested in is whether there
are unwanted interrupts that could interfere with the timing
in your program, this seems like it might suit your purposes
(as it did mine).  Note that device drivers and TSR's that
hook ISR8 (IRQ0) and do weird things (like SMARTDRV with
write caching enabled) will cause it to report that
multitasking is present.

I'd be curious to know if this solves your problem.



Wed, 18 Jun 1902 08:00:00 GMT  
 Detecting Windows from a dos box...

Of course it does ... I did have to laugh though. I say "windows timing is
weird, can anyone tell me how to detect windows?" and you say "to detect
windows, look if timing is weird". It is a bit like looking for your glasses
which you have sitting on your head...
Actually this jitter is why I posted my question. - While it is possible to read
the timer ports just as you would under DOS, the bios timer in Seg40 which is
incremented by INT08 is totally unreliable. While INT08 has the highest priority
under DOS it obviouly has no priority within Windows. INT1C comes before OR
after INT08 and increments of the Seg40 timer _happen_ asynchronously and with
variable and sometimes horrible delays of up to 150000 ticks post counter
underrun! I tried hard to write routines to resynchronize this mess but failed
time after time, because in order to have the information you need to straighten
out the resulting mess you have to poll the timer anyway and still won't get the
Seg40 timer corrected.
So, what I have to do while in Windoze is to use Int08 AND Int1C (dreadful...)
to update my LastTickCount read in order to avoid having to poll constantly.
Since the average tickcount upon entering Int08's ISR is 35000/65535 and never
is more than 10/65535 this IS the proof that I am running under windoze - I just
didn't look at it from that angle.
Still, if you do not poll constantly, DO NOT believe that the time measured
beyond 55ms will be correct, since the horrid asynchrony between elapsed real
time and the combination of Seg40 timer plus ticktime creates all sorts of
situations with duplicate times, negative time increments and sudden "virtual"
time lapses. Then of course, there IS Windows taking it's toll and the most
laughable thing is that there is a 12ms timing blackout every time Int08 is
called. Talk about negative priority!!!!!!! - So, why do I bother? Well, I did
gazillions of tests and timing is VERY correct just about all of the time and
VERY incorrect just about never. So make your choice. If steering rockets,
avoid, if doing multi trial experiments that require timing, go ahead.
Thanks for giving me the right answer...
Ingmar

Quote:



> >Thanks for the quick reply. Unfortunately this call only checks for Win3
> >active. Actually there is quit a number of Windows related calls in the
> >multiplex int group, but all i tried don't work beyond Win95 - most even
> >report not being supported under NT.

> Ingmar,

> I asked the same question in this newsgroup a while ago
> and got the same answer you did.  So I did a little
> research and found a different method:

> http://www.deja.com/=dnc/getdoc.xp?AN=627421423&fmt=text

> This works for all flavors of Windows including NT.

> It didn't generate much interest here but it was exactly
> what I needed.

> Since what you are really interested in is whether there
> are unwanted interrupts that could interfere with the timing
> in your program, this seems like it might suit your purposes
> (as it did mine).  Note that device drivers and TSR's that
> hook ISR8 (IRQ0) and do weird things (like SMARTDRV with
> write caching enabled) will cause it to report that
> multitasking is present.

> I'd be curious to know if this solves your problem.

  gutberle.vcf
< 1K Download


Wed, 18 Jun 1902 08:00:00 GMT  
 Detecting Windows from a dos box...

Quote:

> Thanks for the quick reply. Unfortunately this call only checks for Win3 active.

Actually, it works in the Windows 98 SE DOS box...


Wed, 18 Jun 1902 08:00:00 GMT  
 Detecting Windows from a dos box...

Yes, you are right. But if you look at the definition of the interrupt function,
it is only meant to check if Win3 is running, meaning that you have to consider
the success of the function under Win98SE more of a bug than a feature...

Quote:


> > Thanks for the quick reply. Unfortunately this call only checks for Win3 active.

> Actually, it works in the Windows 98 SE DOS box...

  gutberle.vcf
< 1K Download


Wed, 18 Jun 1902 08:00:00 GMT  
 Detecting Windows from a dos box...

Quote:



>> > Thanks for the quick reply. Unfortunately this call only checks for
>> > Win3 active.
>> Actually, it works in the Windows 98 SE DOS box...
> Yes, you are right. But if you look at the definition of the interrupt
> function, it is only meant to check if Win3 is running, meaning that you
> have to consider the success of the function under Win98SE more of a bug
> than a feature...

You could also regard it as further evidence that Win98 is basically just a
repackaged version of Win 3... ;-)

--
______________________________________________________________________
     The Scarlet Manuka,      |        Nitpickers' Party motto:
  Pratchett Quoter At Large,  |  "He who guards his lips guards his
 First Prophet of Bonni, is:  |  soul, but he who speaks rashly will

______________________________|_______________________________________



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Detecting Windows DOS box

2. Detecting DOS App under Windows

3. Detect if file is closed on BP7 (Dos or Windows)

4. Detect if file is closed on BP7 (Dos or Windows)

5. Printing inside Windows DOS box

6. TSRs in a Windows DOS-BOX

7. ? IDE in Windows DOS Box (IDLE problem)

8. Timer in DOS, running in a DOS-Box of Win95

9. BP7/DOS in Win95 DOS Box - IOResult problems

10. Detecting Windows from non-Windows program

11. DOS or Windows? (Please say DOS)

12. Running my TP6 Dos program in Windows dos box?

 

 
Powered by phpBB® Forum Software