On Wed, Jan 9, 2013 at 12:43 PM, Rugxulo <rugx...@gmail.com> wrote: > On Jan 9, 2013 11:06 AM, "dmccunney" <dennis.mccun...@gmail.com> wrote: >> >> On Wed, Jan 9, 2013 at 11:13 AM, Rugxulo <rugx...@gmail.com> wrote: >> > I thought WinME removed the real mode bootup, hence lower compatibility? >> I'm pretty sure there was still DOS underneath like in ME. Removing the >> real mode loader didn't occur till NT. > > I don't know the details, they just somehow made it slightly worse for > faster bootup (or so I thought).
That might have been on the Windows side. DOS was being used to boot Windows, so... >> The question is what DOS actually did under it. Memory >> and process management would all be on the Win side. DOS might get >> involved in file system access, but I'm not sure I see why. The same >> sort of thing could be done native from Windows instead of passed >> through DOS. > > For whatever reason, probably legacy, it was heavily reliant upon DOS stuff, > even if a big chunk was rewritten. I don't think it was as separated as > implied. <shrug> Unclear. But since the longer term goal was to get DOS out of the picture, assume it did as little as possible, and once Windows was up, everything what done by it. >> > Besides, you could still use more (kinda sorta) via EMS. It was many >> > years before extended RAM was cheap and common enough for software to >> > be useful over 1 MB. >> >> EMS used a 64KB page frame located in the block between 640K and 1MB, >> and paged memory above 1MB into it for use. > > I vaguely thought EMS 4.0 didn't need a page frame? (Where's Eric to explain > all this when you need him? Heh,) I don't recall. But the underlying issue is how you access stuff above 1MB RAM on a CPU with a 1MB address space. For the CPU to see it, it must be in the 0K - 1MB range, and that mandates copying it from RAM above 1MB into that range. This means you need a defined area in the 640-1MB range were it will be copied, and will mean you'll have to page stuff into it in chunks that will fit in that area. Sounds like a page frame to me. >> I also had a freeware utility that could grab up to 96K of unused >> video memory above 540K and map that to DOS. I had 64K available, >> because I used a Hercules card, so DOS booting thinking I had 704K. > > I think some people (rarely) use unused VGA RAM for extra conv. memory with > cmdline apps. Though these days it's uncommon to see a huge need (esp. since > lots of stuff is 32-bit pmode only, whether necessary or not). These days, I assume no one does it, as there is no need. We don't have the hardware imposed limitations that created the whole notion of conventional vs extended memory. >> On my desktop, I have 4GB RAM, but XP can only use about 3.2MB of it. >> I found a freeware RAMdisk driver that can use the RAM XP can't see, >> and have a 763MB RAMdisk seen as Z:, with a compressed NTFS file >> system. I do things like run Firefox from it. > > Very clever. I never found a reliable RAM disk for Windows. Everything I > ever saw sounded buggy, at best. Not sure why it didn't come standard (and > the old SDK example doesn't count). It didn't come standard because most folks would not understand it or use it. It would have been a support nightmare for little perceivable benefit. In my case, it was handy. The first iteration was telling Firefox to put it's cache there (which you can do in about:config.) The second iteration was putting Firefox there. The third iteration was putting the Firefox profile there. The end result was *very* quick. I had batch files run on startup and shutdown, triggered from Group Policy Manager, which could hook into the events. Firefox and the profile(s) to be used were stored on the hard drive in zip archive. On boot, they were extracted to the RAMdrive. On shutdown, what was on the RAMdrive was zipped back to disk, with the last zip file renamed as a backup copy. (It was faster to extract from zip/store to zip than to do file copy to/from.) I extended it so that I had Firefox, Aurora, and Nightly, plus Thunderbird and SeaMoney runnable that way, because I had the space to do it. The batch files had logic to let me pass a command line parm to specify exactly which product I wanted to unzip/zip, so that I could run them from a command line, too. At the moment, I'm posting from an Acer netbook that has 1.5GB RAM, so I created a 128MB RAMdrive, and just run Aurora from it. The Acer runs XP Home, which doesn't have Group Policy Manager, but I found an old freeware utility that could hook the shutdown event, and use it to trigger that batch file. The startup batch file is simply an entry in the All Users StartUp area. One minor annoyance: the old freeware utility doesn't distinguish between Shutdown and Logoff, and makes Shutdown/Restart a two step process, because it logs me off and I must shutdown/restart from there. I found another utility that may address that, but haven't played with it yet. >> >> You can still get OS/2 from an outfit called eComstation: >> >> http://www.ecomstation.com/product_info.phtml >> > >> > Yes, it sells a 5-pack of licenses for [EDIT] $149 USD or such. Not >> > sure how well the DOS support still works, but I think it claims to >> > have semi-recent Firefox, OpenOffice, Java, etc. Though I would be >> > skeptical that it wouldn't boot properly, honestly, but hopefully >> > they've fixed most of that in their [EDIT] 2.1 release. >> >> I don't see why DOS support shouldn't still work. > > Me either, but some people are busy, lazy, dumb, indifferent, etc. (cough, > NTVDM, cough). My point was that DOS support was in OS/2, and I don't believe the updates the eComstation folks did would have touched that code. If it worked before, there was no reason it shouldn't work now. And NTVDM has worked fine here, but I'm strictly doing character mode stuff. I don't care about DOS games using graphics, and didn't play them when I used DOS. >> The Firefox port is >> third-party - Mozilla officially supports Windows, OS/X and Linux - >> but the underlying code was designed to be portable. For that matter, >> I believe there are still people doing VMS ports. > > I don't think "portable" is the right word here. All modern software, for > whatever trendy (but insane) reason refuses to play nice outside of their > own niche. Usually that means (at best) the big three, even if sometimes > they (falsely) hide behind standards (e.g. POSIX). They can't even reliably > stick to anything, it's always a constant upgrade, very frustrating. Netscape made strenuous efforts to make the core Mozilla code portable. It's written in C++, so that meant "Just because you can do it in MS Visual C++, don't assume it works elsewhere, as all C++ compilers are not created equal". In practice, this meant "Confine yourself to what the HP-UX C++ compiler understands." Portability is *possible*, but has never been easy, and can't be. ______ Dennis https://plus.google.com/u/0/105128793974319004519 ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
