Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Hi, On Thu, Mar 15, 2012 at 8:09 PM, Jack gykazequ...@earthlink.net wrote: But, there are a LOT of us who do not use DJGPP and yet COULD use a bit more UMB space, to load more/bigger drivers etc. In fairness, DJGPP is quite widespread, at least in apps, not necessarily developer tools, though I admit there are alternatives. It's hard for me to not respect all that DJGPP has accomplished. But yeah, you have a point. Nor do I use JEMM386 in everyday work, as I run a pure V6.22 MS-DOS and do not need the extra features. I am only saying that you ought not so-quickly dismiss the idea of using an EMM driver. They DO have their uses! Yes, but not necessarily for EMS. Not that I hate EMS or prefer XMS or DPMI or anything, just saying, sometimes it's less crucial than it seems. I'm glad we have it, obviously, but I don't use it a lot these days. But that's just my own weird (temporary?) habits. Maybe I should load it up automatically for a week or so and see what happens. :-) I must DISAGREE: EMM386 may have been written for EMS memory but it EVOLVED into Microsoft's protected-mode provider and was NEVER merely a backwards compatibility EMS handler! MS doesn't even support EMS at all in NTVDM these days. I know Win9x had it, but nowadays you have nothing but DPMI. This is why all the various DPMI limits and bugs are so painful, there is literally nothing else. But their code is old and bitrotted and nobody cares anymore, so it is left to die. And Win64 just speeds that up by focusing on other, newer things. ONly a FEW factors, since a protection trap is a PROTECTION TRAP! for any AMD CPU as well as for Intel CPUs! All vendors watch this type of compatibility VERY closely, which is why I have NO qualms re: buying an AMD CPU. They are usually less expensive and WORTHWHILE!! I know there are a few minor quirks, but yes, AMD deserves high praise for its products. In a way, it's a great idea (and one that PatV often mentioned) to bring DOS into the 21st century, but it basically means rewriting everything, which is very very unlikely to happen. (Kickstarter, anyone?) Tons could be improved (and I'd expect compatibility to be a top goal, too). However, I know I'm dreaming here, it won't happen. I don't think it is as NECESSARY at you think! It's not necessary at all, but when the current crop of computers die out, we will buy new ones, and they will be less compatible, etc. etc. So eventually everything dies. It's kinda crappy, I don't really like it. Can't we just have some stability? No, apparently not. It's all a chase after the wind. (And don't tell me about Windows or Linux, they aren't stable, lots of barely old software doesn't work anymore.) We need NO more hardware, CERTAINLY NOT any damned 64-bitters having 64-GB of memory, when in fact Intel/Microsoft never REALLY learned to use 32-bit or even 16-bit systems all that well! Same for DOS -- USE IT a little BETTER, and maybe it CAN do the job, EXACTLY as it is now!! I agree, but nobody else does. Like I said, some things (e.g. GCC) work quite well at most things but are horribly inefficient and quite kludgy and bloated. Has C really changed that much? No. Optimizations? Portability? No. It's just over time things just get worse. But I guess their goals are different. Surely Win7 should never need 1 GB just to function, but that's where we're at, and it hasn't changed. What can you do? Even Fedora or Ubuntu need a lot. :-/ Jack, perhaps you should read what Niklaus Wirth had to say back in 1995, Plea for Lean Software. Unfortunately, it seems that nobody listened. (Obviously we DOS users appreciate small size and footprint, but apparently no one else does!) http://www.inf.ethz.ch/personal/wirth/Articles/LeanSoftware.pdf -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Rugxulo, Nor do I use JEMM386 in everyday work ... I am only saying that you ought not so-quickly dismiss the idea of using an EMM driver. They DO have their uses! Yes, but not necessarily for EMS ... Obviously not, as there are few actual EMS memory applications still around and worth using. When I say EMM driver, I refer to JEMM386/ JEMMEX or equivalents like EMM386/QEMM/386MAX/etc., which all provide DOS support for protected-mode and its features. I must DISAGREE: EMM386 may have been written for EMS memory but it EVOLVED into Microsoft's protected-mode provider ... MS doesn't even support EMS at all in NTVDM these days -- Sad, that they flatly abandoned their own MS-DOS, and so EMM386 is still 130K of mostly-obsolete trash. JEMMEX saves about 100K, due to Japheth having paid attention, where Microsoft now pays NO attention to EMM386! I know there are a few minor quirks, but yes, AMD deserves high praise for its products. I agree. My AMD CPU is unable to do a backward MOVSD (D bit set) if both move addresses do not start on 32-bit boundaries; runs SLOW and gives data errors! So, UIDE2 does only a 16-bit MOVSW in backward mode which is O.K. at the point I use it. Otherwise, a few rumors which I respect in UIDE/UIDE2, but really NO serious problems using an AMD CPU. In a way, it's a great idea (and one that PatV often mentioned) to bring DOS into the 21st century ... I don't think it is as NECESSARY at you think! It's not necessary at all, but when the current crop of computers die out, we will buy new ones, and they will be less compatible, etc. etc. So eventually everything dies. It's kinda crappy, I don't really like it. Can't we just have some stability? No, apparently not. It's all a chase after the wind. (And don't tell me about Windows or Linux, they aren't stable, lots of barely old software doesn't work anymore.) I agree entirely. What would we do without computer salesmen??!! We need NO more hardware, CERTAINLY NOT any damned 64-bitters having 64-GB of memory, when in fact Intel/Microsoft never REALLY learned to use 32-bit or even 16-bit systems all that well! ... I agree, but nobody else does ... Pperhaps you should read what Niklaus Wirth had to say back in 1995, Plea for Lean Software. Unfortunately, it seems that nobody listened. I did read Wirth's comments, and he is essentially correct, although he LOST my attention by making his project specific for his needs, e.g. it includes an object-oriented language (YECCH to me, even more than C). And I agree, nobody listened -- Microsoft had to continue feeding its 1500 Win/NT programmers and its maybe 500 DOS programmers at that time! They remind me of the old Jason Robards and Barbara Harris movie titled A Thousand Clowns! Best wishes, Jack R. Ellis -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Hi, On Fri, Mar 16, 2012 at 4:27 AM, Jack gykazequ...@earthlink.net wrote: We need NO more hardware, CERTAINLY NOT any damned 64-bitters having 64-GB of memory, when in fact Intel/Microsoft never REALLY learned to use 32-bit or even 16-bit systems all that well! ... I agree, but nobody else does ... Perhaps you should read what Niklaus Wirth had to say back in 1995, Plea for Lean Software. Unfortunately, it seems that nobody listened. I did read Wirth's comments, and he is essentially correct, although he LOST my attention by making his project specific for his needs, Well, the big problem is that there are too many derivatives, and it's hard to get it booting (at least for me). Also, yeah, it pretty much assumes you do everything its own unique way, which can be a bit too weird sometimes. (His initial 32-bit Ceres machine back in 1986 was something like 4 MB of RAM and 40 MB hard disk, not exactly a behemoth like these days.) e.g. it includes an object-oriented language (YECCH to me, even more than C). In fairness, Oberon is basically very very similar to Modula-2, so the OOP stuff is very minimal and completely optional, so you don't have to use it at all. It definitely does not force you to cram everything inside a class with methods. And I agree, nobody listened -- Microsoft had to continue feeding its 1500 Win/NT programmers and its maybe 500 DOS programmers at that time! They remind me of the old Jason Robards and Barbara Harris movie titled A Thousand Clowns! Too big for their britches, perhaps. Too focused on money, too trendy. But what can you do, that's what sells. I guess it's too naive to expect most people to focus more on technology for its own sake rather than commercial reasons. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
We need NO more hardware, CERTAINLY NOT any damned 64-bitters having 64-GB of memory, when in fact Intel/Microsoft never REALLY learned to use 32-bit or even 16-bit systems all that well! ... I agree, but nobody else does ... Perhaps you should read what Niklaus Wirth had to say back in 1995, Plea for Lean Software. I did read Wirth's comments, and he is essentially correct, although he LOST my attention by making his project specific for his needs, Well, the big problem is that there are too many derivatives, and it's hard to get it booting (at least for me). Also, yeah, it pretty much assumes you do everything its own unique way ... Never knew a college professor who thought any differently!! ... e.g. it includes an object-oriented language (YECCH to me, even more than C). In fairness, Oberon is basically very very similar to Modula-2, so the OOP stuff is very minimal and completely optional ... Glad to hear that, but it changes little re: my opinion of Wirth's system. And I agree, nobody listened -- Microsoft had to continue feeding its 1500 Win/NT programmers and its maybe 500 DOS programmers at that time! They remind me of the old Jason Robards and Barbara Harris movie titled A Thousand Clowns! Too big for their britches, perhaps. Too focused on money, too trendy. But what can you do, that's what sells. Not to ME, it doesn't! I shall KEEP my 5-year-old AMD 3000+ with its only 1-GB of regular SDRAM (not SDRAM2 or SDRAM3) for as long as I can. Runs fine for me, has for 5 years, and saves me all that MONEY v.s. being forced by Intel/Microsoft into buying what THEY think I should buy, same as my old 1994 V6.22 MS-DOS and 1996 V4.0 Win/NT have also saved me a LOT of money! In my day-to-day life, I follow a simple rule: If somebody has to write or E-Mail me a letter, call me on the telephone, or worst-of-all come knocking on my door, WHATEVER they are pushing I absolutely DO NOT want! I paid attention in school and thus can make MY OWN decisions re: what to buy and when! Same thoughts about my computer -- Intel and Gates Co. will NEVER push me into buying their latest (usually high-cost) trend items! Sad how more people do not see things this way and get Sold down the river so often! We need such things like AHCI and Vista like we need the PLAGUE! -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] zbigniew system stability with different shells, kernels and drivers
Hi Zbigniew, Jack I must conclude that the problems you are seeing, using JEMMEX and UIDE2, are NOT caused by those drivers. Not necessarily. They just NOT happen on BOTH hardwares, Zbigniew's and Jack's. Could be A20 or UMB being weaker on one system than on the other. Still a problem exists. Because UIDE uses XMS more often than FreeCOM, you are in trouble faster with UIDE than without if A20 is bad. Other params for XMS and/or EMS drivers might help here? Also, SHELLHIGH 4DOS may also use other UMB areas than FreeCOM. Try with SHELL instead, it could be a bad UMB that just happens to be not used for critical data in one shell but is used in the other, or maybe the OTHER drivers end up in a bad UMB area with different shell, as the shells have different size? Try X=TEST or so? Eric -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Problem (seems to be) solved. Formerly I was using a line: INSTALLHIGH=C:\FDOS\BIN\UIDE2.SYS ...and this made problems. When I replaced INSTALLHIGH with DEVICEHIGH - there are no problems anymore. I thought, that INSTALL and DEVICE keywords are synonyms for fdconfig.sys file, since I was very long time using various combinations, like e.g.: DEVICE=C:\FDOS\BIN\JEMMEX.EXE (DEVICE for EXE-file) INSTALLHIGH=C:\FDOS\BIN\XMGR.SYS (INSTALL for SYS-file) ...and it just works with no problems whatsoever - unfortunately, not in UIDE*-s case. But now I see, there must be some difference indeed., and for *.SYS files should be DEVICE, and for COM/EXE - INSTALL. The opposite can work, but doesn't have to. Sorry, if I made some more confusion. -- Z. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Problem (seems to be) solved. Formerly I was using a line: INSTALLHIGH=C:\FDOS\BIN\UIDE2.SYS ...and this gave problems. When I replaced INSTALLHIGH with DEVICEHIGH -- there are no problems anymore. I thought, that INSTALL and DEVICE keywords are synonyms for fdconfig.sys file, since I was very long time using various combinations, like e.g.: DEVICE=C:\FDOS\BIN\JEMMEX.EXE (DEVICE for EXE-file) INSTALLHIGH=C:\FDOS\BIN\XMGR.SYS (INSTALL for SYS-file) ...and it just works with no problems whatsoever - unfortunately, not in UIDE*-s case. But now I see, there must be some difference indeed., and for *.SYS files should be DEVICE, and for COM/EXE - INSTALL. The opposite can work, but doesn't have to. I had a LONG set of comments for you, but I will save them. The DEVICE command requires a .SYS file, but can be used for a file with a .SYS header at its start, e.g. RDISK.COM and JEMMEX.EXE. As far as I know, the INSTALL command is absolutely NOT for any pure .SYS files! If you want to load a .SYS file after CONFIG has been run, use a DEVLOAD command in your AUTOEXEC.BAT file. UIDE/UIDE2/UIDEJR are .SYS files, and always will be, as the need for loading them later by DEVLOAD seems to be limited to FreeDOS, that does not provide HMA space for drivers before CONFIG.SYS has been run. Other DOS systems DO make HMA available during CONFIG and so I see no-big-need for the UIDE drivers to load later or be unloaded, despite the many unload FREAKS in this world!They are hard SYSTEM drivers -- Why, after using UltraDMA and caching, would anyone ever WANT to unload such a driver??!! -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
2012/3/15, Jack gykazequ...@earthlink.net: Why, after using UltraDMA and caching, would anyone ever WANT to unload such a driver??!! Well, yes, this is the question. -- Z. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Zbigniew, Why, after using UltraDMA and caching, would anyone ever WANT to unload such a driver??!! Well, yes, this is the question. Do tell THAT to all the unloadable driver FREAKS, who have beset me in past years about making UIDE unload! I am glad that you are on the air (running O.K.) with the UIDE drivers! You can decide if your system works best using UIDE (goes up to 4-GB caches) or using UIDE2 (about 5% faster with protected-mode). In either case do try loading them in AUTOEXEC.BAT with -- DEVLOAD /H C:\...\UIDE2.SYS /S511 /H /D:CDROM1 Using DEVLOAD permits the driver to keep only 928 bytes of data, entry/exit routines and stack in upper-memory. All else, including UIDE2's binary-search table, can be moved into unused HMA space and run from there.As I noted before, the FreeDOS kernel doesn't make HMA space available to drivers until AUTOEXEC is run, so you must use a DEVLOAD command in AUTOEXEC, if you want UIDE2 to run with FreeDOS from the HMA. Then, you will be able to amaze friends with your only 928-byte disk/CD/DVD/ caching driver -- Just tell them you know a Sorcerer! Best wishes, Jack R. Ellis -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Zbigniew, Forgot to mention in my last post that if you do run UIDE2 in HMA space with /H, you must limit the cache to about 325-MB, and with /HL to about 420-MB, since FreeDOS does not have as much free HMA as my V6.22 MS-DOS does. Unlike V7.10+ MS-DOS, old V6.22 has no FAT32 nor long filename logic limiting its HMA! The UIDE driver has no such HMA limits, as it places its binary-search table in XMS memory. Jack R. Ellis -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
But personally I can't see a reason to dispose of such low footprint driver on the fly; that's why I wrote this is the question. Yes, I'm going to use UIDE2 rather than LBACACHE exactly because it takes less memory. BTW: there are many (of course, it's very good to have a choice :) drivers for similar purposes available for FreeDOS now; it would be useful, if the creators made one day some kind of comparison table, which one of them can do better for in which situations. E.g. JEMMEX - or HIMEMX/JEMM386? If the latter - when? Etc. Just tell them you know a Sorcerer! Wizard is a better fit ;) - Sorcerer means the evil kind. -- regards, Z. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Zbigniew, But personally I can't see a reason to dispose of such low footprint driver on the fly; that's why I wrote this is the question. Understood, and I do agree with you! XMS and HMA usage were both suggested to me by Tom Ehlert in 2003, when I wrote my first UDMA. Yes, I'm going to use UIDE2 rather than LBACACHE exactly because it takes less memory. BTW: there are many (of course, it's very good to have a choice :) drivers for similar purposes available for FreeDOS now; it would be useful, if the creators made one day some kind of comparison table, which one of them can do better for in which situations. E.g. JEMMEX - or HIMEMX/JEMM386? If the latter - when? Now that JEMMEX is available, HIMEMX + JEMM386 and XMGR + JEMM386 are historical curios only, and JEMMEX should be preferred. As to the caching drivers, LBAcache may still be a hair faster than even UIDE2, since LBAcache has all its tables in real memory, while UIDE2 still has its main cache-data table in XMS (LBA address, unit number, block count for each cache block). LBAcache and UIDE/UIDE2 all use Write Through caching (no delayed writes) and thus are small. A Write Back cache such as SMARTDRV or Norton NCACHE2, does do writes with a delay, so that if the same block is written 2 or 3 times in sequence, as with compilers and data-bases, the cache saves time by writing the last data over a 0.5 to 1-second time frame to the disk. They are FAR more complicated, as they need hooks on more of the DOS system! For most of us, I feel UIDE with its 1400 bytes of extra logic beyond the actual driver, 800 for UIDE2, is a more reasonable caching idea and provides fully-adequate speed, especially as both can do UltraDMA directly to/from the actual XMS cache buffers! That saves time that a Write Back cache, with separate drivers, might not be able to do! Just tell them you know a Sorcerer! Wizard is a better fit ;) - Sorcerer means the evil kind. Not always: King Arthur's Merlin the Magician is usually portrayed as a Good Guy, and it is him I usually have in mind. If I want to be seen as a bit more evil, I say Witch Doctor or Hoodoo Man!! Best wishes, Jack R. Ellis -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
2012/3/15, Jack gykazequ...@earthlink.net: Now that JEMMEX is available, HIMEMX + JEMM386 and XMGR + JEMM386 are historical curios only, and JEMMEX should be preferred. That was my guess: maybe some of them can be even seen as 'obsolete' by now. As to the caching drivers, LBAcache may still be a hair faster than even UIDE2, since LBAcache has all its tables in real memory, while UIDE2 still has its main cache-data table in XMS (LBA address, unit number, block count for each cache block). LBAcache and UIDE/UIDE2 all use Write Through caching (no delayed writes) and thus are small. A Write Back cache such as SMARTDRV or Norton NCACHE2, does do writes with a delay, so that if the same block is written 2 or 3 times in sequence, as with compilers and data-bases, the cache saves time by writing the last data over a 0.5 to 1-second time frame to the disk. They are FAR more complicated, as they need hooks on more of the DOS system! Actually, it was a bit surprising to me, that I still need a software cache, while using hardware, which - like for DOS requirements - is really very fast. Unfortunately, using no caching at all, I noticed pauses (3-4 seconds), that occur although not to often, but frequently enough to be irritating (the controller's LED is on at that time). Well, perhaps the NVIDIA SATA isn't the best fit for DOS. For most of us, I feel UIDE with its 1400 bytes of extra logic beyond the actual driver, 800 for UIDE2, is a more reasonable caching idea and provides fully-adequate speed, especially as both can do UltraDMA directly to/from the actual XMS cache buffers! That saves time that a Write Back cache, with separate drivers, might not be able to do! I agree, thanks for providing such nice thing. :) Just tell them you know a Sorcerer! Wizard is a better fit ;) - Sorcerer means the evil kind. Not always: King Arthur's Merlin the Magician is usually portrayed as a Good Guy, and it is him I usually have in mind. If I want to be seen as a bit more evil, I say Witch Doctor or Hoodoo Man!! Just out of curiosity ;) , made a quick search on this subject; some specialists wrote about this: - “Merlin wore many hats: he was a wizard or sorcerer, a prophet, a bard, an adviser and a tutor,” ( http://claricemoran.wikispaces.com/Merlin ) ...but some other authority prefers to see him as a wizard rather: http://www.castles.me.uk/merlin-the-wizard.htm - anyway, the other one described the difference: What makes a wizard different from an enchanter, a magician, a sorcerer, a thaumaturgist, etc.? Well, sorcerers are sometimes evil, `black magicians' (i.e., practitioners of black magic)... But in general, not a lot, although fantasy authors and FRPGs might use the names with narrower meanings. [..] Another example: `The difference between a wizard and a sorcerer is comparable to that between, say, a lion and a tiger, but wizards are acutely status-conscious, and to them, it's more like the difference between a lion and a dead kitten.' ( http://galatea.meccahosting.com/~a0006753/wizards%20world.htm ) In conclusion: wizard writes extraordinary drivers - sorcerer creates e.g. very interesting... viruses. ;) Forgot to mention in my last post that if you do run UIDE2 in HMA space with /H, you must limit the cache [..] Thanks, I think, that it could be worthy to add this comment to UIDE-s readme.txt. -- regards, Zbigniew -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Hi, On Thu, Mar 15, 2012 at 2:48 PM, Zbigniew zbigniew2...@gmail.com wrote: Actually, it was a bit surprising to me, that I still need a software cache, while using hardware, which - like for DOS requirements - is really very fast. Unfortunately, using no caching at all, I noticed pauses (3-4 seconds), that occur although not to often, but frequently enough to be irritating (the controller's LED is on at that time). Well, perhaps the NVIDIA SATA isn't the best fit for DOS. DOS doesn't use SATA anyways (AFAIK), only IDE compatibility mode. It would be even slower without UDMA or a software cache. As to why you need it, it's because (quoting Martin Reiser) Software gets slower faster than hardware gets faster. Also known as What Intel giveth, Microsoft taketh away. But actually even DOS software gets slower and bloatier over time. I hate to bring up DJGPP, one of my favorite things, but take a look at CC1.EXE (C compiler proper) over the years, quite a difference!!! And don't forget the differences in x86 families (and software optimizations) and L1/L2/L3 cache sizes (among a billion other things). It all heavily varies (and GCC has both pros and cons). You'll always have speed issues if you don't watch what you're doing. Floppy, USB, CD-ROM, hard drive are all much slower than RAM (use RDISK!). -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Hi, On Thu, Mar 15, 2012 at 3:39 PM, Jack gykazequ...@earthlink.net wrote: I have saved XMGR for real mode users who run UMBBCI first, followed by XMGR. In that case, XMGR is able to read UMBPCI's table of UMBs and can load there directly, which also uses 0 low-memory like JEMMEX. UMBPCI cannot map the B000h-B7FFh space (black and white graphics, that no one uses any more) into upper-memory. But DOS games players, and others who want real-mode speed (like me!), normally get over 128K upper-memory, which is O.K. for our needs. So, UMBPCI + XMGR is the only useful old configuration -- Most users should run JEMMEX alone. Unless you need EMS, you don't truly need JEMMEX itself. Last I checked, I don't think it would let you run XMS only unless you did NOEMS, and even that still left you in V86 mode. Granted, it should be fine for most software, but it's not a perfect solution (not that one probably exists anyways). Nowadays, it does seem most DOS software is either real-mode or 32-bit DPMI, though some XMS creeps in too. And CWSDPMI won't use 4 MB pages if you're running EMM386, so that's a speed drop (but then probably doesn't use those anyways unless you're making huge allocations as there are other minor compatibility nits). It all depends on what you're trying to do. Turbo C uses EMS (if found) by default, and of course DJGPP uses DPMI (which uses whatever it can find). Obviously there's no comparing the two in speed, but the point is the same: different approaches to the same problem. Feel free to benchmark them, but the results are unlikely to matter much unless you do it a lot in succession. DOS also retains its single-sector directory handling, designed back in the early 1980s, when memory was EXPENSIVE and buffers were kept small. Two of the biggest hurdles to using DOS software often seem to be memory management and file system quirks. I know there are other minor things too, but those are the ones that seem to come up a lot. But with DPMI and FAT32, that's fairly moot, thankfully. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
2012/3/15, Rugxulo rugx...@gmail.com: DOS doesn't use SATA anyways (AFAIK), only IDE compatibility mode. It's still much faster than the hardware, that I was using at - say - 1991. The HDD itself has quite large hardware cache (16 MB - incredibly large space compared to 640 KB). But actually even DOS software gets slower and bloatier over time. Maybe I wasn't clear enough in my writing: that pauses occur, for example, even when I've got to save just edited autoexec.bat - then we're talking about 2 KB (or so) text file. Not sure, but my guess is hardware problem. -- regards, Zbigniew -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Actually, it was a bit surprising to me that I still need a software cache ... Well, perhaps the NVIDIA SATA isn't the best fit for DOS. DOS doesn't use SATA anyways (AFAIK), only IDE compatibility mode. It would be even slower without UDMA or a software cache. As to why you need it, it's because (quoting Martin Reiser) Software gets slower faster than hardware gets faster. Also known as What Intel giveth, Microsoft taketh away. Intel giveth NOTHING, and followeth only All we want is MONEY!, same as Gates Co.! In my opinion, absolutely NO excuse for AHCI that a better-written Windows driver could NOT have solved, but for Intel as-always wanting to sell-Sell-SELL new chips! Back in 2008 I asked Lucho how my (then) relatively-new UIDE driver fared v.s. Windows, as he ran both DOS and Win/XP, and Lucho replied You beat THEM 2 months AGO!! At-least Intel does not sucketh like Gates Co. does!! Re: SATA, it does not offer an IDE compatibility mode, as it uses all the same commands as IDE. Only its drive cables are different and NOT its software interface! AHCI is the one using a totally DIFFERENT command protocol, so it does need and have an IDE compa- tibility mode on most mainboards and in most BIOS routines. As I have noted, (A) AHCI is USELESS for DOS, as DOS does One at a time I-O and cannot make use of AHCI's much-touted Native command queuing, and (B) AHCI is RIDICULOUSLY complex, the obvious results of it being designed by a [MISERABLE!] ANSI committee which tried to satisfy EVERYBODY and in the end satisfied NOBODY, as-usual! I have REFUSED to implement actual AHCI in UIDE/UIDE2, and I shall do so for as long as IDE compatibility mode exists -- I have NO wish to double my drivers' I-O logic and so reduce their cache capacity, Por NADA! [for NOTHING], since DOS can never use AHCI queuing! But actually even DOS software gets slower and bloatier over time. I hate to bring up DJGPP, one of my favorite things, but take a look at CC1.EXE (C compiler proper) over the years, quite a difference!!! And don't forget the differences in x86 families (and software optimizations) and L1/L2/L3 cache sizes (among a billion other things). It all heavily varies (and GCC has both pros and cons). Hardware improvements like those you mention will never hurt any existing software, only make it faster. As for poor-old C com- pilers, which ALSO try to satisfy everybody and end-up satisfying NOBODY, maybe you can understand why I prefer assembly-language! No constraints on what code you generate, except your own!! -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
I have saved XMGR for real mode users who run UMBBCI first, followed by XMGR. In that case, XMGR is able to read UMBPCI's table of UMBs and can load there directly, which also uses 0 low-memory like JEMMEX. ... Unless you need EMS, you don't truly need JEMMEX itself ... JEMMEX/JEMM386 also allow VCPI/DPMI to be used, they allow mapping of upper-memory addresses into UMBs that UMBPCI cannot do (e.g. B000-B7FF) and they can be the one provider of upper-memory required by FreeDOS, which does NOT add-up the memory found by both UMBPCI and HIMEMX/JEMMEX (MS-DOS V6.22 and V7.10 WILL do this). Many other reasons, I am sure, for using JEMMEX/JEMM386. ... Last I checked, I don't think it would let you run XMS only unless you did NOEMS, and even that still left you in V86 mode ... ANY usage of JEMMEX/JEMM386 is GOING to leave you in V86 mode, since by definition THAT is the protected mode used by any EMM driver to protect the system from errant DOS programs! Actual protected mode is much less restricted, and that is NOT what an EMM driver uses nor what Intel INTENDED them to use when handling 16-bit DOS applications! In 16-bit real mode i.e. true DOS, you can play whatever games you like.In 32-bit protected mode, you can play games only in YOUR program areas. In V86 mode as when an EMM driver runs an old DOS program, you will TRAP real QUICK to the EMM driver on almost ALL instruction sequences EXCEPT commands legitimate for up to an 80386+ CPU to execute on its own! As for your NOEMS comment, I cannot be certain, but I think you need to CHECK THIS, once again! Nowadays, it does seem most DOS software is either real-mode or 32-bit DPMI, though some XMS creeps in too ... Use of XMS is irrelevant, 32-bit DPMI is also irrelevant. WHO CARES, since using or not-using an EMM driver in fact gives you exactly TWO choices for running a DOS system: 16-bit real mode, or V86 mode!! DOS also retains its single-sector directory handling, designed back in the early 1980s, when memory was EXPENSIVE and buffers were kept small. Two of the biggest hurdles to using DOS software often seem to be memory management and file system quirks. I know there are other minor things too, but those are the ones that seem to come up a lot. But with DPMI and FAT32, that's fairly moot, thankfully. How do either DPMI or FAT32 affect single-sector directory handling by DOS?? Do they magically RE-program DOS to handle more than ONE directory sector at a time?? I think NOT!! Until someone DOES so, DOS directory handling will still use SLOW 1981 style single-sector I-O, and only a cache like LBAcache or UIDE/UIDE2 will help! -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
DOS doesn't use SATA anyways (AFAIK), only IDE compatibility mode. It's still much faster than the hardware, that I was using in 1991. The HDD itself has quite large hardware cache (16 MB - incredibly large space compared to 640 KB). Hard-disks have come a long way. In 1994, I paid $350 for a 350-MB hard disk that as I recall had NO write cache. Now, under $100 can get me about 250-GIGABYTES with at-least a 16-MB write cache! Most IDE commands used in 1994 can still be used, only a few were added since then to support 48-bit LBA addressing (not 28-bit, like then). But actually even DOS software gets slower and bloatier over time. Maybe I wasn't clear enough in my writing: that pauses occur, for example, even when I've got to save just edited autoexec.bat - then we're talking about 2 KB (or so) text file. Not sure but my guess is hardware problem. Maybe not: I still use a 1986 WordStar editor, the only one I ever had time to learn well. It is VERY slow at the end of an edit, my guess being that only THEN does it rename my previous file with the .BAK suffix, then finishes output of my NEW file, then it deletes all its temporary files! Perhaps your editor does a LOT of such work, whenever you finally output a new edited file. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
2012/3/15, Jack gykazequ...@earthlink.net: Now, under $100 can get me about 250-GIGABYTES with at-least a 16-MB write cache! Most IDE commands used in 1994 can still be used, only a few were added since then to support 48-bit LBA addressing (not 28-bit, like then). Right - and, of course, I set the controller to use IDE-compatible mode, not to AHCI. Maybe not: I still use a 1986 WordStar editor, the only one I ever had time to learn well. It is VERY slow at the end of an edit, my guess being that only THEN does it rename my previous file with the .BAK suffix, then finishes output of my NEW file, then it deletes all its temporary files! Perhaps your editor does a LOT of such work, whenever you finally output a new edited file. I noticed that pauses while using edit shipped with FreeDOS - can it really be that slow when saving edited file? -- regards, Zbigniew -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Hi, On Thu, Mar 15, 2012 at 6:28 PM, Zbigniew zbigniew2...@gmail.com wrote: 2012/3/15, Jack gykazequ...@earthlink.net: Maybe not: I still use a 1986 WordStar editor, the only one I ever had time to learn well. It is VERY slow at the end of an edit, my guess being that only THEN does it rename my previous file with the .BAK suffix, then finishes output of my NEW file, then it deletes all its temporary files! Perhaps your editor does a LOT of such work, whenever you finally output a new edited file. I noticed that pauses while using edit shipped with FreeDOS - can it really be that slow when saving edited file? How big is the file? (Last I checked, FD EDIT only supported 64 kb files.) It's a 16-bit real mode editor compiled by a wimpy compiler, what'd you expect? ;-) So no, it's not fast, but it shouldn't take long. What file system? I think FAT32 is slightly slower. And of course fragmentation hurts (so defrag!). Of course, it could be a hardware (faulty disk) or driver issue, but first try a different editor (e.g. VILE, FTE). -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
I noticed that pauses while using edit shipped with FreeDOS - can it really be that slow when saving edited file? Try using EDIT shipped with V6.22 or V7.10 MS-DOS, which I find is not too bad! -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Unless you need EMS, you don't truly need JEMMEX itself. Last I checked, I don't think it would let you run XMS only unless you did NOEMS, and even that still left you in V86 mode. To test this, I change the first few lines of my CONFIG.SYS file which are -- DEVICE=C:\BIN\UMBPCI.SYS DEVICE=C:\BIN\XMGR.SYS /W DOS=HIGH,UMB REM DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF X=C800-EFFF NOEMS Normally, I remark out (REM) JEMM386 and use it only for UIDE/ UIDE2 testing. After editing, my CONFIG.SYS file began with -- DEVICE=C:\BIN\XMGR.SYS /B DOS=HIGH,UMB DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF I=CC00-DFFF DEVICEHIGH=C:\BIN\XMGR.SYS XMGR loads first in /B boot mode, then after JEMM386 enables upper-memory, XMGR loads again and moves to upper-memory, as was my original scheme for it to save 640K DOS memory. The JEMM386 driver is told to map the B000-B7FF monochrome video area and from CC00-DFFF as upper-memory. My video BIOS takes up to CBxx, and I wanted to avoid E000 up so JEMM386 could use it as an EMS page frame. Did not try this on FreeDOS, but on my old V6.22 MS-DOS, the edited CONFIG.SYS file booted with NO gripes or groans!! Rugxulo, I REALLY think you should check AGAIN running JEMM386 without NOEMS -- worked fine for me! -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Hi, On Thu, Mar 15, 2012 at 6:50 PM, Jack gykazequ...@earthlink.net wrote: Unless you need EMS, you don't truly need JEMMEX itself. Last I checked, I don't think it would let you run XMS only unless you did NOEMS, and even that still left you in V86 mode. Did not try this on FreeDOS, but on my old V6.22 MS-DOS, the edited CONFIG.SYS file booted with NO gripes or groans!! Rugxulo, I REALLY think you should check AGAIN running JEMM386 without NOEMS -- worked fine for me! In the past I always had EMM386 enabled, and it worked fine. In fact, some apps explicitly needed EMS and/or EMM386. But nowadays, FreeDOS is so good at keep low RAM free that I don't need UMBs for average stuff, esp. not DJGPP/DPMI things, so I would only do JEMM386 LOAD and UNLOAD at runtime if needed (rarely). My point was that JEMMEX is basically just HIMEMX + JEMM386 bound together, and you can't just load at runtime (if XMS already enabled) because it only uses its own XMS manager built-in. So while it saves a few kb of space by combining them, it's slightly less useful if you don't want EMS or UMBs (and/or have a very rare app that refuses to run under V86 mode). Also I very vaguely remember some apps in the old days not working correctly with NOEMS. Long story short: heh, 30+ years of compatibility can be a pain. But it's much easier to use (for me) than the alternatives. ;-) -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Hi, On Thu, Mar 15, 2012 at 5:37 PM, Jack gykazequ...@earthlink.net wrote: Intel giveth NOTHING, and followeth only All we want is MONEY!, same as Gates Co.! In my opinion, absolutely NO excuse for AHCI that a better-written Windows driver could NOT have solved, but for Intel as-always wanting to sell-Sell-SELL new chips! In fairness, not every person is truly as diligent, intelligent, and experienced as you are. So while in theory, somebody could rewrite Windows drivers or whatever to be 10x faster or smaller or better, it's probably just wishful thinking. We can't fulfill every dream, it's not realistic. As I have noted, (A) AHCI is USELESS for DOS, as DOS does One at a time I-O and cannot make use of AHCI's much-touted Native command queuing, and (B) AHCI is RIDICULOUSLY complex, the obvious results of it being designed by a [MISERABLE!] ANSI committee which tried to satisfy EVERYBODY and in the end satisfied NOBODY, as-usual! Yes, unpopular standards by committee are no better than no standard. But sometimes compromise is all you can get. You win some, you lose some. Hardware improvements like those you mention will never hurt any existing software, only make it faster. Not always the case, sometimes software misunderstands or interacts badly with more RAM or faster cpu. Also the timings for cpu instructions change, so what was once faster (e.g. 186 optimizations [ENTER, LEAVE] vs. 8086) is now comparatively slower (to its counterpart, e.g. 2.5 times slower). But yes, cpus themselves are mostly faster due to higher clock speed, microcode improvements, etc. As for poor-old C com- pilers, which ALSO try to satisfy everybody and end-up satisfying NOBODY, maybe you can understand why I prefer assembly-language! No constraints on what code you generate, except your own!! It's true, assembly will always win, but few are willing to go that far. Some even call C portable assembly, but it's not really. I'm not saying it has no use, but it's overrated. At least with assembly you can disregard calling conventions and memory models and do whatever is necessary. (And yes, C has some type safety issues, compilation speed issues, pointer aliasing issues, etc. But it's where most compiler optimizations are focused due to heavy use in the outside world. Sometimes worse is better only because more people work on it.) -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Rugxulo, I REALLY think you should check AGAIN running JEMM386 without NOEMS -- worked fine for me! In the past I always had EMM386 enabled, and it worked fine. In fact, some apps explicitly needed EMS and/or EMM386. But nowadays, FreeDOS is so good at keep low RAM free that I don't need UMBs for average stuff, esp. not DJGPP/DPMI things, so I would only do JEMM386 LOAD and UNLOAD at runtime if needed (rarely). Never HEARD of loading and unloading JEMMEX/JEMM386, which in fact never DID work properly with MS-DOS EMM386 (or maybe they found very early that UNLOADING it was DANGEROUS!!). Same as I noted for UIDE and UIDE2, why would you EVER want to unload the JEMM drivers, for they take so little memory and are thus invisible in normal use?? My point was that JEMMEX is basically just HIMEMX + JEMM386 bound together, and you can't just load at runtime (if XMS already enabled) because it only uses its own XMS manager built-in. So while it saves a few kb of space by combining them, it's slightly less useful if you don't want EMS or UMBs (and/or have a very rare app that refuses to run under V86 mode). Also I very vaguely remember some apps in the old days not working correctly with NOEMS. Such apps ought to be RETIRED, if they are so incompatible. And if anyone truly HAS a serious need for unloading JEMMEX, they should be using HIMEMX + JEMM386 (or my own XMGR + JEMM386), since in that case, unloading at-least JEMM386 can be done a LOT more easily!ought to use Long story short: heh, 30+ years of compatibility can be a pain. But it's much easier to use (for me) than the alternatives. ;-) Actually, only about 15 years of compatibility, since the first EMM386 did not appear until about 1990, and 386MAX was around only from 1988. But, I agree: For most people, JEMMEX is The Lazy Man's Way to have V86 protected mode on a DOS system -- Only ONE extra driver needed! -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Op 16-3-2012 0:55, Rugxulo schreef: stuff, esp. not DJGPP/DPMI things, so I would only do JEMM386 LOAD and UNLOAD at runtime if needed (rarely). The ability to dynamically load and unload JEMM386 is a nice benefit indeed. Indeed an XMS/HMA-only environment already provides a pretty decent start. together, and you can't just load at runtime (if XMS already enabled) because it only uses its own XMS manager built-in. So while it saves a few kb of space by combining them, it's slightly less useful if you don't want EMS or UMBs (and/or have a very rare app that refuses to run under V86 mode). Also I very vaguely remember some apps in the old days not working correctly with NOEMS. JEMMEX optionally acting as a 2-stage driver would be nice. Either load it as all-in-one, or starting as an XMS-driver and only allow itself as EMM386 driver, refusing all other UMB/EMS drivers. Then you get: [1]: DEVICE=JEMMEX.EXE NOEMS DOS=HIGH,UMB [2]: DEVICE=JEMMEX.EXE XMS DOS=HIGH [3]: DEVICE=JEMMEX.EXE XMS DEVICE=JEMMEX.EXE NOEMS DOS=HIGH,UMB [4]: DEVICE=JEMMEX.EXE XMS DOS=HIGH @echo off echo Loading EMS driver: jemmex.exe Some XMS managers are also dynamicly loadable, but that has more limited use as it won't enable HMA. Also, (primary) shells typically can't relocate themselves to XMS. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Op 16-3-2012 0:50, Jack schreef: To test this, I change the first few lines of my CONFIG.SYS file which are -- DEVICE=C:\BIN\UMBPCI.SYS DEVICE=C:\BIN\XMGR.SYS /W DOS=HIGH,UMB REM DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF X=C800-EFFF NOEMS Normally, I remark out (REM) JEMM386 and use it only for UIDE/ UIDE2 testing. After editing, my CONFIG.SYS file began with -- DEVICE=C:\BIN\XMGR.SYS /B DOS=HIGH,UMB DEVICE=C:\BIN\JEMM386.EXE I=B000-B7FF I=CC00-DFFF DEVICEHIGH=C:\BIN\XMGR.SYS http://www.vfrazee.com/ms-dos/6.22/help/commands%20for%20defining%20multiple%20configurations.htm ^^ (then again, a bootmenu typically causes delays due to giving the user a chance to make their choice). -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Hi, On Thu, Mar 15, 2012 at 6:04 PM, Jack gykazequ...@earthlink.net wrote: Unless you need EMS, you don't truly need JEMMEX itself ... JEMMEX/JEMM386 also allow VCPI/DPMI to be used, VCPI, yes, but not DPMI, you don't (necessarily) need EMM386 for that. they allow mapping of upper-memory addresses into UMBs that UMBPCI cannot do (e.g. B000-B7FF) Yes, if you can use it or need it. However, a 32-bit DJGPP app or pure real mode conventional memory only usually doesn't. and they can be the one provider of upper-memory required by FreeDOS, which does NOT add-up the memory found by both UMBPCI and HIMEMX/JEMMEX (MS-DOS V6.22 and V7.10 WILL do this). Many other reasons, I am sure, for using JEMMEX/JEMM386. FASTBOOT and VME are good reasons, but I don't run a lot of EMS-based software these days, so I don't enable EMM386 by default anymore. If I need it or want to test under it, I just do JEMM386 LOAD (another cool feature, despite disregarding UMBs). But keep in mind that JEMMEX LOAD [sic] won't work if XMGR is already loaded, so I can't use that. ... Last I checked, I don't think it would let you run XMS only unless you did NOEMS, and even that still left you in V86 mode ... ANY usage of JEMMEX/JEMM386 is GOING to leave you in V86 mode, since by definition THAT is the protected mode used by any EMM driver to protect the system from errant DOS programs! Not much protection. DPMI is (usually but not always) ring 3, which is better than ring 0 VCPI. Sure, DJGPP is rock solid (thanks to good work by CWS), but other stuff isn't so kind, hence EMM386 rarely helps there (in my limited experience). Actual protected mode is much less restricted, and that is NOT what an EMM driver uses nor what Intel INTENDED them to use when handling 16-bit DOS applications! EMM386 only exists for backwards compatibility with EMS-using software, and it was easier to implement due to the 386's MMU (or whatever, I don't understand the details). Sure, EMM286 exists in rare cases, but it's not as good. In 16-bit real mode i.e. true DOS, you can play whatever games you like. In 32-bit protected mode, you can play games only in YOUR program areas. In V86 mode as when an EMM driver runs an old DOS program, you will TRAP real QUICK to the EMM driver on almost ALL instruction sequences EXCEPT commands legitimate for up to an 80386+ CPU to execute on its own! It depends on a billion factors. Cpus these days are very complex. (Don't take this the wrong way, I know way less than you do, just saying, it's a mess.) Nowadays, it does seem most DOS software is either real-mode or 32-bit DPMI, though some XMS creeps in too ... Use of XMS is irrelevant, 32-bit DPMI is also irrelevant. WHO CARES, since using or not-using an EMM driver in fact gives you exactly TWO choices for running a DOS system: 16-bit real mode, or V86 mode!! In theory everything is fine, and usually it is, but there are weird corner cases. I'm not saying EMM386 is bad or unstable, I've used it (them?) a lot in the past. But the advantages aren't so irreplaceable. DOS also retains its single-sector directory handling, designed back in the early 1980s, when memory was EXPENSIVE and buffers were kept small. Two of the biggest hurdles to using DOS software often seem to be memory management and file system quirks. I know there are other minor things too, but those are the ones that seem to come up a lot. But with DPMI and FAT32, that's fairly moot, thankfully. How do either DPMI or FAT32 affect single-sector directory handling by DOS?? Do they magically RE-program DOS to handle more than ONE directory sector at a time?? I think NOT!! Until someone DOES so, DOS directory handling will still use SLOW 1981 style single-sector I-O, and only a cache like LBAcache or UIDE/UIDE2 will help! Well, that's basically what I meant. Newer modern OSes use fancier schemes and have more uniform (forced one-size-fits-all) memory management and file systems. Well, less so on the latter, Linux has like 45+ file systems (and we don't, sniff). And people always whine about DOS memory management bugs, quirks, workarounds. Same with FAT, they hate it (but no one has replaced it yet, esp. not with open source TSR or device driver). I just meant that in a perfect world we'd already have ext2 or HPFS support and/or better memory management across the board, not just lots of tiny bits and pieces and hacks. In a way, it's a great idea (and one that PatV often mentioned) to bring DOS into the 21st century, but it basically means rewriting everything, which is very very unlikely to happen. (Kickstarter, anyone?) Tons could be improved (and I'd expect compatibility to be a top goal, too). However, I know I'm dreaming here, it won't happen. Not a big deal either, I'm (semi-)content with the status quo ... but the damn hardware keeps changing and breaking things ad nauseum, thanks to rapid development of other modern things, hence UEFI kills
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Hi, On Thu, Mar 15, 2012 at 7:11 PM, Zbigniew zbigniew2...@gmail.com wrote: 2012/3/15, Rugxulo rugx...@gmail.com: I noticed that pauses while using edit shipped with FreeDOS - can it really be that slow when saving edited file? How big is the file? (Last I checked, FD EDIT only supported 64 kb files.) Like I wrote: about 2 KB. Hmmm, no, that shouldn't take more than a second. It's a 16-bit real mode editor compiled by a wimpy compiler, what'd you expect? ;-) So no, it's not fast, but it shouldn't take long. But even compiled using anything wimpy - can it still be noticeably slow on 2 GHz CPU? Depends on the algorithms, but normally I'd hope not! What file system? I think FAT32 is slightly slower. And of course fragmentation hurts (so defrag!). Of course, it could be a hardware (faulty disk) or driver issue, but first try a different editor (e.g. VILE, FTE). It's FAT32. But - as I wrote - my HDD has 16 MB of its own internal cache (it's STM3320418AS), then IMHO I shouldn't notice any pause while saving such short file. Even when not using any software cache at all. It shouldn't pause at all if using a generic hard drive, but perhaps yours is flash-based, e.g. USB or SSD?? If not, then it's some other conflict. I would to add, that no such problems when working under Linux - this makes me think, that NVIDIA SATA perhaps needs some kind of software booster to exploit its full potential? We've got nowadays win-printers, win-modems - and instead of soundcards programmed by setting their registers contents, there are just ALC codecs - perhaps now it's time for win-controllers, crippled by default, when not using additional software? Modern computers are 100x more complex than they were 10-20 years ago, so it could be anything. And yes, something like Windows has more support by default (e.g. ACPI) than most other OSes (with Linux second, natch). But I don't know exactly what's going on here. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Intel giveth NOTHING, and followeth only All we want is MONEY!, same as Gates Co.! In my opinion, absolutely NO excuse for AHCI that a better-written Windows driver could NOT have solved, but for Intel as-always wanting to sell-Sell-SELL new chips! In fairness, not every person is truly as diligent, intelligent, and experienced as you are. So while in theory somebody could rewrite Windows drivers or whatever to be 10x faster or smaller or better, it's probably just wishful thinking ... My Thanks for your personal compliments, but I still DO believe there MUST be someone at Intel or Microsoft who COULD have done a better job with SATA/IDE, rather than simply throwing up their hands (all maybe 3000 of them!!) and saying We need more HARDWARE! Or, it really IS an Intel conspiracy to sell more chips; wouldn't be the first time!! ... and (B) AHCI is RIDICULOUSLY complex, the obvious results of it being designed by a [MISERABLE!] ANSI committee which tried to satisfy EVERYBODY and in the end satisfied NOBODY, as-usual! Yes, unpopular standards by committee are no better than no standard. But sometimes compromise is all you can get. You win some, you lose some. Note that I said RIDICULOUSLY complex, and as above, I have REASONS for believing No AHCI at ALL could have been made to WORK! Hardware improvements like those you mention will never hurt any existing software, only make it faster. Not always the case, sometimes software misunderstands or interacts badly with more RAM or faster cpu. Also the timings for cpu instructions change, so what was once faster (e.g. 186 optimizations [ENTER, LEAVE] vs. 8086) is now comparatively slower (to its counterpart, e.g. 2.5 times slower). Rare circumstances. They have occurred, but I doubt that Intel allows such situations very often. It's true, assembly will always win, but few are willing to go that far ... Absolutely known in the 1980s or 1990s, when U.S. colleges virtually gave up on finding ENOUGH Slept Through High-School BRATS with 1/2 a brain, that might even be CONSIDERED for assembly-language software! THAT, and ONLY that, is why most U.S. colleges now teach only C! I used to joke about their college degrees being B. S. Chicken. Sh**.; not-much of a JOKE, any more!! -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
2012/3/16, Rugxulo rugx...@gmail.com: It shouldn't pause at all if using a generic hard drive, but perhaps yours is flash-based, e.g. USB or SSD?? If not, then it's some other conflict. No, STM3320418AS is just common internal HDD, got it attached to on-board controller. That's why I was surprised by these delays. -- regards, Z. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
JEMMEX/JEMM386 also allow VCPI/DPMI to be used, VCPI, yes, but not DPMI, you don't (necessarily) need EMM386 for that. Same for VCPI, I suppose -- There are subroutine packages that set up VCPI for a user application, if needed. they allow mapping of upper-memory addresses into UMBs that UMBPCI cannot do (e.g. B000-B7FF) Yes, if you can use it or need it. However, a 32-bit DJGPP app or pure real mode conventional memory only usually doesn't. But, there are a LOT of us who do not use DJGPP and yet COULD use a bit more UMB space, to load more/bigger drivers etc. and they can be the one provider of upper-memory required by FreeDOS, which does NOT add-up the memory found by both UMBPCI and HIMEMX/JEMMEX (MS-DOS V6.22 and V7.10 WILL do this). Many other reasons, I am sure, for using JEMMEX/JEMM386. FASTBOOT and VME are good reasons, but I don't run a lot of EMS-based software these days, so I don't enable EMM386 by default anymore. Nor do I use JEMM386 in everyday work, as I run a pure V6.22 MS-DOS and do not need the extra features. I am only saying that you ought not so-quickly dismiss the idea of using an EMM driver. They DO have their uses! ANY usage of JEMMEX/JEMM386 is GOING to leave you in V86 mode, since by definition THAT is the protected mode used by any EMM driver to protect the system from errant DOS programs! Not much protection. DPMI is (usually but not always) ring 3, which is better than ring 0 VCPI. Sure, DJGPP is rock solid (thanks to good work by CWS), but other stuff isn't so kind, hence EMM386 rarely helps there (in my limited experience). Thus far, I have been absolutely UNABLE to break into a V86 system, which I might LIKE to do, so UIDE/UIDE2 are a bit faster from needing NO Int 15h Ah=87h XMS move traps when V86 is active. The level of protection provided by V86 mode sure looks SOLID enough, to me! EMM386 only exists for backwards compatibility with EMS-using software, and it was easier to implement due to the 386's MMU (or whatever, I don't understand the details). Sure, EMM286 exists in rare cases, but it's not as good. I must DISAGREE: EMM386 may have been written for EMS memory but it EVOLVED into Microsoft's protected-mode provider and was NEVER merely a backwards compatibility EMS handler! In 16-bit real mode i.e. true DOS, you can play whatever games you like ... In V86 mode as when an EMM driver runs an old DOS program you will TRAP real QUICK to the EMM driver on almost ALL command EXCEPT commands legitimate for up to an 80386+ CPU to execute on its own! It depends on a billion factors. Cpus these days are very complex. (Don't take this the wrong way, I know way less than you do, just saying, it's a mess.) ONly a FEW factors, since a protection trap is a PROTECTION TRAP! for any AMD CPU as well as for Intel CPUs! All vendors watch this type of compatibility VERY closely, which is why I have NO qualms re: buying an AMD CPU. They are usually less expensive and WORTHWHILE!! How do either DPMI or FAT32 affect single-sector directory handling by DOS?? Do they magically RE-program DOS to handle more than ONE directory sector at a time?? I think NOT!! Until someone DOES so, DOS directory handling will still use SLOW 1981 style single-sector I-O, and only a cache like LBAcache or UIDE/UIDE2 will help! Well, that's basically what I meant ... Glad to hear THAT!! In a way, it's a great idea (and one that PatV often mentioned) to bring DOS into the 21st century, but it basically means rewriting everything, which is very very unlikely to happen. (Kickstarter, anyone?) Tons could be improved (and I'd expect compatibility to be a top goal, too). However, I know I'm dreaming here, it won't happen. I don't think it is as NECESSARY at you think! Back in 1988, I saw an MS-DOS V3.3 system running EIGHT tasks using an old Quarterdeck type of multi-tasking, and that was on a VERY-old 80386! DOS could still WORK for people (quite-well using drivers like UIDE as Lucho confirmed to me in 2008) if only they USE it properly, and aren't Sold down the river by Intel and Microsoft into buying new systems! I began my software career in 1966 at The Bank of California in San Francisco, who had only 2 IBM 1460s and one 1401, each with only TAPES (no disks!) and only 16K of memory! Yes, I meant 16,000 7-bit bytes, since memory was TERRIBLY expensive in 1966! Any you know what?? Those poor old 16K systems did a LOT more work than my current 1-GB system will EVER do! We need NO more hardware, CERTAINLY NOT any damned 64-bitters having 64-GB of memory, when in fact Intel/Microsoft never REALLY learned to use 32-bit or even 16-bit systems all that well! Same for DOS -- USE IT a little BETTER, and maybe it CAN do the job, EXACTLY as it is now!! -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Hi Jack, Thus far, I have been absolutely UNABLE to break into a V86 system, VCPI is there to share protected mode, not to keep you outside. But indeed while you are in V86, you have limitations. Running your stuff in protected mode with HELP of VCPI would fix this, but it is annoying to need TWO strategies - while there is no V86, it is easy to have unlimited access and faster than even shared protected mode with V86. You can also break EMM386 itself by patching it in RAM but I do not see why that would be good for you. Only debuggers sometimes do this, for them it can be useful... EMM386 only exists for backwards compatibility with EMS-using software, and it was easier to implement due to the 386's MMU (or whatever, I don't understand the details). Sure, EMM286 exists in rare cases, but it's not as good. I must DISAGREE: EMM386 may have been written for EMS memory but it EVOLVED into Microsoft's protected-mode provider... I disagree again - EMM386 got the VCPI extension so Windows and EMM386 can cooperate instead of being in the way of each other. Raw mode is as good as VCPI mode for Windows, because VCPI is not giving you any fancy services. It just gives you a small set of hooks and levers to share protected mode with EMM386. Windows can even use the extra GEMMIS interface to clone the whole state of EMM386 and effectively disable it and do memory management in both Windows and DOS context itself, so Windows can avoid having to share responsibilities with EMM386 and can avoid VCPI. Note: Only very few EMM386 clones implement the low-documented GEMMIS. What I mean: If there is no EMM386, very few apps will feel bad about not having VCPI around. When protected mode is on - be it EMM386 loaded or Windows running - then the spartan VCPI or the helpful DPMI are needed by protected mode apps. DPMI also keeps you further from hardware - you need less low level code and you are kept away from it as well. Windows and Linux Dosemu therefore give you DPMI but not VCPI. The CWSDPMI extender takes raw, VCPI or DPMI situations as starting point for always giving you DPMI. Eric -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] zbigniew system stability with different shells, kernels and drivers
Hi, On Thu, Mar 15, 2012 at 8:23 PM, Eric Auer e.a...@jpberlin.de wrote: Thus far, I have been absolutely UNABLE to break into a V86 system, VCPI is there to share protected mode, not to keep you outside. http://en.wikipedia.org/wiki/VCPI Yup, developed by PharLap and Quarterdeck, no surprise, as they invented the DOS extender and Desqview, respectively. They were trying to play nice with other protected mode DOS software. But indeed while you are in V86, you have limitations. Running your stuff in protected mode with HELP of VCPI would fix this, I'm fairly green here, but I'll try to understand anyways: are you talking about 32-bit segments without overrides? As in slightly faster and no 16-bit segment limits? but it is annoying to need TWO strategies - while there is no V86, it is easy to have unlimited access and faster than even shared protected mode with V86. Again, I don't understand. VCPI for full 32-bit and V86 for DOS, isn't that what you're suggesting? I must DISAGREE: EMM386 may have been written for EMS memory but it EVOLVED into Microsoft's protected-mode provider... I disagree again - EMM386 got the VCPI extension so Windows and EMM386 can cooperate instead of being in the way of each other. It was all for Windows originally, even HIMEM, I think. Windows and OS/2 were the future, DOS was old, they thought character-mode only was obsolete long ago. They wanted to mimic the Apple Macintosh (and/or Xerox Star or whatever): GUI, mouse, icon, pointer, overlapping frames. Raw mode is as good as VCPI mode for Windows, because VCPI is not giving you any fancy services. Can't remember, did Win9x need EMM386 at bootup? I doubt it. Win16 certainly seemed to for Enhanced mode, more or less (not counting Win3.0's real mode, which was quickly abandoned). Certainly 2k/XP don't need VCPI (nor DOS) at all, but the guts are probably still the same. It just gives you a small set of hooks and levers to share protected mode with EMM386. Under EMM386, you need VCPI to switch to protected mode (if not already enabled). Windows can even use the extra GEMMIS interface to clone the whole state of EMM386 and effectively disable it and do memory management in both Windows and DOS context itself, so Windows can avoid having to share responsibilities with EMM386 and can avoid VCPI. Note: Only very few EMM386 clones implement the low-documented GEMMIS. Yes, Win9x (I think?) had a hidden way of shutting it down so it wouldn't interfere. Quite silly, really. What I mean: If there is no EMM386, very few apps will feel bad about not having VCPI around. Right, without EMM386 there wouldn't be a need for an official API to switch to pmode and back. When protected mode is on - be it EMM386 loaded or Windows running - then the spartan VCPI or the helpful DPMI are needed by protected mode apps. Windows always considered VCPI inferior for various reasons, hence why it wasn't well-supported except in standard (286) mode, barely. You had to use improved / better DPMI for 386 Enhanced mode (despite Win16 being DPMI 16-bit based, oddly enough). DPMI was invented for Windows, but unlike VCPI, it could be ring 3, better handling of virtual memory, optional 16-bit support, etc. So it was quickly standardized and copied. (Too bad NTVDM is so buggy these days and non-existent on Win64. Also too bad DPMI 1.0 was so rarely utilized.) DPMI also keeps you further from hardware - you need less low level code and you are kept away from it as well. Windows and Linux Dosemu therefore give you DPMI but not VCPI. The CWSDPMI extender takes raw, VCPI or DPMI situations as starting point for always giving you DPMI. CWSDPMI won't load at all if DPMI is already found. And it can't load at all if EMM386 is but VCPI isn't found. (And what I was barely referring to before was some rare bugs where some apps and/or extenders didn't handle NOEMS correctly because it did or didn't think it also meant NOVCPI. But, again, that was fairly rare. But it seems a lot of software has such quirks, and DOS is certainly not immune, esp. when most of it is currently not maintained anymore.) -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
