From: MORRIS JP Date: Mon, 2 Jun 1997 16:44:53 +0100 Message-Id: <199706021544.QAA16966@mug> To: mharris AT blackwidow DOT saultc DOT on DOT ca Subject: 32 bit DOS - let's bury the hatchet. Cc: opendos AT delorie DOT com Precedence: bulk Mike Harris wrote: > 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 No, I did not say this. > than a 386 can, and that it can also do so in an easier way with > a far superior memory model? I am saying that it is a viable solution. I am not suggesting that it is an optimal solution for all possible cases. > *GET A GRIP* > > A 286 can NOT use more than 16M of physical memory except perhaps > with some bizarre EMS board or other indirect memory scheme. On I'm not talking about physical memory. Physical memory on a real 80286 is stuck at 16MB because of the 24 address line scheme. What I am saying, is that a 286 DPMI program, running on a 386 can take advantage of more memory in a transparent manner. What happens is something like this: The extender sees the 386 and says "Look, there is a 386. We have 32 address lines, let's map the extra stuff into selectors at it's needed." Effectively, it pretends that the extra memory is virtual memory. The application doesn't care where it comes from. > 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. I never, ever said this. I never implied that 1 gig is larger than 4 gig, or 64TB. I did say that 1 gig is more than most systems can actually handle in terms of motherboards. ... > 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 Granted, but 286 programs can still eat all the memory you throw at them until some manufacturer makes a board capable of > 1 gig. Anyway, the 64MB limit is more likely to affect 286 or 386 extenders first. > > 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 This is correct. I have not done much DPMI32 programming yet, as it is just over a month since it became viable for me to do so. I am open to suggestions on debugging, although in most circumstances, if one of my programs crashes, it crashes _big_, and takes the debugger down with it. Not neccessarily something to be proud of. > in DPMI32 is much easier IMHO, as is the flat memory model, also > you get the added 386+ debugging features. [checking for page faults] > 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 Fair enough. > > 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 I will upgrade it as soon as the Freeware replacement stabilises. It should also work under NT at last. > you are arguing that 16bit programming and the 286 architecture is > easier/faster than 32bit programming on the 386+ architecture. > > This is completely irrational. You know, you're right. But I belong to a school of thought that attempts to make the best use of whatever hardware is available. A 286 PM program was something considered impossible not long ago, so it seemed like a fun thing to do. Not necessarily rational. I guess I've been sticking my head in the 286 for too long. > > 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. One of the things I have always considered is a lack of skill in programmers. For example, why must win95 have such a vast amount of memory to perform such simple tasks? Why is DOOM-95 even slower than Quake? Why is Quake so slow? I have seen programs written long ago, which perform most of the functions of the Quake engine on an XT, but without texturemapping. Wolfenstein does texture mapping. Just add these together, and Quake for a 286 or at least a 386 doesn't seem so far-fetched. For all this time, I've been trying to optimise code to run on older machines. That is my interest in 286PM, although they don't necessarily run well. I'm not saying that all tasks which have to use flat memory are badly-designed, in a lot of cases this is the only way to get it done. But is it _always_ strictly necessary? [DPMI16 is only useful if..] > 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. DJGPP was unpleasant at the time of my purchasing BC 4.0, which is why I chose the Borland route. If I was doing it again now, I'd choose DJGPP. > 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. > 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. > 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? No, it is a pity that a 286-protected mode build of OpenDOS is not likely. That is, it would be a pity if 286 owners ended up running 8088 code forever.. > >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. No, I paid 250 pounds sterling for BC 4.5 and all it's add-ons, and yes I do feel ripped off sometimes. > Ipaid $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 ^^^^^ It's an emotional reaction from someone who got ripped off by Borland. Once they special-offered me Delphi for 1 Grand sterling.. some chance :-). Sent me an ultimatum. "Buy Delphi or else.." > mode when my program is ALWAYS going to run on a 386 and I have > DJGPP installed! > > 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! Easy to say that with hindsight. Most of the DPMI32 programmers got stuck in Borland's trap. :-( > > 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? Since you ask, I tested the technology behind it in Real-mode, using BC v2.0. Then I converted it to DPMI-16. It ran at peak 90fps on a K75. About two months ago, I decided to convert it to run in 15-bit colour. The best way to do this was to use 128k framebuffers, instead of 64k. The most efficient way to do this was to switch to DPMI-32. Now I have converted it to DPMI-32 over the last two months. It still runs at 90fps, and 160fps on a P150, but this is _not_ because it is a 32-bit program, it is because I have been optimising the hell out of it to get it fast again. Of course, using 386 opcodes in the assembler helps a great deal. > > Oh yes. Who is "Brian Dead"? > Typo. Now we're at the spelling/grammar flame stage? Figures... No, we are not and it does not. It was actually a misguided attempt to inject a bit of humour into what was rapidly becoming nasty. I was trying to lighten up. Now, RFM programs... > > 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 No, that is my point. A 32-bit dos will make use of handy V86 features. The RFM programs _cannot_ survive V86 mode, which is why the RFM memory model is used even less than 286PM. I agree and acknowledge that most 16 and 32 bit programs will run in OD/32, (getting doom to work in multitasking enviroment is a useful benchmark). After all, DOS spends most of it's time in V86 mode ayway. But RFM is a special case. There are commercial programs out there which DO use RFM, and they will not run under OpenDOS/32, Win95, NT, linux, or even EMM386 (any version). This is why we'd want an emergency backdoor, although dual booting to OD16 would be one (wasteful) solution. Before you ask, I haven't tried RFM with linux yet, as Dosemu is not running at this stage. AFAIK, the only way RFM programs can run is under True real-mode. Unless linux or OD/32 does all it's DOS compatability by mode-switching instead of V86, (major performance dent!) it will not work correctly. > >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 Oh good. I'll have to look that up. > 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! Point conceeded. Thanks. > >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, That's normally the motive for disliking PNP. :-) > it is here, and new machines come standard with it. If OpenDOS > doesn't support new technology, then it will DIE. One thing it I know, I know. If I was forced to use a PNP card, I'd use ICU, a brutal utility from Intel which is buggy and badly designed, but does add PNP capability to DOS. Possibly this technology could be licenced, as the program is already free. > CERTAINLY won't do however is REQUIRE PNP so why even suggest > that? It's rediculous. It is not ridiculous, the possibility is VERY REAL. Windows 95 actually went down this path. There is no way to disable the PNP subsystem, which in fact can cause serious, irresolvable conflicts that nail the entire system stone dead. If it was optional, (disable PNP manager [Y]) I could use Win95 if I wanted. > > 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. I probably will. > 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.