Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.msdos.programmer > #1364 > unrolled thread

detecting emulation or console windows

Back to article view | Back to comp.os.msdos.programmer

Contents

  detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-31 18:31 -0400
    Re: detecting emulation or console windows Ross Ridge <rridge@csclub.uwaterloo.ca> - 2014-05-31 19:59 -0400
      Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-31 20:54 -0400
        Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-31 21:43 -0400
          Re: detecting emulation or console windows "James Harris" <james.harris.1@gmail.com> - 2014-06-01 22:48 +0100
            Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-02 00:46 -0400
              Re: detecting emulation or console windows "James Harris" <james.harris.1@gmail.com> - 2014-06-02 06:15 +0100
                Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-02 03:21 -0400
                  Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-02 03:32 -0400
                  Re: detecting emulation or console windows "James Harris" <james.harris.1@gmail.com> - 2014-06-02 09:51 +0100
                    Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-02 09:27 -0400
                      Re: detecting emulation or console windows "James Harris" <james.harris.1@gmail.com> - 2014-06-02 17:05 +0100
                        Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-02 19:25 -0400
                          Re: detecting emulation or console windows "James Harris" <james.harris.1@gmail.com> - 2014-06-04 07:55 +0100
                            Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-04 03:20 -0400
        Re: detecting emulation or console windows Ross Ridge <rridge@csclub.uwaterloo.ca> - 2014-06-01 14:03 -0400
          Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-02 00:53 -0400
            Re: detecting emulation or console windows Ross Ridge <rridge@csclub.uwaterloo.ca> - 2014-06-02 15:55 -0400
              Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-02 19:27 -0400
                Re: detecting emulation or console windows Ross Ridge <rridge@csclub.uwaterloo.ca> - 2014-06-03 17:00 -0400
    Re: detecting emulation or console windows Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2014-06-01 06:25 +0200
      Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-01 02:50 -0400
    Re: detecting emulation or console windows "James Harris" <james.harris.1@gmail.com> - 2014-06-01 07:53 +0100
      Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-01 04:53 -0400
        Re: detecting emulation or console windows "James Harris" <james.harris.1@gmail.com> - 2014-06-01 20:57 +0100
          Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-02 00:48 -0400
        Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-02 03:20 -0400
    Re: detecting emulation or console windows JJ <duh@nah.meh> - 2014-06-02 03:43 +0700
      Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-02 00:34 -0400
      Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-03 07:06 -0400
        Re: detecting emulation or console windows JJ <duh@nah.meh> - 2014-06-03 20:25 +0700
    Re: detecting emulation or console windows "wolfgang kern" <nowhere@never.at> - 2014-06-03 20:52 +0200
    Re: detecting emulation or console windows "James Harris" <james.harris.1@gmail.com> - 2014-06-03 22:59 +0100
      Re: detecting emulation or console windows CN <qmbmnp3799@pacbell.net> - 2014-06-03 18:39 -0700
        Re: detecting emulation or console windows "James Harris" <james.harris.1@gmail.com> - 2014-06-04 07:06 +0100
          Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-04 03:07 -0400
            Re: detecting emulation or console windows "James Harris" <james.harris.1@gmail.com> - 2014-06-04 09:16 +0100
    Re: detecting emulation or console windows "James Harris" <james.harris.1@gmail.com> - 2014-06-03 23:00 +0100
    Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-10 17:37 -0400
      Re: detecting emulation or console windows Wildman <best_lay@yahoo.com> - 2014-06-11 00:37 +0000
        Re: detecting emulation or console windows "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-07-27 12:11 -0400

Page 1 of 3  [1] 2 3  Next page →

#1364 — detecting emulation or console windows

Do you guys have any pointers on detecting whether or not code
is executing in an emulator or in console window?

Specifically, I have DJGPP (GCC) DOS code which is intended
to execute under a DPMI host starting from RM (real-mode)
MS-DOS.  The problem is the code is incompatible with emulated
environments and causes a crash, i.e., programs hardware.

Console windows, like Windows 98/SE's DOS console or Linux's
dosemu environment, are emulating well enough that I can't
currently detect them.  But, I'd like the code to exit cleanly,
if possible, instead of crashing.

I'm aware that certain environments, e.g., DOSBOX, have
a specific interrupt routine that can be called to detect.
I use a bunch of these such calls, but they're insufficient.
The fact such calls are available is good, but I'd prefer
something more generic so that I'm coding up dozens upon
dozens of tests, including tests for environments I can't test.

I've looked at CR0.PE, but dosemu emulates MOV CRO and SMSW
accurately enough that those instructions are *not* useful,
i.e., they indicate CR0.PE is clear even when under emulation.
A20 has a similar problem.  Under emulation, it initially indicates
it's not enabled.  So, now, I'm thinking about keyboard, NMI, RTC,
or other things, like processor flags, interrupts, memory locations,
instruction bugs, self-modifying code, etc where emulation might
not be perfect or is at least detectable.  The goals are: simple,
reliable, i.e., works everywhere, all machines, all processors,
all types of emulation.

So, if software emulation is good, it's hard to detect.  I've
been searching Google, Yahoo, and Usenet archives for some hints,
but I'm not finding much.  It seems Shawn Hargreaves of Allegro
ran into much the same issue years ago, but I'm not sure if he
found a solution.


Rod Pemberton
PS.  This is cross-posted to a few groups.  I read all, but it's
easier for me, if you leave all groups on.

[toc] | [next] | [standalone]

#1365

Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>I've looked at CR0.PE, but dosemu emulates MOV CRO and SMSW
>accurately enough that those instructions are *not* useful,
>i.e., they indicate CR0.PE is clear even when under emulation.

DOSBox and dosemu on 64-bit Linux both emulate a real-mode environment,
not a virtual 8086 environment so that's why the PE bit is clear.
If your application expects actual real mode and doesn't work in either
of these emulators then either your something is wrong with the emulator
or your application.  There shouldn't be any difference between real mode
on an Intel CPU and the real mode provided by these software emulators.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#1366

On Sat, 31 May 2014 19:59:16 -0400, Ross Ridge  
<rridge@csclub.uwaterloo.ca> wrote:
> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:

>> I've looked at CR0.PE, but dosemu emulates MOV CRO and SMSW
>> accurately enough that those instructions are *not* useful,
>> i.e., they indicate CR0.PE is clear even when under emulation.
>
> DOSBox and dosemu on 64-bit Linux both emulate a real-mode environment,
> not a virtual 8086 environment so that's why the PE bit is clear.

That's one part of the point, but not the critical part, IMO.

CR0.PE should be emulated as clear for DOSBox which uses your own DPMI host
(except for one or two old versions which had DPMI enabled...).  IMO,  
CR0.PE
should be emulated as _set_ for dosemu since dosemu provides it's own  
32-bit
PM DPMI host.  I.e., dosemu should report as PM, meaning v86 instead of RM.
However, it doesn't until something uses DPMI.

> If your application expects actual real mode and doesn't work in either
> of these emulators [...]

The problem isn't the code.  It's a standard 32-bit PM DPMI (GCC via DJGPP)
application with a 16-bit RM startup.  The problem is that the code  
basically
runs everywhere, including under environments where it shouldn't be  
executed,
such as under OSes like Windows 98/SE/NT/2K/XP, and emulation such as  
DOSBox
and dosemu.  So, I'd like to detect and reject these environments.  The  
other
option is to just let the user try and fail.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1367

On Sat, 31 May 2014 20:54:26 -0400, Rod Pemberton  
<dont_use_email@xnothavet.cqm> wrote:
> On Sat, 31 May 2014 19:59:16 -0400, Ross Ridge  
> <rridge@csclub.uwaterloo.ca> wrote:
>> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:

>>> I've looked at CR0.PE, but dosemu emulates MOV CRO and SMSW
>>> accurately enough that those instructions are *not* useful,
>>> i.e., they indicate CR0.PE is clear even when under emulation.
>>
>> DOSBox and dosemu on 64-bit Linux both emulate a real-mode environment,
>> not a virtual 8086 environment so that's why the PE bit is clear.
>
> That's one part of the point, but not the critical part, IMO.
>
> CR0.PE should be emulated as clear for DOSBox which uses your own DPMI  
> host (except for one or two old versions which had DPMI enabled...).
> IMO, CR0.PE should be emulated as _set_ for dosemu since dosemu provides
> it's own 32-bit PM DPMI host.  I.e., dosemu should report as PM, meaning
> v86 instead of RM. However, it doesn't until something uses DPMI.

Sorry, it seems I got something wrong here...  dosemu *DOES* return v86
as enabled prior to using DPMI.  So, that's good!

It seems dosemu doesn't provide the PS/2 A20 bit, and doesn't toggle
keyboard A20 bit when A20 is enabled.  No real machine fails that.
Only really old machines are missing the PS/2 A20 bit.

DOSBox emulates both PS/2 and keyboard A20, but it doesn't do it
correctly!  Each A20 bit, keyboard and PS/2, operate independently
of each other.  I.e., if you turn keyboard A20 on, and then PS/2 A20 on,
you must turn *both* off to disable A20.  DOSBOX treats them as a
single A20 on/off instead of the two separate A20 enable/disables,
on real machines which have both bits.

So, if you've got 16-bit, A20 differences can be used to detect
those two emulators.

So, maybe, if I search around a bit more, I'll come up with something
consistent.  Unfortunately, this is still rather specialized, and I
can't test A20 after the DPMI app enters PM.  I.e., I can't test A20
in my C code.  So, it'd need to be a custom binary with a modified
16-bit startup, which I'm definately not going to do.

But, I've got a bit of hope now that some solution exists!  Their
emulation isn't perfect.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1375

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xgq5q0ms6zenlw@localhost...

...

> It seems dosemu doesn't provide the PS/2 A20 bit, and doesn't toggle
> keyboard A20 bit when A20 is enabled.  No real machine fails that.

Are you sure? Take a look at the A20 Controls section in

  http://aodfaq.wikispaces.com/machine+characteristics

In the table check the first "K bits" column. It shows the effects of 
enabling A20 by the KBC. Note that bit 1 (which is the A20 control) changes 
from 0 to 1 correctly on some machines but not all. The Aopen and the Asus 
were both found to leave that bit as 0 even after being told to set it to 1. 
A20 was enabled but the effect was not evident in the bit.

> Only really old machines are missing the PS/2 A20 bit.
>
> DOSBox emulates both PS/2 and keyboard A20, but it doesn't do it
> correctly!  Each A20 bit, keyboard and PS/2, operate independently
> of each other.  I.e., if you turn keyboard A20 on, and then PS/2 A20 on,
> you must turn *both* off to disable A20.  DOSBOX treats them as a
> single A20 on/off instead of the two separate A20 enable/disables,
> on real machines which have both bits.
>
> So, if you've got 16-bit, A20 differences can be used to detect
> those two emulators.

Don't go there! Many machines don't really have the old keyboard hardware 
any more but emulate it in firmware. Accesses to KBC ports, for example, 
trap to emulation routines. Thus you could see the things you are testing 
not just with emulator programs but also when running on bare metal.

> So, maybe, if I search around a bit more, I'll come up with something
> consistent.  Unfortunately, this is still rather specialized, and I
> can't test A20 after the DPMI app enters PM.  I.e., I can't test A20
> in my C code.  So, it'd need to be a custom binary with a modified
> 16-bit startup, which I'm definately not going to do.
>
> But, I've got a bit of hope now that some solution exists!  Their
> emulation isn't perfect.

Nor are machines!

James

[toc] | [prev] | [next] | [standalone]

#1377

On Sun, 01 Jun 2014 17:48:09 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
> news:op.xgq5q0ms6zenlw@localhost...

>> It seems dosemu doesn't provide the PS/2 A20 bit, and doesn't toggle
>> keyboard A20 bit when A20 is enabled.  No real machine fails that.
>
> Are you sure? Take a look at the A20 Controls section in
>
>   http://aodfaq.wikispaces.com/machine+characteristics
>

Well, I should've consulted that.  I didn't forget it exists.  Clearly,
I didn't recall any with that defect.  I remember some had the keyboard
bit permanently set.  But, for an emulator, I'd still argue they should
implement the "correct" method. ;-)  How common are some of the problem
machines we found anyway?  IIRC, probably don't, it was my, yours, and
Wolfgang's obscure collection ... Or, Steve? Alexei?  I.e., this was not
what we could call an "excellent" sample selection of machines.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1380

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xgs8v3iw6zenlw@localhost...
> On Sun, 01 Jun 2014 17:48:09 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>> news:op.xgq5q0ms6zenlw@localhost...
>
>>> It seems dosemu doesn't provide the PS/2 A20 bit, and doesn't toggle
>>> keyboard A20 bit when A20 is enabled.  No real machine fails that.
>>
>> Are you sure? Take a look at the A20 Controls section in
>>
>>   http://aodfaq.wikispaces.com/machine+characteristics
>>
>
> Well, I should've consulted that.  I didn't forget it exists.

I sometimes forget it exists. I especially forget what's on it.

> Clearly,
> I didn't recall any with that defect.  I remember some had the keyboard
> bit permanently set.  But, for an emulator, I'd still argue they should
> implement the "correct" method. ;-)

Sure they should. The trouble is that some PCs don't implement the "correct" 
method either.

> How common are some of the problem
> machines we found anyway?  IIRC, probably don't, it was my, yours, and
> Wolfgang's obscure collection ... Or, Steve? Alexei?  I.e., this was not
> what we could call an "excellent" sample selection of machines.

Are you saying that you want to ignore problem machines? Looking at those on 
the list their brand names are well known so I suspect that many machines 
exhibit this problem. They did correctly enable A20 though.

As evidence of other incorrect PCs I think the MSI may have been yours. 
According to the table it seems to show the KBC output port bit as set even 
before enabling A20. That was a problem for the Asus EEE too and possibly 
the Viglen Geode. So I suspect that problem hardware is quite common.

James

[toc] | [prev] | [next] | [standalone]

#1382

On Mon, 02 Jun 2014 01:15:58 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
> news:op.xgs8v3iw6zenlw@localhost...
>> On Sun, 01 Jun 2014 17:48:09 -0400, James Harris
>> <james.harris.1@gmail.com> wrote:
>>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>>> news:op.xgq5q0ms6zenlw@localhost...

>>>> It seems dosemu doesn't provide the PS/2 A20 bit, and doesn't toggle
>>>> keyboard A20 bit when A20 is enabled.  No real machine fails that.
>>>
>>> Are you sure? Take a look at the A20 Controls section in
>>>
>>>   http://aodfaq.wikispaces.com/machine+characteristics
>>>
>>
>> Well, I should've consulted that.  I didn't forget it exists.
>
> I sometimes forget it exists. I especially forget what's on it.
>

It's really "cryptic", IMO, no offense.

>> Clearly,
>> I didn't recall any with that defect.  I remember some had the keyboard
>> bit permanently set.  But, for an emulator, I'd still argue they should
>> implement the "correct" method. ;-)
>
> Sure they should. The trouble is that some PCs don't implement the  
> "correct" method either.

How many don't? ... (joke) ;-)

>> How common are some of the problem machines we found anyway?
>> IIRC, probably don't, it was my, yours, and Wolfgang's obscure
>> collection ... Or, Steve? Alexei?  I.e., this was not
>> what we could call an "excellent" sample selection of machines.
>
> Are you saying that you want to ignore problem machines?

No.

Although, ... that might not be a bad idea.

> Looking at those on the list their brand names are well known [...]

 From the table, I think we can conclude BIOS A20 control is useless,
and PS/2 bit is the most correct, A20 enables correctly for each
supported method, at least for the sample set.

> Looking at those on the list their brand names are well known so
> I suspect that many machines exhibit this problem. They did
> correctly enable A20 though.

Well, my C code is executing after a 32-bit PM switch, i.e., A20
should be "permanently" enabled while the code is running in PM.
So, disabling A20 while in PM to test A20 should clearly be avoided.
IIRC, we (?) discussed something about 486's forcing A20 on for PM (?).

> As evidence of other incorrect PCs I think the MSI may have been yours.

I think three of mine are on the list now ...
MSI K9N Neo-F (dead)
GigaByte MA78LM-S2H (current)
ABIT AB-SM5-A (old)

There's an HP in the basement I've been meaning to spruce up...

And, there's another one here w/electrical problems that I've
been saying I'm going to get working again for a few tests for
years and years now ...

The other machines are probably too deep in the pile of boxes.

> According to the table it seems to show the KBC output port
> bit as set even before enabling A20.

Yes, and the other one (ABIT) was pre-PS/2 port.

It appears some data is wrong in the chart.

For the MSI, it says "00-02" (PS/2 A bit) but then has "02"
in binary for both.  I don't recall what's correct... From
my post the "00-02" heading is correct, so the binary "02"
(first binary) should be changed to "00" binary.

Ditto for the Gigabyte.  It says "09-09" (PS/2 K bit) but
then has "09" and "0B" in binary.  From my post "09-09" is
correct, so the binary "0B" (second binary) should be changed
to "09" binary.

So much for using Javascript to do binary ... (joke) ;-)

> That was a problem for the Asus EEE too and possibly
> the Viglen Geode. So I suspect that problem hardware
> is quite common.

Ok.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1383

On Mon, 02 Jun 2014 03:21:25 -0400, Rod Pemberton  
<dont_use_email@xnothavet.cqm> wrote:

[A20]

> Well, my C code is executing after a 32-bit PM switch, i.e., A20
> should be "permanently" enabled while the code is running in PM.
> So, disabling A20 while in PM to test A20 should clearly be avoided.

Or, maybe not ...  I'm wondering how emulators implement A20.  Do any of
them actually implement it?  I.e., do any unmap memory above roughly 1MB
when A20 is disabled.  Or, do they just pretend to implement the A20
enable/disable, and actually map all memory above 1MB?  Do any actually
implement the memory wrap when A20 is disabled?  It's possible many might
ignore it.  How many DOS applications *require* the 1MB memory wrap?
That probably hasn't been a necessity for a long time.  So, would they?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1384

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xgtf1zk06zenlw@localhost...
> On Mon, 02 Jun 2014 01:15:58 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>> news:op.xgs8v3iw6zenlw@localhost...
>>> On Sun, 01 Jun 2014 17:48:09 -0400, James Harris
>>> <james.harris.1@gmail.com> wrote:

...

>>>>   http://aodfaq.wikispaces.com/machine+characteristics
>>>>
>>>
>>> Well, I should've consulted that.  I didn't forget it exists.
>>
>> I sometimes forget it exists. I especially forget what's on it.
>>
>
> It's really "cryptic", IMO, no offense.

None taken. I agree. I do have thoughts on improving it and making it easier 
to add info but that will take time to set up. For now the notes above and 
below the tables are much easier to read, at least to start with.

...

> From the table, I think we can conclude BIOS A20 control is useless,

Definitely!

> and PS/2 bit is the most correct,

I presume you mean the bit in System Control Port A, address 0x0092. Was it 
not used in ISA machines? It is mentioned in the ISA System Architecture 
book but The Undocmented PC shows it as present in MCA/EISA so I'm not sure.

SCPA bit 1 may be more correct than the KBC bit (as an indicator, not as a 
method) but it doesn't seem to be completely reliable. There is one machine 
in the table where it is always set and so it doesn't work as an indication 
of whether A20 is enabled or not.

> A20 enables correctly for each
> supported method, at least for the sample set.

Not quite. SCPA enable fails on the ABIT - though it is a relatively old 
machine. I think the KBC bit is by far the best method - and it should be 
set by the old fashioned method of writing the output port (with command 
0xD1). There are special commands to set the bit but they are only supported 
by some PCs.

  http://www.win.tue.nl/~aeb/linux/kbd/A20.html

The old write to output port method (with a terminating null command to keep 
some firmware happy, i.e. send 0xD1xx where xx has the bit set and then send 
0xFF) seems to be universal and is the only method supported by newer 
Microsoft boot sectors that I have seen so it should remain reliable. E.g. 
search for A20 in

  http://thestarman.pcministry.com/asm/mbr/W7MBR.htm

Rather than rely on KBC and SCPA indicators I use a routine to test A20. It 
should be more reliable. At least I hope it is. Will post it at the end.

>> Looking at those on the list their brand names are well known so
>> I suspect that many machines exhibit this problem. They did
>> correctly enable A20 though.
>
> Well, my C code is executing after a 32-bit PM switch, i.e., A20
> should be "permanently" enabled while the code is running in PM.
> So, disabling A20 while in PM to test A20 should clearly be avoided.
> IIRC, we (?) discussed something about 486's forcing A20 on for PM (?).

Yes, I think you or someone else pointed out to me that a disabled A20 in PM 
is invalid so the effects would be undefined.

...

> It appears some data is wrong in the chart.
>
> For the MSI, it says "00-02" (PS/2 A bit) but then has "02"
> in binary for both.  I don't recall what's correct... From
> my post the "00-02" heading is correct, so the binary "02"
> (first binary) should be changed to "00" binary.
>
> Ditto for the Gigabyte.  It says "09-09" (PS/2 K bit) but
> then has "09" and "0B" in binary.  From my post "09-09" is
> correct, so the binary "0B" (second binary) should be changed
> to "09" binary.

You are right. I must have mistranscribed the info you sent. I looked back 
to your original post and it was clear enough. Sorry about that. The entries 
have been fixed now.

...

The A20 test routine I mentioned follows below.

James

;******************************************************************************
;
; Return the current A20 state
;
;******************************************************************************

global _a20_state

_a20_state equ a20_state

TEST_WORD equ 0x05fe ;Must be 0xffee or lower

a20_state:

; Test whether the test word and the test word + 0x10_0000 are really
; the same address (bit 20 being forced to zero).

; Supplied - None
; Returned - 0 if disabled, 1 if enabled
; Modified - None

; DS and ES are temporarily changed during this routine.
; Interrupts are disabled briefly

  push es
  push ds
  pushf     ; Save incoming interrupt enable state

  ; Set up segment registers - DS for low mem and ES for high mem
  xor ax, ax
  mov ds, ax
  dec ax
  mov es, ax

  ; Test A20 state
  cli
  mov ax, [TEST_WORD]           ;Fetch the current value at the low address
  cmp ax, [es: TEST_WORD + 16]  ;Compare with the word above 1M
  jne .is_enabled               ;Jump if they differ

  not ax                        ;Form a different value
  mov [TEST_WORD], ax           ;Store into low address
  cmp ax, [es: TEST_WORD + 16]  ;Compare with the word above 1M
  not ax                        ;Form original value (without changing 
flags)
  mov [TEST_WORD], ax           ;Restore memory (without changing flags)
  jne .is_enabled               ;Branch on result of the compare instruction

  ;A20 is disabled
  xor ax, ax
  jmp .done

.is_enabled:
  mov ax, 1

.done:
  popf    ; Restore initial interrupt enable state
  pop ds
  pop es
  ret

[toc] | [prev] | [next] | [standalone]

#1385

On Mon, 02 Jun 2014 04:51:28 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
> news:op.xgtf1zk06zenlw@localhost...

>> A20 enables correctly for each
>> supported method, at least for the sample set.
>
> Not quite. SCPA enable fails on the ABIT

Ah, you missed my weasel wording: "for each supported method".
I.e., the PS/2 method is _not_ supprted on the ABIT ...

> The A20 test routine I mentioned follows below.
>
> [...]

I have a whole bunch of DOS .com's which
enable and disable A20.  In DOS, you have to
boot clean, i.e., no XMS memory manager to
correctly detect and use A20.  XMS memory managers
emulate A20.

DOS .com programs:
-on and off for keyboard A20 bit
-on and off for PS/2 bit
-on and off for Int 15 - and some others for Int 15
-on for UHCI A20 sequence
-(unimplemented) on for OHCI A20 sequence
  (this might be same as the UHCI sequence...)
-some others that were experimental or used A20
  routines from other people

I don't want to give away the code for the my code
that checks the A20 status, but I'll tell you what
it does.  You could probably recreate it.

-checks for XMS memory manager
(XMS emulates A20 in DOS and may return incorrect
results because of the emulation.  A message is
emitted stating XMS is enabled.)

-disable interrupts
-sets some RM segments
-sets the 0h vector to a routine which emits "A20 ON"
-sets the memory at the possibly wrapped location above
1MB which is equivalent to the 0h vector to a routine
which emits "A20 OFF"  (I.e., if memory is wrapped,
Int 0h reports off.  If memory is not wrapped, Int 0h
reports on.)

-enable interrupts
-does an Int 0h
-disable interrupts

-standard routine to read A20 keyboard bit
and display it's status
-standard routine to read A20 PS/2 bit
and display it's status, adjusted slightly
to detect a non-existent PS/2 port ...
-exits to DOS


AIUI, the Int instruction should force memory coherency
and/or cache flush etc to ensure that the memory wrap or
unwrap is in effect prior to generating the interrupt.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1386

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xgtw0lnh6zenlw@localhost...
> On Mon, 02 Jun 2014 04:51:28 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>> news:op.xgtf1zk06zenlw@localhost...
>
>>> A20 enables correctly for each
>>> supported method, at least for the sample set.
>>
>> Not quite. SCPA enable fails on the ABIT
>
> Ah, you missed my weasel wording: "for each supported method".
> I.e., the PS/2 method is _not_ supprted on the ABIT ...

I noticed the wording but evidently misunderstood your meaning. I see now 
you meant supported *on a given machine*.

>> The A20 test routine I mentioned follows below.
>>
>> [...]
>
> I have a whole bunch of DOS .com's which
> enable and disable A20.  In DOS, you have to
> boot clean, i.e., no XMS memory manager to
> correctly detect and use A20.  XMS memory managers
> emulate A20.

You mean they enable it and then program segment tables to mimic wrapping as 
needed? I'm not sure whether that would work or not. Just a guess.

> DOS .com programs:
> -on and off for keyboard A20 bit
> -on and off for PS/2 bit
> -on and off for Int 15 - and some others for Int 15
> -on for UHCI A20 sequence
> -(unimplemented) on for OHCI A20 sequence
>  (this might be same as the UHCI sequence...)
> -some others that were experimental or used A20
>  routines from other people
>
> I don't want to give away the code for the my code
> that checks the A20 status, but I'll tell you what
> it does.  You could probably recreate it.

...

You probably only need that complexity because you start from DOS.

As this has come up I have to say that I was surprised at the start of this 
thread when you mentioned that your new project started from DOS the way 
that your OS does. I remember discussing how complex that made your OS 
startup. Did you not want to do away with that in your new project?

> AIUI, the Int instruction should force memory coherency
> and/or cache flush etc to ensure that the memory wrap or
> unwrap is in effect prior to generating the interrupt.

Is that needed? We discussed this on alt.os.development a few years ago and, 
IIRC, came to the conclusion that the A20 mask occurs between the CPU and 
its caches even if those caches are on chip. (There is an A20 gate input pin 
on CPUs with caches.) So the test of A20 is one of addressing, not memory 
values. In other words there is no need for memory coherency such as to 
allow updated values to drain to memory before reading them back from the 
other address.

The only potential problem I can remember would be a machine such as an old 
pre-486 (i.e. one which has no on-chip cache) then an external cache and 
then the A20 gate. That was theoretcical. We didn't identify any particular 
machine which was built that way.

James

[toc] | [prev] | [next] | [standalone]

#1388

On Mon, 02 Jun 2014 12:05:34 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
> news:op.xgtw0lnh6zenlw@localhost...

>> I have a whole bunch of DOS .com's which
>> enable and disable A20.  In DOS, you have to
>> boot clean, i.e., no XMS memory manager to
>> correctly detect and use A20.  XMS memory managers
>> emulate A20.
>
> You mean they enable it and then program segment tables
> to mimic wrapping as needed?

I'm not sure what XMS does with A20.  It's emulated somehow.
I'd have to recheck, but I think XMS wouldn't let you enable
or disable A20 via the standard methods.

> As this has come up I have to say that I was surprised at
> the start of this thread when you mentioned that your new
> project started from DOS the way that your OS does.I remember discussing  
> how complex that made your OS startup.
> Did you not want to do away with that in your new project?

This doesn't use anything from my OS.  It uses standard
DJGPP (GCC) C compiler and DPMI functionality.  It doesn't
need to dump out the DPMI host, or DOS, or need a special
TSR to start, etc like my OS.  I'm hoping to keep it to
only DJGPP and DPMI functionality, excluding some potential
direct hardware access.  For it to be useful, it needs to
be made to operate somewhat faster.

>> AIUI, the Int instruction should force memory coherency
>> and/or cache flush etc to ensure that the memory wrap or
>> unwrap is in effect prior to generating the interrupt.
>
> Is that needed?

It's done.  It's been done.  It works.

Codewise, it looks clean-er...

> We discussed this on alt.os.development a few years ago
> and,

Yes.

> IIRC, came to the conclusion that the A20 mask
> occurs between the CPU and its caches even if those
> caches are on chip. (There is an A20 gate input pin
> on CPUs with caches.) So the test of A20 is one of
> addressing, not memory values. In other words there
> is no need for memory coherency such as to allow
> updated values to drain to memory before reading
> them back from the other address.

I don't remember the conclusion, but as long as the
cache is up to date in terms of A20 state at the time
of the memory writes to the vector and high address,
it won't matter if the value is in cache or memory.

And, you know about both techniques, so if you want to
search for one where the Int method doesn't work, it's
your choice.  I only had a half dozen machines to test
on.

> The only potential problem I can remember would be
> a machine such as an old pre-486 (i.e. one which has
> no on-chip cache) then an external cache and then
> the A20 gate. That was theoretcical. We didn't
> identify any particular machine which was built
> that way.

That would be a "strange bird", at least for x86.

IIRC, the 68000 series had an external MMU for the first
few processors, but I recall if they had an external cache.


Rod Pemberton
P.S.  Opera has an option which says it's supposed to be wrapping lines  
for Usenet so I'm sending this extra long one to see what happens ...

[toc] | [prev] | [next] | [standalone]

#1402

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xguoost76zenlw@localhost...
> On Mon, 02 Jun 2014 12:05:34 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
>> news:op.xgtw0lnh6zenlw@localhost...
>
>>> I have a whole bunch of DOS .com's which
>>> enable and disable A20.  In DOS, you have to
>>> boot clean, i.e., no XMS memory manager to
>>> correctly detect and use A20.  XMS memory managers
>>> emulate A20.
>>
>> You mean they enable it and then program segment tables
>> to mimic wrapping as needed?
>
> I'm not sure what XMS does with A20.  It's emulated somehow.
> I'd have to recheck, but I think XMS wouldn't let you enable
> or disable A20 via the standard methods.

AFAICT XMS provides an API for managing memory. It provides A20 management 
calls but I cannot see how it can trap and emulate A20 changes. I say that 
because XMS was a spec from the early days of long ago, wasn't it? I don't 
think PCs had any virtualisation support then. Real-mode code that changed 
A20 would run as privileged and so I cannot see how such could trap to 
anything. Nor could it prevent access to the keyboard controller so I cannot 
see how XMS could prevent a program from changing A20.

...

>>> AIUI, the Int instruction should force memory coherency
>>> and/or cache flush etc to ensure that the memory wrap or
>>> unwrap is in effect prior to generating the interrupt.
>>
>> Is that needed?
>
> It's done.  It's been done.  It works.

Putting a NOP in a piece of code also "works" but its presence might be 
misleading and unnecessary and nothing to do with whether the piece of code 
works or not!

> Codewise, it looks clean-er...
>

...

> P.S.  Opera has an option which says it's supposed to be wrapping lines 
> for Usenet so I'm sending this extra long one to see what happens ...

Haven't checked in any detail but the posts do seem easier to read.

James

[toc] | [prev] | [next] | [standalone]

#1405

On Wed, 04 Jun 2014 02:55:22 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

>> P.S.  Opera has an option which says it's supposed to be wrapping lines
>> for Usenet so I'm sending this extra long one to see what happens ...
>
> Haven't checked in any detail but the posts do seem easier to read.
>

The line came through unwrapped where I read.  I'm speculating that
the wrapping option in Opera may only be for the viewing window, not
actually for terminating lines for posting.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1372

Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>IMO, CR0.PE should be emulated as _set_ for dosemu since dosemu provides
>it's own 32-bit PM DPMI host.  I.e., dosemu should report as PM, meaning
>v86 instead of RM.  However, it doesn't until something uses DPMI.

No, under bare-metal MS-DOS a DPMI host wouldn't normally switch into
protected mode until it was first used.  The processor wouldn't be
running in Virtual 8086 mode (CR0.PE set) unless something else like a
EMS emulator (eg. EMM386) put in that mode.

>The problem isn't the code.  It's a standard 32-bit PM DPMI (GCC via DJGPP)
>application with a 16-bit RM startup.  The problem is that the code
>basically runs everywhere, including under environments where it
>shouldn't be  executed, such as under OSes like Windows 98/SE/NT/2K/XP,
>and emulation such as  DOSBox and dosemu.  So, I'd like to detect and
>reject these environments.  The  other option is to just let the user
>try and fail.

Sorry, but I don't understand what the problem is.  Why exactly shouldn't
this code run under DOSBox or any other emulator that is designed
to emulate an entire PC, including real-mode and all hardware?  If it
crashes on DOSBox, but works fine on bare-metal MS-DOS then something is
either wrong with DOSBox or your application.  As far your application
is concerned it should startup in 16-bit real-mode and then switch in
32-bit protected mode via a DPMI host regardless of whether it's running
natively on an Intel CPU, software emulation using DOSBox or hardware
emulation running under Virtual PC, VirutalBox or some other VM.

Which brings up the fact that you haven't mentioned need to block your
code running under any of the VMs.  If you need to block it running on
software emulatorl like DOSBox you should also need to block it running
under hardware emulation.  If on the other hand your code works fine
under VMs but not DOSBox then this points back to this either being a
problem with your code or DOSBox.

I think maybe going about this the wrong way.  Perhaps the best way to
resolve your problem isn't to crudely detect incompatible environments,
but to detect whether the hardware or other specific minimal set of
conditions necessary for your program to run correctly are present.
You might also be able to make your application more robust so that it
doesn't crash when the enviroment isn't exactly what you need.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#1379

On Sun, 01 Jun 2014 14:03:27 -0400, Ross Ridge  
<rridge@csclub.uwaterloo.ca> wrote:
> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:

>> IMO, CR0.PE should be emulated as _set_ for dosemu since dosemu provides
>> it's own 32-bit PM DPMI host.  I.e., dosemu should report as PM, meaning
>> v86 instead of RM.  However, it doesn't until something uses DPMI.
>
> No, under bare-metal MS-DOS a DPMI host wouldn't normally switch into
> protected mode until it was first used.  The processor wouldn't be
> running in Virtual 8086 mode (CR0.PE set) unless something else like a
> EMS emulator (eg. EMM386) put in that mode.
>

As noted in my other post, I made a mistake.  dosemu *does* set CR0.PE
correctly.  This is because DPMI services are installed.  I.e., the
DPMI host uses PM to provide DPMI calls, so CR0.PE should be set when
DPMI is present.

AISI, this is no different that installing a DPMI host permanently,
as allowed by some hosts.  Once installed permanently, the CR0.PE
should be set.

>> The problem isn't the code.  It's a standard 32-bit PM DPMI (GCC
>> via DJGPP) application with a 16-bit RM startup.  The problem is
>> that the code basically runs everywhere, including under environments
>> where it shouldn't be  executed, such as under OSes like Windows
>> 98/SE/NT/2K/XP, and emulation such as DOSBox and dosemu.  So, I'd
>> like to detect and reject these environments.  The  other option
>> is to just let the user try and fail.
>
> Sorry, but I don't understand what the problem is.

I'd prefer my application to exit cleanly, not execute for environments
where it crashes, not execute for environments where it's not likely
to work correctly, not execute for environments which are restricted
in functionality, not execute for environments where the environment
is something other than booted directly into DOS in RM, i.e.,
emulation, VM's, certain incompatible DPMI hosts.

> Why exactly shouldn't
> this code run under DOSBox or any other emulator that is designed
> to emulate an entire PC, including real-mode and all hardware?

It's similar to an OS, but running on top of DOS.  It's hardware
access and machine control issues don't currently work under emulation,
and those yet to be implemented are unlikely to work under VM's and/or
emulation, and already it won't work with some DPMI hosts.

> If it
> crashes on DOSBox, but works fine on bare-metal MS-DOS then
> something is either wrong with DOSBox or your application.

If it works fine on bare metal, can you seriously argue it's
something wrong with my application? ...

Yes, emulators do catch some errors that aren't caught on bare metal.
But, generally, if the emulator or VM won't run it, it's a problem
with the emulator or VM, not the other way around.

> As far your application
> is concerned it should startup in 16-bit real-mode and then switch in
> 32-bit protected mode via a DPMI host regardless of whether it's running
> natively on an Intel CPU, software emulation using DOSBox or hardware
> emulation running under Virtual PC, VirutalBox or some other VM.

True, but DOS doesn't impose any restrictions upon the executing
program in terms of hardware access, or processor modes, or memory
access, etc.  Windows, Linux, and emulators do.  They prohibit and
restrict things, or fail to implement things.

> Which brings up the fact that you haven't mentioned need to block
> your code running under any of the VMs.

I do.

I block certain DPMI hosts which, when I tested them, didn't have
sufficient functionality.  I'm thinking about doing a run-time test
for that functionality, now, instead of having to each host
individually, which is many, and could, in theory, be many more ...
I already know I don't have access to some of the environments which
support DPMI, e.g., OS/2, older Windows, but found some info which
helps me.

> If you need to block it running on
> software emulatorl like DOSBox you should also need to block it running
> under hardware emulation.  If on the other hand your code works fine
> under VMs but not DOSBox then this points back to this either being a
> problem with your code or DOSBox.

...

> I think maybe going about this the wrong way.  Perhaps the best way to
> resolve your problem isn't to crudely detect incompatible environments,
> but to detect whether the hardware or other specific minimal set of
> conditions necessary for your program to run correctly are present.
> You might also be able to make your application more robust so that it
> doesn't crash when the enviroment isn't exactly what you need.

Fair enough.

The other option is to not worry about it.  If it does work under VM
or emulation, great. Windows 3.1, 98/SE can and do work under emulation.
If it doesn't work, it doesn't work.  But, that's "not nice" from the
potential user's perspective.  If something serious and unexpected
happens under VM or emulation, e.g., wiped out data on disk etc,
that would tarnish user's opinions.

So, if I have a choice, I'd rather block bad situations or potentially
bad situations.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1387

Ross Ridge  <rridge@csclub.uwaterloo.ca> wrote:
> No, under bare-metal MS-DOS a DPMI host wouldn't normally switch into
> protected mode until it was first used.  The processor wouldn't be
> running in Virtual 8086 mode (CR0.PE set) unless something else like a
> EMS emulator (eg. EMM386) put in that mode.

Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>This is because DPMI services are installed.  I.e., the
>DPMI host uses PM to provide DPMI calls, so CR0.PE should be set when
>DPMI is present.
>
>AISI, this is no different that installing a DPMI host permanently,
>as allowed by some hosts.  Once installed permanently, the CR0.PE
>should be set.

No, a permanently installed native MS-DOS DPMI host doesn't need to
switch into protected mode when its first installed, nor does it have
any reason to.  It only needs to switch into protected mode when the
DPMI API for entering protected mode is first used.  Before then under
an unemulated PC running MS-DOS the CR0.PE bit would only be set if
something else is using virtual 8086 mode to provide some other service.

Even after a DPMI host has switched to protected mode there is no
requirement that the host use virtual 8086 mode whenever it needs to
switch back to real-mode.  A DPMI host is free to reflect interrupts
using real-mode if it wants.  A DPMI host running on a 80286 has no
other option in fact.  When the DPMI client exits the host will also
normally switch the back to real-mode, not virtual 8086 mode (again,
unless something else put the CPU in that mode before hand).

You can't use CR0.PE to detect the presence of a DPMI host from real-mode
code, whether under an emulator or an actual PC running MS-DOS.  

>I'd prefer my application to exit cleanly ...
  
Yes, I made it very clear I understand that part.  Obnoxiously repeating
this requirement in detail isn't going to help you.

>> If it
>> crashes on DOSBox, but works fine on bare-metal MS-DOS then
>> something is either wrong with DOSBox or your application.
>
>If it works fine on bare metal, can you seriously argue it's
>something wrong with my application? ...

That's a false interpretation of what I wrote.  Again, something that's
not going to help you solve the problem.

>The other option is to not worry about it.  If it does work under VM
>or emulation, great.

Given the small audience any MS-DOS application would have today that
maybe your most practical option.  Your application may very well never be
run under a number of the enviroments you're concerned about.  Having an
applcation crash under an emulator, even it crashes the entire emulation,
is also usually nothing more than a minor inconvience, if that.

Other than my previous suggestions, I think your only other practical
solution would to blacklist specific known problem enviroments using well
known and hopefully documented detection methods.  Any other detection
method, general or not, is likely to be considered a bug in the emulator,
one that might get fixed one day.

					Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

#1389

On Mon, 02 Jun 2014 15:55:37 -0400, Ross Ridge  
<rridge@csclub.uwaterloo.ca> wrote:
> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:

>> I'd prefer my application to exit cleanly ...
>
> Yes, I made it very clear I understand that part.  Obnoxiously
> repeating this requirement in detail isn't going to help you.

Ross, I remember you being one of the nice guys.  Of course, I remember
"R. Weiser" being the same, but you two duked it out recently.

So, off hand, I don't recall any conflict between me and you over the
years, both on c.o.m.p. and a.o.d. back to at least 2009.  And, I
recall each of us being helpful and responsive to each others posts.
But, you seem to be a tad bit hostile in this thread and seem to be
ignoring what I've said.  I.e., you seem to be more interested in
questioning my logic or reasoning, instead of discussing possible
solutions.  Now, I'm usually all for discussing reasoning, since most
peoples logic is seriously faulty, but I already had a strong
inclination as to where I'd like to go before I posted.  I'm not
saying my reasoning isn't faulty, or won't be discarded later on.
I frequently change directions and decisions as my code develops.
And, lately, I seem to be a bit more forgetful and making more mistakes.
Since I'm aware that there are quite a few different implementation
paths I could choose, I get the impression you're wanting more
implementation details.  If I wanted to go into more implementation
detail, I would've.  I do appreciate your comments, but they seem
to be going in the wrong direction, from my perspective.  Sorry.

I was just hoping for a generic easy solution.  That simply may not
exist.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#1396

Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>So, off hand, I don't recall any conflict between me and you over the
>years, both on c.o.m.p. and a.o.d. back to at least 2009.  And, I
>recall each of us being helpful and responsive to each others posts.
>But, you seem to be a tad bit hostile in this thread and seem to be
>ignoring what I've said.  I.e., you seem to be more interested in
>questioning my logic or reasoning, instead of discussing possible
>solutions.

I could say the much same about you, except I wouldn't be lying.
I've suggested a few different ways you might go about solving your
problem, and since you've acknowledged a couple of them, you know as a
fact that I haven't been avoiding discussing possible soltuions.

I not questioning your logic or reasoning, I don't understand your logic
or reasoning.  As a result I've tried to explain certain aspects of the
problem as well as I understood it and asked questions that I hoped
would result in me gaining a better grasp of the problems you face.
Unfortunately you've mostly either ignored these questions or chosen to
misinterpret them as some sort of of criticism.

Perhaps if you had simply stated from the start you weren't willing to
share "implementation details" I would've known not to bother to try to
help you, and you wouldn't have been so aggravated by me having the gall
to try to ask you for more information.  But really I think you would've
been better served by removing the chip off your shoulder before you
posted in the first place.

						Ross Ridge

-- 
 l/  //	  Ross Ridge -- The Great HTMU
[oo][oo]  rridge@csclub.uwaterloo.ca
-()-/()/  http://www.csclub.uwaterloo.ca/~rridge/ 
 db  //	  

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.os.msdos.programmer

csiph-web