DOS ain't dead

hi gang.

I've got a real mode DOS app that I'm writing (x86 assembly) that needs to manipulate some data in 256k chunks. Since the data is larger than 64k segments, it's a bit of a pain to have to use normal ds/es segments and work on everything using 16 bit pointers.

So, I switched to setting gs=0 and addressing things with gs:[esi] which is significantly easier.

I'm not using memory above 1mb, and I don't really want to switch into unreal mode at the top of my program to be compatible on the most machines.

The machine I first developed this code on had absolutely no problems doing all the work it needed to do, so I thought I was done. I run the program on a different machine, and I get a general protection fault (GPF) every time I try and access any 32bit pointer.

I am admittedly *very* protected mode dumb, so my question are:
1) why does this work on some machines and not others? Are they already in unreal mode, left that way by the BIOS?
2) what is causing the GPF? I mean, is there a CPU register bit set or something in some GDT that is detecting this and causing it?
3) any other ways to do 32bit pointers? I don't want to use any libraries or extenders to do this work-the code is already 100% done, it just doesn't work the same on every platform.

thanks!

> So, I switched to setting gs=0 and addressing things with gs:[esi] which is
> significantly easier.

Don't do this. Real mode has a 64 KiB segment limit. Having (ESI+size)<=65535 will work but there is no point to do, just use plain SI.

> I'm not using memory above 1mb, and I don't really want to switch into
> unreal mode at the top of my program to be compatible on the most machines.

Removing 64 KiB segment limit needs at least 80386, sorry (so does GS).

> The machine I first developed this code on had absolutely no problems doing
> all the work it needed to do, so I thought I was done. I run the program
> on a different machine, and I get a general protection fault (GPF) every
> time I try and access any 32bit pointer.
> I am admittedly *very* protected mode dumb, so my question are:
> 1) why does this work on some machines and not others? Are they already in
> unreal mode, left that way by the BIOS?

Someone (most likely BIOS or XMS host) left the unreal mode enabled.

> 2) what is causing the GPF? I mean, is there a CPU register bit set or
> something in some GDT that is detecting this and causing it?

64 KiB segment limit, stored in the "hidden part" of segment registers.

> 3) any other ways to do 32bit pointers? I don't want to use any libraries
> or extenders to do this work-the code is already 100% done, it just doesn't
> work the same on every platform.

What does the code do ? To remove the 64 KiB segment limit, you MUST set up PM or unreal mode some way, sorry (and preferably check for 80386 before using any 8086-incompatible instruction). Relying on "someone" enabling the unreal mode for you is a very bad idea. Also ASS'uming "code 100% done" and then finding a horrible bug needing to rewrite 99% of the code to fix it is a "known issue".

P.S. what about the updated sound stuff ? I never got any mail except one with very little text and no attach.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

>
> Removing 64 KiB segment limit needs at least 80386, sorry (so does GS).

that's ok. this code is only used on pentium class machines.

>
> What does the code do ? To remove the 64 KiB segment limit, you MUST

it's an internal program for my work, so it is in a very controlled environment. You will never run this code.

It may be used on a variety of motherboards, but I know that they are all new machines.

> Also ASS'uming "code
> 100% done" and then finding a horrible bug needing to rewrite 99% of the
> code to fix it is a "known issue".

meh. I'll just add the unreal mode tweak to the start of my code-it's not that big of a deal.

I've always equated unreal mode to access above 1mb in my mind, and since I didn't really need the memory, I didn't really want to touch the CPU state either. I just wanted to do simple addressing without god awful segments that are too tiny.

The compatibility issue that I'm worried about is that it seems that a "dos boot disk" as prepared by later versions of windows, boots into some sort of emm386-like mode where the switch to unreal mode fails because the CPU has already been set in some mode that breaks my "switch to unreal" code. I've never really investigated what that problem is, but maybe adding some "switch from pmode to real mode" before switching to unreal mode might fix it.




> P.S. what about the updated sound stuff ? I never got any mail except one
> with very little text and no attach.

it may be gone. One week ago today I suffered a HDD+motherboard+power supply failure and lost everything. I have backups of all my good stuff, but I suspect that that update might have been tucked away in an unbacked up folder since it was just to test. IIRC, it was an easy change to make (just the device+vendor ID) so I can do it again once I get a new machine.

> The compatibility issue that I'm worried about is that it seems that a "dos
> boot disk" as prepared by later versions of windows

don't use such "DOS"

> boots into some sort
> of emm386-like mode where the switch to unreal mode fails because the CPU
> has already been set in some mode that breaks my "switch to unreal" code

Right But it breaks your "use of the unreal mode" too ...

> I've never really investigated what that problem is

V86 has the 64 KiB segment limit too and you can't do INC CR0 in V86 mode ...

> "switch from pmode to real mode" before switching to unreal mode might fix

YES, but "V86 to real" is difficult and depends from EMM386 version, there is no good official way ...

> it may be gone. One week ago today I suffered a HDD+motherboard+power
> supply failure

Voltage increase killed all the other stuff ???

> and lost everything. I have backups of all my good stuff,
> but I suspect that that update might have been tucked away in an unbacked
> up folder since it was just to test. IIRC, it was an easy change to make
> (just the device+vendor ID) so I can do it again once I get a new machine.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> the code is already 100% done, it just doesn't work the same on every
> platform.

Well, then, apparently it's not 100% done.

If it were me, what I would probably do is create some subroutines that use GS:[ESI] as a real mode input parameter. For example, instead of:

MOV AX,GS:[ESI]

I would create a subroutine that does all of the necessary manipulations/calculations and:

CALL MovAxGsEsi

That approach should allow you to keep most of your code intact. You could also do it with macros instead of subroutines. I don't know exactly what your code looks like, but you probably wouldn't need to create very many of these types of subroutines/macros to "fix" the program so it would work on any 386+ platform.