Mail Archives: opendos/1997/05/31/21:15:13
On 31 May 1997, JP Morris wrote:
> >>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.
So what you are saying is that a 286 and hence it's programs as
well can access both more PHYSICAL memory AND more VIRTUAL memory
than a 386 can, and that it can also do so in an easier way with
a far superior memory model?
*GET A GRIP*
> 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.
A 286 can NOT use more than 16M of physical memory except perhaps
with some bizarre EMS board or other indirect memory scheme. On
a *3*86 you *CAN*. You really ought to get the Intel programming
books if you think that a 286 can access more memory than a 386.
What a joke!
> >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.
Great. I'm not arguing that. I'm saying that a 386 specific
DPMI32 program has access to both more PHYSICAL memory and more
VIRTUAL memory than a 286 DPMI16 program. This is common
sense, and even arguing about it is really so silly that I can't
believe I'm even giving you the time of day on this issue!
> 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.
Well, you haven't done much DPMI32 programming then. Debugging
in DPMI32 is much easier IMHO, as is the flat memory model, also
you get the added 386+ debugging features.
> 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.
Sorry, I can't help you there because I've never had that
problem. A better place to ask would be djgpp AT delorie DOT com
> >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.
Time to upgrade your DPMI32 extender then. I can't believe you
are arguing that 16bit programming and the 286 architecture is
easier/faster than 32bit programming on the 386+ architecture.
This is completely irrational.
> >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.
Precicely my point. IT IS SLOW *AND* you cant get more than 16
megs of PHYSICAL RAM. Some applications DEMAND more than 16 megs
of RAM for performance reasons, or for realtime data acquisition,
or various other computational reasons.
> >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.
THEN THEY WONT USE THE 32bit DOS! Likewise some people NEED more
power than a 16 bit system can provide, AND *NEED* more than 64k
at a time. That is why there is something BETTER - 32bit flat
memory DPMI.
> 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.
I'm not disagreeing with that statement. I'm disagreeing that
286/16 is BETTER for ANY purpose except compatibility with 286
processors. In other words, the ONLY reason to use 16bit DPMI is
if you MUST have compatibility with that architecture over all
else, or don't HAVE a decent 32bit DPMI program. The latter is a
lame excuse because DJGPP is *FREE* and is a wonderful package.
> >> 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.
Well, I didn't say that it did support a full 4G, you cut out my
full comment. CWSDPMI supports a much greater memory pool.
Since the source is available, it can be fully extended to the
limits of the architecture by a few changes in a makefile or
#define.
As for your "assembler" code working out of the box - if you have
legacy code, and don't want to recode it, that is fine. BUT it
DOESN'T mean that it is better than if ported to native 32bit
code.
As I said before, the only reason to use 286/16 code is for
compatibility with that processor and/or legacy code allready
written for that processor.
Also, I'm not aware of a FREEWARE or GPL DPMI16 compiler (but I'm
not denying the existance of one either).
> >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.
Why is it 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.
You paid 250+ for DJGPP? You got ripped off, I paid $0.00. I
paid $260 for BC4.0 and TASM 4.0.
The fact that you paid money for a compiler/extender/whatever,
doesn't mean that it is the best development environment, nor
that it creates the fastest apps. I still use BC too, but not
because I bought it and want to get my money's worth - thats
crazy. I'm hardly going to struggle with a 4 meg array in 16bit
mode when my program is ALWAYS going to run on a 386 and I have
DJGPP installed!
> >> 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.
Well, likewise I stated that I blew $260 on 4.0 of both. That is
a pretty penny too. I don't USE 4.0 though, I use 3.1 because of
the DOS IDE, and ease of use programming DOS progs. If a DOS
prog needs to screw around with segments to bypass memory
limitations or MK_FP and shit like that, I head straight for
DJGPP.
> >> 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.
Yeah, and not very bright if they paid the extra $60 Borland
wants for the crappy extender!
> > 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.
What engine? Is it 16bit or 32?
> >>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"?
Typo. Now we're at the spelling/grammar flame stage? Figures...
> > 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.
OpenDOS/32 isn't going to REPLACE OpenDOS/16. ELKS is a PRIME
example of the NEED and DEDICATION of programmers for the 286 and
less. OpenDOS will be no different. Also, look at the
dedication to older architectures of all of the emulator authors.
Did they dump the Commodore 64? NO! what about the Vic-20? NO!
Will the 8086 die? NO!
You really shouldn't be so scared of new technology destroying
old technology as the emulators out there prove that legacy
machines NEVER DIE! Look at the Apple II emulator or the atari
2600 emulator! I even downloaded a brand NEW atari 2600 game
that someone wrote a year or so ago called "Okie Dokey". That's
what I'd call dedication!
> >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_!
Well, I dislike PNP for the simple reason that EVERY single
experience that I've had with it has been a nightmare, however,
it is here, and new machines come standard with it. If OpenDOS
doesn't support new technology, then it will DIE. One thing it
CERTAINLY won't do however is REQUIRE PNP so why even suggest
that? It's rediculous.
> >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?
It lets you try it out. It *IS* limited, but it lets you see
what is available for DOS! It has 8 virtual consoles. Each
console can run either a DOS program (16/32/whatever) *OR* a
WINDOWS program! The multitasking is fantastic, and there are a
lot of cool utilities, etc... but why take my word for it - the
demo was FREE from logan industries. Just drop them an email
requesting a demo CD and literature for Real/32.
> >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.
Well, before you speak, you should research. Don't ASSUME that a
32bit DOS means NO 16bit DOS apps because it isn't true, and
would NOT be "DOS" it would be a totally different operating
system completely incompatible with DOS. You DONT need a
"backdoor" to realmode either. Linux runs in 32bit protected
mode, DOSemu runs in a VM. Linux HARDLY lets DOSemu switch to
REAL mode!!!! Nonetheless 16bit real mode programs run just
fine. If anything there are MORE 16bit mode programs that work
100% than there are 32bit ones! Therefore backwards
compatibility with 16bit is much easier. Also, since the
majority of legacy software is 16bit, it would certainly be the
first thing to be developed completely.
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
LINUX: Lost access to your keyboard after a game? Email me for fix.
- Raw text -