37fc39b2   
   From: marcov@stack.nl   
      
   On 2010-01-01, Rugxulo  wrote:   
   >> > So it won't run without go32.exe??   
   >>   
   >> Afaik no, but I haven't tested that in a decade. If I used dos I simply used   
   >> the install with a bunch of files in it.   
   >   
   > As mentioned, even GO32-V2.EXE needs CWSDPMI, so it's not a substitute   
   > (although old old v1's GO32 predated CWSDPMI and hence didn't need   
   > it). In v2 DPMI is always required unlike v1 where it could optionally   
   > use other stuff (XMS, VCPI). Mixing v1 and v2 apps is rare since most   
   > got updated or are redundant. (FYI, the Desqview/X toolkit used DJGPP   
   > v1.)   
      
   FPC uses v2, apparantly I'm mistaking/outdated since go32.exe is no longer   
   in SVN   
      
   > QEMM386 might've come with QDPMI (which did somewhat support virtual   
   > memory), but I think that was somewhat buggy too and limited in total   
   > RAM available for use (e.g. I'm told that QEMM 9.01 can only use 256   
   > MB max).   
      
   When I still used Dos, I used qemm, and had 64MB iirc. No problems with   
   fpc/go32v2.   
      
   >> I assume under DOS it is a CPU vs disk-I/O tradeoff. But indeed UPX   
   >> frustrating the mapping of binaries that normal OSes have doesn't apply to   
   >> dos.   
   >   
   > I'm told that DJGPPv2 apps load entirely into memory anyways via the   
   > stub (except for debug info). I guess the DPMI provider could do   
   > something with unused pages, but I don't think most do (even CWSDPMI).   
   > Not sure what DPMIONE does, for instance.   
      
   Sure, but since they are not memory mapped, they have to be loaded first,   
   and only then paged out. And that doesn't matter for UPX, if the pages in   
   mem were compressed before or not.   
      
   > UPX is probably more reliable than DoubleSpace or Stacker,   
      
   Well, I never had a antivirus balking at stacker. In dos times, I kept the   
   sources that were for reference only on a small stacker drive.   
      
   > IMHO, but I've never really tried those (too timid), so I can't say for   
   > sure. However, high cluster size (*shakes fist at 16k for > 512 MB FATs*)   
   > is annoying, so anything to stem the waste ...!   
      
   I kept one 1GB partition FAT16, and the rest FAT32 for a long time, till   
   *nix FAT32 support was mature enough.   
      
   >> Since Vista, the NT side of things finally also can postload drivers from   
   >> mass storage devices.   
   >   
   > Right, I think that's what XP had to do, use floppies for drivers. And   
   > yes, my P4 / XP updated its BIOS via DOS (I used FreeDOS). But my   
   > Vista laptop has some native Win32 app to do so from within Windows   
   > (weeeeeeiiiirrrrrrdddd!!!).   
      
   There are a lot of different schemes. Even with one manufacterer (we use a   
   lot of MSI boards at work), it varies with each generation and target   
   market.  Even reactos is slowly moving into this space.   
      
   >> They execute faster, and are tighter? Do you need any more reasons? :-)   
   >   
   > I guarantee that various modern machines vary in their speed of old   
   > code, esp. 16-bit. And it definitely won't run faster than FPC in   
   > DOSEMU x86-64!!! (That reminds me, I never did truly benchmark that   
   > 386 DJGPP compile of GCC 2.95.3 on my AMD64 vs. P4 ... I swear it runs   
   > much faster on the AMD.)   
      
   On fast computers, I never saw TP code outperform the same code in 32-bit if   
   the code was non-trivial.   
      
   >> I do have slow machines (resp 110 and 40 MHz), but they are non-x86.   
   >   
   > (joking) Don't test me, man, or I'll benchmark compile speeds on my   
   > 486.   
      
   You only say that because you know I threw out my 386SX25 last year :-)   
      
   >> > Then again, is FPC fairly fast to compile stuff?   
   >>   
   >> Compared to what? TP ? No. GCC? Yes.   
   >   
   > GCC, even old versions, is unbearable on a 486. Same with UPX. It's   
   > actually much faster to copy to floppy, go to faster machine, do it   
   > there, drink some coffee, then copy it back. (I'm told Turbo / Borland   
   > C is quite slow on an 8086 also, heh.)   
      
   I'd guess that FPC speed is roughly GCC minus two specific GCC problems:   
   - the C disease to reparse headers again and again   
   - IIRC FPC/go32v2 has AS built in, so no need to call a separate assembler.   
      
   However I don't know how big this latter difference is. When FPC got the   
   internal assembler, the speed up was gigantic, but the "older" FPC model   
   might not match the GCC model (specially if GCC pipes the assembler to AS),   
   because afaik FPC wrote it to disk.   
      
   > I know a lot of people whining about size annoys you, but in my case   
   > it's necessary (and fun / interesting, heh) because of old hardware   
   > and similar limitations (boot floppies). But I'm a rare (weird) case.   
      
   I never understood this. Size was always only a side objective, even when I   
   was on Dos with a 260MB HD. It was always primarily about getting things   
   done. After the gigabyta era, that pretty much went away, since most of   
   these factor were in the same magnitude as disk slack, and were no real   
   factor anymore. (the mp3 collections were bigger problems)   
      
   I even assisted people with 4k and 64k demo compos at a certain point, but   
   these never said it was "necessary", and never posted about their   
   self-inflicted limitations in newsgroups as if it were a general, universal   
   rule, something that has always greatly annoyed me in the residual TP   
   circles.   
      
   >> > Only for such cases (or by chance if something didn't compile with FPC)   
   >> I'm a BP7 licensee, so even then I would not use TP55.   
   >   
   > Well, 5.5 is the latest freeware version, so that's all most of us   
   > have available.   
      
   Wasn't it TP7 french?   
      
   >> The only interesting part for playing is Turbo Vision (I have a soft spot   
   >> not so much for Dos, but for fullscreen TUI programming), and I have that in   
   >> FPC for 98%.   
   >   
   > Also used by RHIDE, as you probably know.   
      
   Yes, but I never used that one, since IIRC it is a library that is GPL, not   
   LGPL. There is a BSD equivalent (by sb with an Italian sounding name)   
   though. The original version released by Borland is afaik not easily found   
   anymore.   
      
   The Pascal version was never released from copyright, so when Borland   
   started to crack down on 3rd party use of it, FPC switched to a version is a   
   backport of the freed C++ version to Pascal. This was afaik done by somebody   
   who wanted to make a graphical clone. (which meant backporting it to FPC   
   meant revisioning the whole coordinate system again, not trivial)   
      
   > BTW, that's one major complaint from DOS / DJGPP users: that XP (and   
   > moreso Vista, 7) crippled or broke RHIDE, which they preferred for its   
   > nice interface.   
      
   One can also turn it the otherway around and blame RHIDE (or its users) for   
   never updating it to support windows.   
      
   Though afaik currently the dos IDE also works on XP, and even Vista.   
      
   > I never really used it, so it's no huge huge loss to me. Still, it was a   
   > useful app. But without a maintainer and without decent OS support, you're   
   > stuck. (If only virtualization and emulation wasn't so slow and buggy and   
   > could share host OS files easily, then we could all be happy.)   
      
   I always avoided such dead ends, and moved to the next one that had at least   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)