Mail Archives: opendos/1997/05/31/19:27:05
>>On 17 May 1997, JP Morris quarreled:
>>
>> Please remember that 32 bit and 'more memory' are NOT synonymous, >>
until last month I was quite happy to use DPMI/16, which gave me all >> the
memory I could eat, as well as the familiar seg:offset memory >> model.
>> I habitually designed my data structures around the 64k limit,
>> easy really.
>
>Yes, 32bit and more memory ARE a reality. 16bit is limited to
>16Megs of memory and no VM. 32bit is limited to 4gigs without VM
>and up to 64Terabytes with VM. Are you telling me that that is
>not "more memory"?
Yes I am. The 286 has enough selectors etc. to access 1 GIG of virtual
memory, and the DOS extender is designed to take this into account.
Consider that no mainboard I know of can handle more than 1/2 a gig.
Even ftp.cdrom.com has levelled off at this amount.
Therefore, when running on a 386 or higher, it is able to map more
than 16mb of physical memory. I did this with up to 28MB, because that
was all the memory available to me at the time. It would work with
more memory if I had that much.
>The seg:offset model is neither faster, nor intuitive, nor does
>it give you more memory. The fact that you HAVE to design your
>data structures around the 64k limit is what the problem is.
But it stops the RM code from breaking when it is compiled in DPMI16.
Also, it makes debugging easier, as you now know the segment in which
the access error occurred. In DPMI32, you just get a Page Fault
and no real idea where the problem is.
Any idea how I can verify an address in asm? IE, see if r/w to a
pointer will result in a page fault or not..
I had a function to do this in DPMI16.. seems it's not easy/possible
in flat mode.
>I frequently write programs that use arrays that are much larger
>than 64k. Anywhere from 100k to 2Megs. I have coded a lot of
>such programs for both 16bit DOS and 32bit DPMI with DJGPP.
>In DJGPP, I just do this:
[snip]
>To allocate a 2meg array on a 16bit machine you've got to
>implement EMS/XMS handling or use 16bit DPMI. 16bit DPMI works
>fine if you've GOT memory in your machine to handle all of the
>malloc's, but NOT if you need more ram than what is physically
>there. What if I need twenty 2 meg arrays? Piece of cake with
Why not? The extender I've been using will support Virtual memory,
considerably better than the DPMI32 extender I have will.
>32bit DPMI. No special coding required. Just malloc() it.
>
>Doing that in 16 bit is very difficult - regardless of how used
>to it you are. *NOT* easy *really*.
The extender can actually cope with this but it is slower, as it has
to add all this junk to do this on a 286.
>The point of creating a 32bit DOS is that it is for 32bit
>processors - which contain 32bit protected mode which is FASTER
>than the RM/PM switch time on 16bit PM, as well as the advantages
>of VM and 32bit DPMI. You certainly can't rationally argue that
>32bit DPMI is harder to code than 16bit DPMI, and you also cant
>rationally argue that a flat memory model is too difficult to
>understand and that 16bit seg:off is easier. Come on!
Some people do not NEED more than 64k contiguously.
And as I said, the advantage of keeping s:o is compatability.
No, I'm just saying that it is possible to make protected mode applications
that work on a 286. People keep forgetting that this
is possible, and I would like to remind them.
>> Even my assembler code worked after a simple recompilation.
>> In addition, it also works on 286 processors, albeit with a limit of >>
16mb on those systems. But then DOS/4GW has a 16mb limit AFAIK.
>The "4G" in DOS/4GW stands for 4gigabytes. With VM, you can have
In theory. In practice, the extender tends to cack out and not see
any more than 16Mb. I think they may have fixed this now.
>Since we are talking about creating a 32bit DOS for
>32bit computers, 286 compatibility is NOT an issue. If you want
>16 bit compatibility you will be free to use OpenDOS/16 instead.
A pity.
>DJGPP has interrupt handling.
I sunk £250+ into that compiler, I am NOT about to write that much off.
Also I prefer an IDE.. rawhIDE was not around at the time I decided
to buy BC4.5.
>> The only reason I changed was to use SVGA, I couldn't find a quick
>> way to do this in 16-bit code.
>> The 32-bit program is slower and less stable.
>Poor compiler. What is it?
Borland C++ 4.5 with powerpack and TASM 5.
Cost a pretty penny to assemble.
>> It also dies under NT and win95 dos boxes, but that's 'cause of
>> the wierd 32RTM extender.
>RTM? Is that Borland's? If so, I'm not surprised. Virtually
>ZERO software that we use today uses Borlands crappy 32bit
Deep, Final Frontier. 32RTM coders are a rare breed.
> compiler. Their 16bit compilers are fantastic (I'm a Borland
> fan) but their 32bit stuff is horrible.
I know this to my cost. However, I've got up the stability curve and
my engine runs nicely now at 90-140 fps.
>>So the moral is to remember that the 286 has a protected mode as well.
>Well, the moral is that the 386 has protected mode as well, and
>that all of the advantages that it has to offer are not available
>in the best way to DOS programs. A 32bit DOS would allow the
>full advantages that the 386+ have to be utilized to make much
>faster and more capable programs.
> > Now this sounds like the ultimate in brian dead ideas,
Oh yes. Who is "Brian Dead"?
> It wouldn't work with Real Flat programs, Ultima 7, and my demo > collection.
> When we get a 32-bit DOS, we'll also need an emergency backdoor into
> REAL-MODE, so that V86-allergic programs can be run.
>A 32bit DOS will be able to run all existing 16bit/32bit DOS
>stuff. DOSemu is a prime example of what is possible. It
>doesn't currently run EVERYTHING, but it does run a tonne of
>16bit and 32bit and mixed 16/32 DOS software including DPMI apps.
>This is entirely possible with a 32bit DOS, and probably easier.
>Just because YOU don't have a need/use for a 32bit DOS doesn't
>mean that the world should be denied one. Other people DO have a
Hang on, I never intended to deny anyone anything.
Optionality remember? But because OpenDOS was supposed to run on old
machines, and the 286 was hyped by intel as being the New Sliced Bread,
there should be a fair few 286's still around, and NATIVE support would
be nice. Although I suppose in reality, it wouldn't be used a lot.
>need and a want for one. DPMI is just a hack of 32bit PM
>services ontop of DOS. Native 32bit services would be much
>faster. Game developers would flock to such a system I believe,
>as long as it was PNP and had driver layers for video, modems,
PNP is the bane of my life! Please God, let it be _optional_!
>etc... Other developers would use it too. I have a demo of
What does this demo do? Does it die after 30 days, or what?
>Real/32 which *IS* a 32bit DOS and it IS very fast too! It isn't
>widely known due to it's price - it's aimed at industrial control
>and stuff like that.
>http://www.lii.com
>Well, that's my $10 on a 32bit DOS. You'll see it sooner than
>you think!
I'm sure I will, and I'd use it like a shot, except on my 286.
But I don't want to see my R.F.M. programs die of it, without a
backdoor to RM to let me run them.
>
>Mike A. Harris | >http://blackwidow.saultc.on.ca/~mharris
>Computer Consultant | Coming soon: >dynamic-IP-freedom...
>My dynamic address: >http://blackwidow.saultc.on.ca/~mharris/ip-address.html
>Email: mharris at blackwidow.saultc.on.ca <-- Spam proof address
>
>WABI: A commercial Windows emulator for Linux. http://www.caldera.com
** b52g AT usa DOT net ** http://members.tripod.com/~JPMorris **
Data control & IBM, Science is mankind's brother
but all I see is draining me & my Plastic Fantasic lover!
-- Jefferson Airplane
- Raw text -