Re: [Freedos-user] "Test." -- does that come from FreeDOS?
I suspected as much. Dell support, of course, runs and hides when it comes to any issue outside the Microsoft ecosystem. So, no joy there. Thanks for your time and prompt reply, Tom. On Mon, Jan 6, 2020 at 1:30 PM tom ehlert wrote: > Hallo Herr Jack Browning, > > am Montag, 6. Januar 2020 um 19:32 schrieben Sie: > > > I've been trying to update the BIOS on my wife's Dell Inspiron 17 > > 5721 laptop using FreeDOS. I've tried to do this with FreeDOS 1.0, > > 1.1, 1.2, and 1.3rc2, each time with the same result. > > > > What happens is this: after setting up FreeDOS on a USB stick using > > its .img file (and adding the BIOS executable, 3521A16.exe), I can > > boot without incident into FreeDOS on the laptop. After opting not > > to continue with the installation, the DOS prompt I'm dropped into > > seems to be fully functional, i.e., all the builtin commands appear > > to work normally. When I go to run the BIOS updater by typing the > > .exe's file name and hitting return, however, the only thing that > > happens is that the word "Test." is printed to the console. The > > updater then exits without doing anything else. > > > > The updater is what Dell describes as a "Universal (Windows/MS > > DOS)" application. Even though it appears to the file system as a > > single .exe file, it is actually a package, containing these files: > > > > Ding.wav > > FlsHook.exe > > FlsHookDll.dll > > FWUpdLcl.exe > > InsydeFlash.exe > > iscflash.dll > > iscflash.sys > > iscflashx64.sys > > isflash.bin > > platform.ini > > xerces-c_2_7.dll > > > > Frankly, I don't know enough about DOS to know whether this kind of > > application structure is normal in a DOS environment. I'm just > > mentioning it as a possible issue. > > this is definitively not a DOS application. > most likely you are supposed to run (on Windows 10) recoverydrive.exe > and run this stuff. anything else should go through the Dell support > forum. > > > > > I've scanned for strings in all of the files of the updater, and > > did not find a "Test." string, which leaves me with the question of > > whether "Test." (and the premature installer exit) is coming from > FreeDOS. > no. > > > more help should come from Dell support. > > Tom > > > > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] "Test." -- does that come from FreeDOS?
I've been trying to update the BIOS on my wife's Dell Inspiron 17 5721 laptop using FreeDOS. I've tried to do this with FreeDOS 1.0, 1.1, 1.2, and 1.3rc2, each time with the same result. What happens is this: after setting up FreeDOS on a USB stick using its .img file (and adding the BIOS executable, 3521A16.exe), I can boot without incident into FreeDOS on the laptop. After opting not to continue with the installation, the DOS prompt I'm dropped into seems to be fully functional, i.e., all the builtin commands appear to work normally. When I go to run the BIOS updater by typing the .exe's file name and hitting return, however, the only thing that happens is that the word "Test." is printed to the console. The updater then exits without doing anything else. The updater is what Dell describes as a "Universal (Windows/MS DOS)" application. Even though it appears to the file system as a single .exe file, it is actually a package, containing these files: Ding.wav FlsHook.exe FlsHookDll.dll FWUpdLcl.exe InsydeFlash.exe iscflash.dll iscflash.sys iscflashx64.sys isflash.bin platform.ini xerces-c_2_7.dll Frankly, I don't know enough about DOS to know whether this kind of application structure is normal in a DOS environment. I'm just mentioning it as a possible issue. I've scanned for strings in all of the files of the updater, and did not find a "Test." string, which leaves me with the question of whether "Test." (and the premature installer exit) is coming from FreeDOS. Any help would be greatly appreciated. Thanks in advance! ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Rugxulo IS A FRAUD!!!
Note the following comments by Rugxulo in this post: www.bttr-software.de/forum/forum_entry.php?id=14140 * If you want to try his latest drivers (Mar-18) [sic], grab them from * his DropBox, but since he doesn't even use FreeDOS (only MS-DOS 6.22), * I'm not sure if they work at all anymore: And note the following comments by Rugxulo in this post: www.mail-archive.com/freedos-user@lists.sourceforge.net/msg16396.html * I hope Jim Hall removes every ounce of work you've ever done for FreeDOS. * I hope he deletes it all from BASE, iBiblio mirror, and everything else. Now, note the following comments by Rugxulo in THIS post: www.mail-archive.com/freedos-user@lists.sourceforge.net/msg16472.html * BTW, I forgot I had Doom 1.9 (shareware) here (circa 1995), so I did a * quick install (no music, PC speaker sfx). It played just fine for * several levels, using default extender ... until I quit the game, then * it crashed/hung/beeped with MCB error. :-P And that's on a more * modern machine than yours, of course not running LBACACHE but still * using (Mar-05, 2015) XMGR, UIDE, RDISK. Rugxulo, you are a FRAUD!! A Charlatan and now a PROVEN FRAUD!! If you don't think my drivers work any more, and you want Jim Hall to remove all my work from BASE and IBiblio, they WHY ARE YOU STILL USING XMGR, UIDE, and RDISK?? Because you are a DISGRACE to all humanity, you lousy FRAUD!! STOP using my drivers, you stinking FRAUD!! Stop using them NOW, and NEVER use them again, you wretched FRAUD!! And Put your money where your [FOUL] MOUTH is and get Jim Hall to DELETE my drivers from IBiblio, EVERY LAST ONE since 2004, you despicable FRAUD!! STOP using my drivers and GET RID OF THEM ALL from Ibiblio NOW, you stinking FRAUD!! No matter if you have Jim Hall do it, or do it somehow yourself, just DO IT NOW, you miserable FRAUD!! You have made a MOCKERY of this forum by breaking EVERY ONE of its Rules For Posting, which I now regard as either a JOKE or a bald-faced SHAM!! I DO NOT want my work associated with FreeDOS any more, CERTAINLY NOT for use by a PIG and a CRACKER like YOU, you two-bit FRAUD!! So DO IT NOW!! STOP using my drivers, ALL OF THEM, if you think they no-longer work!! And Get Them All OFF IBIBLIO too!! They were NOT written to be used by a pitiful CRETIN like YOU, you FRAUD -- Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] XIDE Updated; UIDE Support TERMINATED!
Johnson Lam has posted an updated 5-Jun-2015 DRIVERS.ZIP file with a single XIDE driver, in his dropbox at: https://dl.dropboxusercontent.com/u/15785527/dos/file/drivers.zip XIDE is now a single driver, using a /P switch to request high-speed protected caching, also a /X switch to disable overlap of UltraDMA disk I-O with caching on an old or odd mainboard requiring this. XIDE's overlap of UltraDMA disk input with caching is also improved. Versus UIDE, the 5-Jun-2015 XIDE now offers up to 10% greater speed! Note also that my support for the old UIDE driver is now TERMINATED, due to Rugxulo's continuing MAD Dog! GRUDGE against me, that began with his following 17-Mar-2015 post on BTTR: http://www.bttr-software.de/forum/forum_entry.php?id=14140 Rugxulo is miffed that I refused to follow his ideas for upgrading my PC, after SourceForge made virtually overnight changes to their Internet security certificates, which I think was a MISTAKE!But, Rugxulo went on sending me more ideas, although I asked him at-least twice to Send me NO MORE E-Mails! If in the above post, he calls this arguing with me, Rugxulo is a LIAR!! It was only HE who was intruding on ME, and nothing more!! Rugxulo now takes EVERY chance he can to ATTACK me, as can be viewed in all his FD-User and BTTR posts since 17-Mar-2015. He is correct in only one thing: After his having recommended UIDE for years, his above post is the reason I made the new XIDE a closed-source driver. My drivers ALWAYS work, as they are always CHECKED by Johnson Lam or by Khusraw (both, if their time allows) before Johnson posts them! And if, after so long, Rugxulo now thinks he can make my using V6.22 MS-DOS into a FreeDOS driver issue, Rugxulo is Blowing SMOKE! to make himself look good, and he should be considered only as a FAKE!! I'll BE DAMNED before I merely give away any more of my sources in the face of Rugxulo's BACKSTABBING! XIDE will remain closed-source and I plan NEVER to do any more open-source work: Too many absolute FREAKS and MAD Dogs! to put-up with!! Please do NOT address any further UIDE questions/comments to me. I now regard it as defunct, and you now know why. Jack R. Ellis -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] XIDE Updated; UIDE Support TERMINATED!
Mateusz and Eric, my Thanks for your comments, which I respect. But I will not accept undeserved attacks on me and my work. So, my decision stands, that XIDE and other software from me will now be closed-source. Re: the REST of what was posted on FD-User today, Sunday 14-Jun-2015: * I know it's ironic that I spent so many hours trying to help him get * back on the list ... MY decision and MY RESPONSIBILITY that I feel SourceForge made a MISTAKE in their overnight Internet certificate changes. Who is Rugxulo that I MUST LISTEN to his ideas! I had to tell him TWICE to STOP sending me any more E-Mails! So he took what was essentially a PRIVATE matter onto a PUBLIC forum, in his 17-Mar-2015 BTTR post. In any case, as one can see from my posting on FD-User again, it was not necessary to upgrade. I could have ignored all by Rugxulo or Zangune (SourceForge), merely used my intuition, and I would have been able to post here again MUCH sooner! * I can't even officially mirror anything closed source. This is a * FreeDOS mailing list hosted by SourceForge, or have you forgotten? I have not forgotten, and in fact I never asked you to mirror any of my drivers. After all of this, I would be absolutely delighted, if FreeDOS, IBiblio or whoever DID delete every one of my driver files! * You explicitly told me NOT to mirror your drivers because, unless * you could directly announce them on freedos-user, that you'd be done * with FreeDOS. Correct, since their are always technical details re: my drivers that only I can explain. Without being able to post on FD-User, I cannot give such explanations, and that says I would be done with FreeDOS! * I (indirectly) was asking rr to either reinstate you or explain * why not (though he never did). The above is the first I ever heard of that! Robert Riebisch of BTTR did write me that he had begun work at a new job and is very busy. I was unable to read an attachment he sent, in his inquiry re: getting me back on BTTR, and I have not heard from him since, just like others to whom he has not replied. From my 35 years in software, I am aware of just how demanding and mercenary such jobs can be. * I (indirectly) was trying to get mvojvodic to test your newer * drivers and report back because they didn't work for me (refused to * boot on Lenovo 2011 ... The above is the first I ever heard of that, as well! Although I was tired of Rugxulo's never-ending upgrade-Upgrade-UPGRADE E-Mails, did he really believe I would not have listened to a SERIOUS bug comment about a PC-compatible system? I surely WOULD have! * (08-Dec-2014) Jim Hall: I see Jack has got you involved on this too. * He's becoming very abusive (again) and I find that tiring. I'm not * going to put up with it. ABSOLUTELY the first I ever heard of THAT! Then why did Jim Hall not write to ME in December, nor answer at-all the E-Mail which I sent him last Monday, 8-Jun-2015? His total lack of response this week is why I chose to make yesterday's FD-User post, so users WOULD know what was going on. * Jack, you didn't want to spend any money to upgrade ... Absolutely NOT Rugxulo's BUSINESS, whether or not I upgrade! Who is HE that I MUST listen to his ideas, and what if his ideas proved to be flatly UNNECESSARY, as I noted above! ** My drivers ALWAYS work, as they are always CHECKED by Johnson Lam or ** by Khusraw (both, if their time allows) before Johnson posts them! * * Two whole testers? Out of 8 billion people? Wow, I'll bet even * Microsoft is jealous. They positively SHOULD be!! Lucho told me in 2008, when I asked how UIDE compared in speed to his Windows, You beat THEM, 2 months ago! That was long before any of XIDE's upgrades; and XIDE is still only a 5K run-time driver using NO interrupts and providing up to 4-Gigabyte caches! Gazillion-byte drivers in C were never-Never NECESSARY!! I shall continue to rely on Johnson's 11 years and Khusraws 8 years of test results. They value and comment about my drivers.Others on BTTR and FD-User almost NEVER say anything. * Jack ... I hope Jim Hall removes every ounce of work you've ever * done for FreeDOS. I hope he deletes it all from BASE, iBiblio * mirror, and everything else ... So do I. My drivers were not designed solely for FreeDOS but for any DOS system. The fact that they DID end up on IBiblio was not my doing nor really my desire. Jim Hall is absolutely free to be rid of every one of my driver files from 2004, any time he wishes! But I know he will NOT do it, for the same reasons as before: Jim is DESPERATE not to lose software that WORKS! Can anyone imagine how much SLOWER FreeDOS would be, without UIDE? If you want to SEE how much slower, try having FreeDOS copy a full CD to one disk file with XCOPY, in protected mode using JEMM386, both with and without my drivers. You should note about a 4 to 1 speed difference in favor of using UIDE, or around 10 to 1 if your BIOS cannot permit disk
[Freedos-user] New 19-Oct-2014 Drivers -- Faster UHDD!
Johnson Lam has posted a new DRIVERS.ZIP file, now dated 19-Oct-2014 and with an updated UHDD driver, in his dropbox at: http://dl.dropboxusercontent.com/u/15785527/drivers.zip No change to any of the other drivers but re-dating them 19-Oct-2014 for consistency, also no change to the /B stand alone UHDD. UHDD's /M switch is deleted. It shall now set a 256-byte binary search buffer, not 512. The short buffer still avoids 6 XMS accesses in every cache binary search, which increases speed. It also helps UHDD + UDVD2 (4400 HMA bytes total) fit in the limited HMA of V7.0+ MS-DOS (max. 8976 bytes) with up to 12 DOS buffers. For these reasons, UHDD's buffer has been made permanent, and /M is now unneeded. UHDD now overlaps caching tasks with UltraDMA disk I-O! Disk input may not be overlapped, as at least one extra XMS move is needed (user-buffer to cache, or vice-versa, depending on UltraDMA rules). That move may not begin until input is finished. But, disk output CAN be overlapped, and an extra XMS move (if needed) can be done during output DMA! Adding only UltraDMA output overlap, and doing some cache work after DMA end but before disk ready, i.e. in the last inter-sector gap of each disk I-O, all WORKED the very first time! UHDD now has noticeably more speed! This is especially true for slower laptop or old disks, whose sector gaps give UHDD more time to overlap XMS binary searches, etc. More difficult to add in UIDE, with its integrated logic, while UHDD has separate stand-alone and caching UltraDMA subroutines. Many UIDE users want the driver to remain as-is, so it was again left alone. Those who desire more speed can switch from using UIDE to using UHDD + UDVD2. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New 27-Sep-2014 Drivers -- UHDD Updated.
BAD year for illness re: my surgery in May and re: Johnson Lam having a nasty Flu last week. Johnson is finally O.K., and he has posted a new 27-Sep-2014 DRIVERS.ZIP file with an upgraded UHDD driver, in his dropbox at: http://dl.dropboxusercontent.com/u/15785527/drivers.zip No changes to the other drivers but re-dating them to 27-Sep-2014 for consistency, as always. UHDD now provides all four UIDE caches: Common, CD/DVD, User-1 and User-2. The user caches now add only 48 bytes of tables, thus they are now permanent. Little DOS driver development going on, and no user drivers have ever asked UIDE/UHDD to do caching. But now, UHDD will not need a re-assembly if its user caching is ever desired! UHDD also re-adds a 512-byte binary search buffer, for those who want maximum caching speed. This was deleted from old driver versions to save memory. The search buffer's 80 bytes of logic are permanent in UHDD, as this code is integrated in the driver and hard to dismiss. But the 512-byte buffer is not permanent and must be requested with a new /M (memory buffer) switch. Users whose systems are short on HMA space can omit /M and save HMA as before. Or, users can request the search buffer but reserve only 4 DOS buffers with BUFFERS=4 in CONFIG.SYS to save HMA. UIDE/UHDD work fine with only 4 DOS buffers, which handle directories, as other directory sectors are cached and can be accessed quickly! Note that UIDE has not been updated to have the search buffer. Many users are happy with UIDE as-is, so it has been left alone. Those who run UIDE but want maximum caching speed can run UHDD + UDVD2 as a substitute. They take a maximum 4.5K of HMA space, when loaded with /H switches. If necessary, BUFFERS=4 in CONFIG.SYS should be able to save enough HMA space, so UHDD + UDVD2 can be loaded there. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Using UIDE/UHDD With FreeDOS.
My belated reply to an FD-User post by Bill Haught, dated 2014-07-18 12:36:17 and answered below by Tom Ehlert. I planned to stay silent, but all of the following BEGS to be addressed! -- As I mentioned earlier, Freedos requires a ATA legacy mode in BIOS, which I don't have. wrong. Tom is correct to say Wrong. All DOS variants merely issue Int 13h I-O requests for BIOS disks/diskettes and could not care what mode a BIOS uses to do a request. Any hard-disk controller, from old IDE to new AHCI, is supposed to have a legacy mode that can handle such I-O so a PC can at-least boot from its BIOS units via common commands. Found this in the archives http://sourceforge.net/p/freedos/mailman/message/26625851/ UIDE/UIDEJR can run AHCI drives on mainboards that have a legacy or native IDE setting for AHCI controllers, i.e. the drives can be addressed using standard SATA/IDE I-O logic. Obsolete. Since 2012, to handle MISERABLE Virtual Box which FAILS to emulate all SATA/IDE commands, UIDE and UHDD have had a /E switch, which tells them to call the BIOS for hard-disk I-O. /E helps for pre-1994 systems with no PCI BIOS (needed to get UltraDMA addresses), and it should handle disk I-O on AHCI systems which offer NO legacy controller settings for a mainboard.AHCI controllers are supposed to use boot-up legacy mode, until an operating-system driver ORDERS them into Native AHCI mode.UIDE/UHDD never issue that order, so legacy AHCI mode should remain active and should work fine for DOS! right. UIDE doesn't work on AHCI controllers ... Tom is WRONG! UIDE/UHDD will run AHCI controllers in legacy mode and/or with their /E switch as noted above. What I REFUSE to do is add all the GARBAGE needed for Native AHCI in my drivers! Any AHCI system is supposed to offer some form of legacy mode, specifically for old drivers that cannot (or WILL NOT, in my case!) get upgraded. El Cheapo mainboards from Taiwan which lack any such legacy AHCI mode settings are in my opinion ABSOLUTELY NOT worth anybody's time! ... and isn't required for FreeDOS. FreeDOS is perfectly happy without UIDE. (UIDE might even get in the way of updating your HD firmware.) Technically correct. But Tom is totally IRRESPONSIBLE to emphasize [UIDE] isn't required for FreeDOS! DOS was designed in 1981, and it still does single sector I-O for its FAT and directory sectors, let-alone using normal IDE (NO UltraDMA) for its Int 13h disk I-O, also let-alone ancient CD drivers like VIDE-CDD, OAKCDROM, etc., all of which use NO UltraDMA and do NO calls to a caching driver! Does our phrase Grizzling SLOW mean anything to all of you?? Hard disks, and especially CDs/DVDs, at-least need caching for their directories, which makes them twice as fast. Hard disks and CD/DVD drives also need UltraDMA, which makes them run twice-as-fast AGAIN! Most new BIOS chips have disk UltraDMA, but many still omit Virtual DMA logic, meaning that in protected-mode (JEMM386, etc.), the BIOS CANNOT do UltraDMA! VDS calls are the only way to get the 32-bit address of a mapped I-O buffer, when running protected-mode, since only JEMM386/EMM386 can say how they mapped memory! FOOLISH, for a BIOS to have UltraDMA without VDS. But THAT is what Taiwan DOES! I wrote my original UDMA driver in 2003, added caching for directory sectors in 2006, full caching of ALL disk data later in 2006, and CD directory/data caching in 2007 (UDVD calling UDMA for CD caching), ALL of which improved system speed! In 2008, I asked my old friend Luchezar Georgiev how UIDE compared to the I-O speed of his Windows, and Lucho replied, You beat THEM, 3 MONTHS ago! Along with that, in 1989 I added XMS only caching, which permits caches up to 4-GB! And with my latest 26-Jan-2014 drivers, UIDE/UIDE can set 4 separate caches (2 in UHDD, re-assembly gives all 4), for CD/DVD gamers and others who want their data retained and not discarded due to other device I-O into only one cache! My drivers do not use Write Back (delayed writes, faster in some cases). But this keeps them SMALL, versus the 40K+ of SMARTDRV, or 80K+ of Norton NCACHE2.UIDE/UHDD do 70% of disk I-O directly to/from their XMS memory buffers, saving unneeded moves; they will cache diskettes and can be called to cache data for other device drivers; etc. In summary, I did ALL I COULD, using only 5K bytes of run-time logic (NO gazillion bytes of C, and only 1K or upper/DOS memory, as most of my logic can go in the HMA!), so my drivers would be a help for any and all DOS variants! Granted, UIDE/UHDD may not be appropriate for diagnostic or test work, to re-flash hard-disk EEPROMs (quite RISKY, in my opinion!), or for other unusual cases. But, if you want FreeDOS (or other DOS variants) to run REALLY SLOW, try omitting any-or-all of my drivers and see what happens to your system performance! I AM NOT trying to sell my drivers nor feather my own nest as we say. But I do hope the above, Once and for
Re: [Freedos-user] Help Using FreeDOS1.1
At 08:46 AM 7/11/2014, panyong wrote: Hi, I installed FreeDOS1.1 on Parallels , and i want to install some software on the list http://www.freedos.org/software/ I¡¯ve tried to use a browser , but there is no on freedos . I've also tried using the usb-flash-disk to share a file , but i fail again. I don¡¯t know how to copy the software-file to freedos. Any help Using FreeDOS would be appreciated. What I do for ESXi (VMWare's hypervisor) is to use the CD-ROM in FreeDOS. I can either mount an iso file as the CD-ROM (which is what I usually do) or mount the physical CD-ROM. Maybe Parallels allows something similar. -- ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Command Line Parsing
I've noticed a difference in command line parsing between FreeDOS and PC-DOS. Both FreeDOS and PC-DOS put the command line, starting with the character after the executable, in a buffer at offset 0x80 in the PSP. The behavior difference I see with FreeDOS is if the first non-blank character after the executable is a left parenthesis, then FreeDOS sets 0x80 in the PSP to zero so the rest of the command line is not available. Examples of what is in PSP 0x80: Command Line: SOMEPROG (aa bb cc FreeDOS: \0 DOS: (aa bb cc\0 Command Line: SOMEPROG abc (cc dd ee FreeDOS and DOS: abc (cc dd ee\0 Does anyone know why FreeDOS behaves differently when the first character after the executable is a left parenthesis? -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] SERIOUS Off-Topic, Part 2 -- U.S. Medicine.
An off-topic addendum to my 2011 post on this forum about U.S. medicine -- Regrettably, I have been diagnosed with a 98% chance of bladder cancer, for unknown reasons excepting bad luck. I was told it needs to be taken care of within 3 months, after being detected on 4-Mar-2014.I do not drink, smoke (Asthma since birth), NEVER did drugs, and I do NOT abuse prescrip- tions like my parents did. So where-in-HELL did THIS come from?, and my doctor said it still hits 1 of 30,000 people with no other risk factors. U.S. bladder surgery is now done mostly by urologists, with tiny tools that are inserted you-know-where. But, my town has only two urology practices. One BOTCHED my prostate surgery, giving me 9 years of ever-worsening U.T.I. cases (urinary tract infection, BLOOD in one's urine!). The other, in the middle of a BAD U.T.I. in 2012, REFUSED to let me in their door, as a Medi- care authorization from my own doctor had not-yet arrived!As I DETEST Paperwork BEFORE the Patient medical offices, I thus wanted NOTHING to do with either urology practice in this town, for those reasons! After his office (finally) found me a good urology practice in a neighbor town, and that urologist wanted a cardiac clearance on me due to previous A-Fibs (dangerous racing heartbeat!), my doctor then FAILED to return two phone calls about his SLOW scheduler and about a U.T.I. anti-biotic which now needed pre-authorization by him. No choice but for me to pay $167 for another refill, so I would not run out, suffer a new U.T.I., and maybe have my surgery delayed! Also, no choice but to request a transfer back to the main office of my medical providers, as the doctor could not even spare me 10 minutes on the telephone, and I expected that WOULD occur again. At least my new doctor (younger than my sons!) is a good man and is competent: They let him run their Urgent Care (emergency) office alone on Saturdays! The cardiologist had told me I would get clearance for surgery on Tuesday 22-Apr-2014 with the neighboring urologist. Despite that, I heard today the clearance was NOT sent 2 days ago, and the cardiologist's M.A. (medical assistant) was waiting for all my tests since An anesthesiologist needs to see them for surgery. NOBODY told me that before! Also, very BAD LOGIC as NO anesthesiologist needs to see my tests, nor would he care about them, before I am SCHEDULED for surgery, which requires my clearance to be sent FIRST! The M.A. finally did send my surgery clearance this morning, but not before leaving me SERIOUS doubts that she would! I was left feeling even my diagnosis of CANCER meant NOTHING to the cardiologist or his people and I doubt I will be going back to THAT office again! Hopefully, the urologist can now have me scheduled for surgery without more delays. But I have seen a really good doctor become critically overworked and have also suffered through a cardiology office that, in my opinion, did not care. Add to that the two local urology offices which FAILED me, also last year's 9-part article in TIME Magazine denoting ALL of what I suffered at Fresno hospitals in 2005, and you can just GUESS my opinion of most U.S. medicine now! My best doctor ever (1972-1985) told me in 1985 he was CLOSING his practice and going into retirement, as he saw all this coming, and all the paperwork had started to limit his ability to practice MEDICINE! Sad, that 30 years later, his predictions were much BELOW how bad most U.S. medicine has now become! 400-500 years from now, when we are gone and a detached history of the U.S. is written purely from research, I expect current U.S. medicine to get cited as one of the cruellest FAILURES and one of the worst national DISGRACES in the entire history of mankind!! As for me, I am resigned to dying, either directly from the bladder cancer, or because everyone involved (but the urologist) DELAYED TOO DAMN LONG, and it may have metastasized (spread) into other parts of my body. If so, you all have XMGR/RDISK/UIDE/etc. in essentially mature form, and they should serve you well if I am gone. I say again, as in 2011: If you find yourself visiting the U.S.A. and are taken ill, do your very BEST to get BACK on the airplane and get treated in your own countries, NOT here!! And to all those of you who are Americans, do at-least get some sort of medical insurance, so it can intervene against EXORBITANT medical charges that we CAN charge!, as I was told in 2005! And PRAY you can find doctors and hospitals that are any good! -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Freedos-user mailing list
[Freedos-user] Updated UHDD/UDVD2 Drivers: Caching Re-Added.
Johnson Lam has posted a new 26-Jan-2014 DRIVERS.ZIP file, with a corrected UIDE and an upgraded UHDD/UDVD2, in his dropbox at -- http://dl.dropboxusercontent.com/u/15785527/drivers.zip UIDE had an error in its /B stand alone driver, which would not ignore CD/DVD media changes as it should. The error is fixed in the 26-Jan-2014 UIDE. Users who load UIDE only for caching (not in /B stand alone form) were not affected. Also, it may have been unwise for me to delete caching from UHDD/ UDVD2. Users who want UIDE for caching and UHDD/UDVD2 for tests or non-caching work must then carry around 14.5K of files. No problem with hard-disk drives, but it is wasteful if using boot diskettes (like my backups!) or on other small systems. So, UHDD again does caching with both /S Common and /C CD/DVD caches (like UIDE) and can be assembled with 2 more User caches if user drivers ever need them. UDVD2 again calls UHDD to cache CD/DVD data, using UHDD's CD/DVD cache when specified, or using its Common cache if not. When UHDD loads stand alone, UDVD2 makes no caching calls, but it still shares UHDD's XMS buffer for input unsuited to UltraDMA. This avoids BIOS disk I-O or CD/DVD PIO mode input, and so improves speed! Although a bit slow, both drivers can still be used on systems with no XMS memory. Note that both drivers RETAIN their non-caching capability! The non-caching UDVD2 is still 2000 bytes (144 memory, 1856 HMA), and it still adds only 96 bytes if calling UHDD for caching. The /B stand alone UHDD is still only 1408 bytes (640 memory, 768 HMA) and UHDD.SYS has been held to only a 5.5K file, even with caching added. All its caching logic disappears after Init, if its /B switch is given, so the increase in file size should not matter. Users wanting a small driver set for diskettes, etc., can again run only UHDD and UDVD2, whose .SYS files total 9.5K (not a 14.5K set as before), and which again provide full caching capabilities without requiring the larger UIDE. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New 12-Jan-2014 UIDE, With 4 Caches!
Bernd, The Common cache is always set and uses a default size of 80-MB. All 4 caches can be from 0 (unused) to 4-Gigabytes, and their only rule is that their total size cannot exceed a system's XMS memory! You make it sound like I could use 4 caches of 4GB each, nice to fill up a larger part of my 32GB system memory :) Not yet! Nobody has seriously requested of Japheth's JEMMEX/HIMEMX or my XMGR that they offer more than V3.0 XMS's limit of 4-Gigabytes. Until then, all of UIDE's caches, its own four plus any user driver caches, must total 4-GB or less! Sorry if that disappoints you. ;) ... In any case, I wanted to get multi-caching done in UIDE, while I still had some ideas about HOW to do it!! Enjoy 2014 in good health Jack! Thanks for updating your work. You are most welcome, Bernd, and my Thanks for your nice comments! Jack R. Ellis -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New 12-Jan-2014 UIDE, With 4 Caches!
Dennis, You make it sound like I could use 4 caches of 4GB each, nice to fill up a larger part of my 32GB system memory :) Allocate a *huge* ramdisk, copy your FreeDOS filesystem to it, and run *everything* from the ramdisk. Then copy anything changed back to HD when you quit. Bootup will be slow, but operation will be blindingly fast... You missed Bernd's point. He wants to use more than 4-GB of memory, which is impossible with any current DOS software I know about. One or all of the XMS managers still in maintenance (my XMGR, Japheth's HIMEMX, and his combination JEMMEX) would need an upgrade, to support over 4-GB of XMS memory. My own RDISK driver creates up to a 2-GB RAMdisk, but I wrote it as a FAT16 driver to run with old DOS systems, like my own V6.22 MS-DOS. 4-GB FAT16 RAMdisks are possible, but not all DOS systems work with them -- V6.22 MS-DOS CHKDSK CRASHES when RDISK is patched for 4-GB! Jack R. Ellis -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New 12-Dec-2013 UIDE Driver.
Johnson Lam has posted a new 12-Dec-2013 DRIVERS.ZIP update in his dropbox at: http://dl.dropboxusercontent.com/u/15785527/drivers.zip UIDE now offers a separate CD/DVD cache, with a /C switch, for users with an old CD drive requiring limited seeks, to avoid tracking errors and low speed. UIDE still offers user-driver caching (though nobody uses it!), now with a more positive way of finding UIDE and linking to it for caching calls. The UHDD and UDVD2 drivers are both gone. Users did not want UHDD for PCs with no IDE CDs/DVDs, or UDVD2 for kiosks or boot diskettes. Many go on using the BIOS for disks. And they go on using VIDE-CDD or OAKCDROM for CDs/DVDs, despite no PCI- bus support, no UltraDMA, nor any caching. Pitiful. But, who am I to argue more! So, I decided to get RID of all my dead-wood, and we are now back to the one and only UIDE. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] LBA And FreeDOS.
Karen, I certainly agree with your stance here. I have been using one ms-dos 7.1 package since at least 2007 or so, easily and effort- lessly. I have helped others find it as well. I am not sure where the .bg country code is, but I could not connect to the site when I tried it before writing this note. It may be that they dislike low graphics browsers like lynx, or that they are now getting lots of traffic. For your info, .bg is Bulgaria. Given both Dennis's and your problems with the website I noted, I suspect there could be some international constraints AGAINST Bulgaria, in some areas! I need, no demand smiles reliability, so skip buts myself. I have not used ms-dos 6.22 for a grand while though, my need for much larger drives, the one I use for backup is over 30 gig, made the 7.1 door more practical. I do wonder sometimes though if I could accomplish a bit of both worlds. What stands out for you in dos 6.22 over the later 7.1 edition of ms-dos? My father was a packrat (saved EVERYTHING), and I am not. My total storage, after almost 50 years of software, is only 180-MB and fits easily on CD-RW disks, of which I have 3 as my backups. Thus, I do not need FAT32 or long filenames, and I do not need the bloat that comes with most V7.10 MS-DOS programs. I also do NOT like that V7.10 will LOSE a lock drive command for some reason that I have never understood, and that is a nuisance as it always occurs when I do not expect it. So I stay with V6.22 MS-DOS, which is NOT bloated, and has NO lock drive to cause me any profanity! My actual Internet vehicle is V4.0 Win/NT, since there are no good browsers, CD burners, etc., for use with MS-DOS. V6.22 or V7.10 helps me there, as Win/NT denies me the right to deal with some system files. V6.22 MS-DOS does not! Most important of all, hear hear on using what you desire. It is why there is a personal in pc after all. A pleasure to know you, dear Lady, after all my dealings on this forum with legalists who FAIL to see that I was only giving an EXAMPLE of V7.10 still being available!V6.22 MS-DOS and V4.0 Win/NT also save poor-old retirees like me from paying $500/year tribute to Gates Co. for their semi-annual collection of new BUGS, which they call service packs! BEST wishes, Jack R. Ellis -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] LBA And FreeDOS.
It's really too bad, though, that MS won't make it official and release the MS-DOS source as public domain, or at least one of the various open-source licenses. Surely you JEST!, my friend [are joking]! Gates Co. are charter members of the U.S.A.'s All we want is MONEY! brotherhood! -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New 14-Nov-2013 UHDD/UDVD2 -- Private Caches Deleted.
The UIDE drivers have all been updated to 14-Nov-2013, and they are now available from Johnson Lam's dropbox at -- http://dl.dropboxusercontent.com/u/15785527/drivers.zip In this update, UHDD and UDVD2 no-longer support private caches for user drivers. Reasons for this are a bit involved -- First, My error and my apologies: CD/DVD private caches were NOT needed to support CD/DVD kiosk systems (no hard disk), in Hong Kong or elsewhere. If loaded with its /N1 switch, UHDD dismisses (does not load) all disk/diskette logic, saving 896 bytes.CD/DVD drives thus have a private cache anyway, since disks/diskettes will not be using UHDD due to /N1. I simply forgot about that! Second, no one yet (to my knowlege) has written any other driver that calls UHDD or UIDE to cache its data. Not an immediately simple job, as one can see in the UDVD2 driver which does call UHDD. But it CAN be done!Sadly, I am aware of how little development/update of any DOS drivers now happens. If no one calls UHDD for caching, private caching is also not-needed. Finally, nobody showed ANY interest in caching old video game CDs for higher game performance. Either such CDs have disappeared, or game players must now be using RAM-disk drivers, or whatever.Sad, as I felt such a feature would be valuable -- seems to be Not so! So, the 14-Nov-2013 UHDD and UDVD2 drivers are put back to having a single cache, that withing UHDD. This saves over 900 bytes of setup logic in UDVD2, from not reserving XMS for its own cache, and it also saves 192 bytes of run-time logic (128 in UHDD, 64 in UDVD2). UHDD/ UIDE also gain minor code optimizations, and XMGR/RDISK are unchanged except for being redated to 14-Nov-2013. Any users who ever DO need a private cache can get the same results by loading the RDISK driver to set a RAM-disk for their data. RDISK handles up to 2 GIGABYTES of data (uses XMS memory), and it may run a bit faster due to no overhead from cache look-ups nor from a CD/DVD Redirector program (SHSUCDX, SHCDX33F, etc.). -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] UIDE Updates: NOT Losing My Mind!
Re: Rugxulo's FreeDOS front-page comment about Another week, another UIDE update, I want to assure people that, despite now being age 68, I am NOT losing my mind! The 20-Aug-13 update was to provide CD/DVD kiosk users in Hong Kong (and elsewhere) a way to cache CD/DVD data without loading the entire 4.5K UIDE driver. My partner Johnson Lam asked for this, so I did it. But, I was UNHAPPY with the size of UCACHE2, and so -- The 26-Aug-13 update makes UHDD able to run private caches, with NO separate caching driver required. UHDD still has its common cache for old drivers, and it may now be called by the updated UDVD2 and by other updated user drivers (if any!) that desire private caching. The 2-Sep-13 update fixed a possible media-change problem in UDVD2. I say possible because UDVD2 ran fine, but its logic did not appear correct. So I upgraded it, to stay safe. Safety MATTERS, to me! The 9-Sep-13 update fixed more possible but unlikely errors in UHDD re: resetting its user parameter-table pointer. The reset cannot be done if UHDD rejects an I-O request because another is still running. If the running request LOSES its cache parameters, a CRASH may occur! Also, the reset should not be done for BIOS requests that UHDD is not going to handle. I am unsure all old DOS versions have media-change logic for a HARD-disk flagged as removable, i.e. a USB disk.So, UHDD/UIDE are written to stay safe and IGNORE any such disks! I have never heard of any cases where multiple I-O requests have been issued to UHDD/UIDE. DOS uses a one at a time I-O scheme, as most developers know. Nor have I heard of many cases where an odd BIOS disk gets ignored by my drivers. But to remain safe, I fixed both cases in UHDD, and I apologize for not having realized all this while adding UHDD's private cache capability. I get bugs, too. Finally, though we are years away from a Super Blu-Ray CD/DVD drive requiring 32 LBA bits (8 Terabytes), UDVD2/UIDE using only 30 bits in caching was a problem waiting to happen! The problem has now been corrected in both drivers. Those are my REASONS behind the 4 recent UHDD/UDVD2/UIDE updates, and everyone can rest assured that I am NOT losing my mind! -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New UHDD/UDVD2 -- A Clarification!
An important clarification about the new UHDD and UDVD2 -- UDVD2 is still a CD/DVD only driver of 2000 bytes. It has NO cache routines of its own, as I am aware there are CD/DVD only users that desire a SMALL driver for their use! UDVD2 still adds merely 96 bytes to call UHDD for caching, or 128 bytes if it now calls UHDD with its own private cache. Do note that any UDVD2 or user-driver caching requires UHDD to be loaded first! UHDD is the cache driver, and only it has the actual caching routines. I got rid of UCACHE2 since I was UNHAPPY about it burning an extra 1700 bytes! (UIDE can also handle caching calls, but nobody has ever done so). Note also that private caches can be set only with BOTH the new 26-Aug-2013 UHDD and the new 26-Aug-2013 UDVD2! All older UHDD/UDVD2 drivers have no private cache routines and will continue to run on only the one UHDD cache, as before. Users who do not desire disk/diskette handling can minimize UHDD with its /N1 switch. This saves 848 bytes, and it will make UHDD into a small cache-only driver. For CD/DVD only or other such systems desiring only one cache, UDVD2 can omit /N and simply run on UHDD's cache, as before. Jack R. Ellis -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New UHDD/UDVD2 -- A Clarification!
My apologies -- In my earlier E-Mail today about UDVD2/ UHDD, I meant to say: For 'CD/DVD only' or other such systems desiring only one cache, UDVD2 can omit /S [not /N] and simply run on UHDD's cache, as before. -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Using UHDD/UIDE In Protected Mode.
An IMPORTANT note on using UHDD/UIDE, which I felt needed to be posted -- Protected mode users (JEMM386, EMM386, etc.) who run UHDD or UIDE should load these drivers with their /F switch. For caches of 80-MB to 1023-MB, /F causes UHDD/UIDE to have 64K cache blocks, not 16K blocks. 64K blocks run MUCH faster for protected-mode, since the drivers need to process only 1/4 as many cache blocks on most files. /F helps to maintain the speed of UHDD/UIDE on any protected mode DOS system! Real mode users (UMBPCI, etc.) are far less affected and may omit /F for higher cache capacity. In real mode, the UHDD/UIDE MvData subroutine has its own FAST logic to handle XMS memory moves (NO slow Int 15h traps needed!), and it is not bothered by cache-block sizes! 16K cache blocks are 90% efficient in cache capacity, while 64K blocks are only 70% efficient, due to wasting more space in the last cache block of a file, which is seldom filled. If /F is given, users can compensate for the lower net cache capacity of UHDD/UIDE by setting a bit larger cache, which most current 1-GB to 4-GB PC systems should easily permit! -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DISGUSTED With Pundits!!
A++ would read again For all those of us who do not speak Germanicized English, would you care to say EXACTLY what-in-HELL the above means?? Regards from our Bunch of Trolls That Ruin (TM) And Greetings to you, Mr. Junior Troll (VERY junior, indeed!). I see you must have learned NOTHING, from when the late Pat Villani had to address you about some of your posts against me, back in 2010!! You should look-up what we mean, when we say someone like you is grandstanding!! -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] DISGUSTED With Pundits!!
I don't know ... Well, Mike, at least you ADMIT to it! ... but if there was a utility to analyze the tone and content of messages and rank them I think that a lot of your messages to this list would be labeled aggressive/hostile. Tough tomatoes. If you don't like my tone, for which I have my reasons, then don't read my posts. You have ranted against BIOS manufacturers, IDE chipset vendors, software companies, other open source software projects, people who don't speak English natively, etc. Never without a reason. Mostly, as was true of my 35 years in assembly-language (plus 11 more in retirement), it is because I get to be The poor bastard who must MAKE IT WORK!! My good friend Ehlert told me about 2003 that he never thought a driver like UDMA (evolved into UIDE) could ever be written. I did it, and in doing so I had to shovel a lot of just-plain SH*T caused by other people's BAD specifications, design ERRATA, etc. That, my good friend Mike, is why I speak so agressively AGAINST such trash. If I say the entire Wintel consortium needs a carload of ExLax, like Apple and others are PROVING to them now, it is NEVER without reasons, reasons I am always stuck programming AROUND!! The entire combined software/hardware industry does not exist just to piss you off ... No, Mike, only you do ... If there is a problem with VirtualBox then I am sure that there is a developer who will listen ... Fine, Mike, then you speak to them. I do not use VirtualBox as I still have a real PC running a real DOS kernel, not a 32-bit system that needs any such emulator. So I am not-interested in working on an emulator I neither need, want, nor like! Perhaps YOU can convince them to reinstate code that would have set 2 bits in 1 byte (as Eric found DELETED in their sources!), and this mess would never have occurred. Surely you are up to telling Almighty Oracle what their error was -- GO for it! I will speak heresy, but if it really matters that much then maybe the correct thing to do is to have two different versions of the driver - a correct one and one that works in broken environments like VirtualBox. Your privilege again, Mike. My drivers are not GNU nor any other licensed form of open-source. Still, I do provide their sources, and that by implication says you are free to fix them as you wish. Again, GO for it! I will continue to offer UHDD and UIDE drivers which follow the BIOS conventions for handling diskettes, as I understand such conventions to be, which you refer to above as the correct drivers. Your own broken environment drivers can be as you wish. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] DISGUSTED With Pundits!!
I have not posted on this forum in almost 5 months due to the rather VICIOUS attacks on me by Bret Johnson, Ralf Quint, and Tom Ehlert re: diskette detection in the UIDE drivers. However, this post has now become necessary. Shown below is an E-Mail which I received early this morning, from Christian Pfaller of Germany (forwarded by Johnson Lam). Pfaller's problem is most likely a direct result of the logic I added with the 29-May-2012 UIDE, which tests for up to four diskettes using BIOS calls, instead of testing for only 2 via directly checking the BIOS diskette-flags byte. That change was made by me under duress, i.e. by the above damn FleaDOS pundits INSISTING I obey the Ralf Brown lists and issue the BIOS calls, so damn VirtualBox could be run without its OWN diskette-detection problems getting CORRECTED!! Pfaller indicates the last UIDE version which worked with his LS120 drives was 20-May-2012, the version BEFORE I put in the diskette BIOS calls. I shall immediately PUT BACK the diskette test logic from the 20-May-2012 UIDE into the current UHDD/UIDE drivers.After appropriate checking by me, Johnson, and Christian Pfaller, I shall release an updated set of drivers on Johnson's website. Eric, if your VBOXFIX program is still available, you might want to re-issue it, with its specific logic to test the bits in the BIOS diskette flag byte for the presence of diskettes, when VirtualBox is used. I intend to use that byte again, and NOT use BIOS calls to check for diskettes! You may also want to INSIST that the VirtualBox emulator fools FIX their diskette-detection logic to post the BIOS diskette-flags byte properly, which would have AVOIDED all of this mess! Now, I will again unsubscribe from FD-User. And I hope NO ONE expects me to listen to any of its pundits ever again!! Jack R. Ellis = Original Message Subject: Problem with the UIDE Cache and LS120 Diskette Drives. Date: Thu, 11 Oct 2012 20:03:58 + From: MR-LEGO mr-lego...@web.de To: Jack R. Ellis [forwarded from johnsonlam...@gmail.com] Dear Mr Ellis. Thank you for your great drivers. They work very fine. But I have a problem with the UIDE cache in conjunction with an LS120 Diskette Drive. I found the problem by checking three LS120 diskettes on last Friday. Yesterday and today I made some several tests with it. I use the latest version [2012-08-04] of UIDE. For example I load UIDE with the parameter /S25 (with 25MB-cache). If I check now a LS120 diskette with DOSFSCHK, it told me that the first and the second FAT are not be the same. Now I load UIDE with the parameter /B (basic, without cache). Then I check the LS120 diskette with DOSFSCHK, no errors were found. If I make a 1:1 image of a LS120 diskette and UIDE-cache is loaded, the content of the image isn't the same as the diskette. Now I make a 1:1 image of a LS120 diskette without the UIDE-cache, the content of the image is the same as the diskette. This problem only appears with the LS120 Diskette Drive. I tested UIDE under FreeDOS and MS-DOS and the result is the same. I tested it on another computer with another LS120 Diskette Drive, too. The oldest version of UIDE [2012-05-20] I tested doesn't have this problem. Many thanks for your help. Best regards, Christian Pfaller -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] UIDE Diskette Change Line Capability Tests.
Bret, A favorite tactic of propagandists, be they Fascist/Nazi/Communist or others, is that they flatly IGNORE any information from opponents and simply go on spouting their own ideas. In responding to the above thread, you have totally IGNORED all info I offered to begin with, and you cite, as your reference, a 1991 IBM Technical Reference for the PS/2. That reference is now 21 years old, and was written for a computer that AFAIK has NOT been sold by IBM for YEARS! I can also note how IBM in fact LOST control of their own PC market beginning about 1985 to vendors in Japan and Asia, due largely to the same class of FIXED thinking that you now exhibit! IBM thought they were Gods and Asia did not matter, and Asia just MASSACRED IBM in their own marketplace same as Crazy Horse did to Custer in 1876! I have NEVER given much trust to IBM, surely not after 1985, and I never will! So I will say it all again, for the cheap seats -- (A) The 1991 IBM Technical Reference for a PS/2 is 21 years old, was written for a system that is now obsolete, and MAY NOT have been kept current. (B) Using byte 0:048Fh is not undocumented. BIOS Central has noted this from at-least 2006, when I first read their BIOS data list. (C) As of 11-Jan-2007, 16 years PAST your IBM reference, Phoenix and maybe other BIOS vendors do in fact support byte 0:048Fh exactly as BIOS Central describes that byte. I have such a BIOS, and I expect others using a hardware PC can verify that 0:048Fh DOES work exactly as BIOS Central indicates, DESPITE some 21-year-old IBM reference calling that byte reserved. (D) UIDE/UIDE2 have NEVER failed, to my knowledge, to cache diskette data and deal with diskette media-changes, if used on any actual hardware PC system. If so, I want to KNOW about it and shall FIX any such problems, REAL QUICK!! (E) VirtualBox handling of diskette change-lines IS IN DOUBT! Eric did find (yesterday) a source file in which THEY DO set the byte at 0:048Fh, despite other parts of their emulator saying they do NOT support diskette change-lines. Since Their RIGHT hand may not know what their LEFT is doing! (a usual result re: too many programmers on one task!), I believe it is WRONG to say they are following the rules. WHOSE rules?? Even THEY seem not able to agree among THEMSELVES what those rules ARE!! And now, Bret, DO NOT merely spout your own propaganda again! If you have more to say, speak to the points -- SPEAK TO THE POINTS! -- that I have listed above!! And do so in private, as after this E-Mail, I will again unsubscribe from FD-User.Jack is right and everyone else is an idiot, Are you trying to prove yourself smarter than everyone else, plus other such INSULTS will be ENOUGH for me! Use UIDE/UIDE2 if you think they work. Otherwise, do not use them. Your choice. I think they work, I have evidence to say they should and NO actual PROOF to the contrary. So I will leave them as is. Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
I was about to post bugreport at VirtualBox bugtracker, but decided to double-check the issue first. On my system floppy images change are correctly recognized. VirtualBox 4.1.4-3.2.3 OSE OpenSUSE 12.1. The issue is that VirtualBox is not posting diskette media-change status in the BIOS data table. So a cache (like UIDE/UIDE2), that needs to know when a new diskette is loaded, is NOT being notified, and the cache will continue to provide data for the PRIOR diskette! If only the VirtualBox diskette driver is used (no cache), there is no problem. To use a cache, or any subordinate diskette driver, posting the BIOS media-change status for a diskette MUST be done by VirtualBox! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Tom: The issue is that VirtualBox is not posting diskette media-change status in the BIOS data table. the 'issue' is that VirtualBox clearly states 'floppy without change-line support' int13/15 returns '01h floppy without change-line support int13/16 returns '06h change line active or not supported but UIDE ignores this, and relies on change line support anyway. You are WRONG, Tom!! UIDE has NEVER ignored if a diskette has change-line support! It does in fact check the BIOS data table at 0:448h for bit 0 (change line for diskette A:) or bit 4 (change line for diskette B:). If those bits are off, diskette A: or diskette B: will not be cached. My update to UIDE in adding the /E switch was simply to add a mask which is 011h without /E, 000h with /E, to mask against the bits at address 0:448h. This works fine. With /E, the mask prevents UIDE from seeing any change-line bits, so diskettes go uncached. But, if what you wrote above is correct, VirtualBox expects people to use ONLY the Int 13h requests, when determining if a diskette has change-line support. And in any event, by indicating NO such support, as you also wrote above, they make it impossible for UIDE to cache diskettes anyway! I will NOT cache a drive which cannot tell me when its media has changed, and I REFUSE to add all of the logic in UIDE that Eric notes the DOS kernel contains, to find out if a media-change has occurred using other methods! So, I shall amend my earlier post to say that VirtualBox now needs TWO changes: (A) It needs to provide media-change status for each diskette, and (B) It needs to provide a PROPER BIOS DATA TABLE, as the table bits that are seen when VirtualBox runs are INCORRECT! maybe the real issue is that noone finds the time to do a tiny bit of debugging the problem but finds a lot of time to write loong emails To which I shall add: Maybe you might have read the UIDE.ASM file before making any BASELESS and WRONG accusations about my drivers! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
UIDE has NEVER ignored if a diskette has change-line support! It does in fact check the BIOS data table at 0:448h for bit 0 (change line for diskette A:) or bit 4 (change line for diskette B:). If those bits are off, diskette A: or diskette B: will not be cached. if UIDE would check INT13/15 if change line is supported, and not cache the floppy if it's not supported everything would be fine (and /N5 not needed). I can't locate any documentation about 0:448. Apologies, I misread my own source file (early!) this morning. UIDE and UIDE2 check 0:48Fh (not 448h) for the bits that indicate if drive A: or B: suipport a media-change line. Note the BIOS data lists at: http://www.bioscentral.com/misc/bda.htm My update to UIDE in adding the /E switch was simply to add a mask which is 011h without /E, 000h with /E, to mask against the bits at address 0:448h. This works fine. I prefer software that works without switches. at least if it can handle the situation itself. And I prefer emulators which emulate EVERYTHING, including a valid alternate way of determining change-line support! But, if what you wrote above is correct, VirtualBox expects people to use ONLY the Int 13h requests, when determining if a diskette has change-line support. wrong. VirtualBox tells you 'change line is not supported' which part of this is difficult to understand? I run V6.22 MS-DOS and V4.0 Win/NT, that I got for free in 1994 and 1998 as a software developer. I have never run any later Windows, Linux, or other C-based systems. So, I have never used VirtualBox and have NO REASON to study its documentation or sources. I rely on what others tell me about it, and before today NOBODY ever told me it positively states 'change line is not supported'. What part of THAT do you not understand?? We all cannot be experts on everything, and after all this, I in fact want NOTHING TO DO with VirtualBox, as it too-often proves itself a piece of TRASH!! And in any event, by indicating NO such support, as you also wrote above, they make it impossible for UIDE to cache diskettes anyway! exactly. hands off these floppies. Thus you joke about this being GOOD?? I think it is PATHETIC that they choose not to support diskette media-changes!! maybe the real issue is that noone finds the time to do a tiny bit of debugging the problem but finds a lot of time to write loong emails To which I shall add: Maybe you might have read the UIDE.ASM file before making any BASELESS and WRONG accusations about my drivers! neither BASELESS nor WRONG, and neither accusations. Just stating that they behave suboptimal. I say again, apologies for my referencing 0:448h this morning, when I should have referenced 0:48Fh as UIDE/UIDE2's source for the diskette media-change flags. However, suboptimal has NEVER been a problem, at-least never before VirtualBox, and UIDE/UIDE2 have worked properly using this scheme for 6 years! I also say again: I will NOT add any (large) amount of logic in UIDE merely to handle one miserable emulator program which admittedly is NOT emulating EVERYTHING! On any hardware PC system, UIDE's logic for handling diskettes and their media-changes runs fine. As I want to keep UIDE/UIDE2 simple, I shall leave things as-is. If users want to run VirtualBox, they can simply use UIDE/UIDE2 /E which specifies 'hands off those floppies' (like Tom stated above), exactly as the writers of VirtualBox intended! No diskette data errors, and everybody should be happy! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
UIDE has NEVER ignored if a diskette has change-line support! It does in fact check the BIOS data table at 0:48Fh for bit 0 (change line for diskette A:) or bit 4 (change line for diskette B:). If those bits are off, diskette A: or diskette B: will not be cached. That is an interesting bug in VirtualBox then (wrong 40:xx data) but I support Tom here because int 13 is the front entrance to knowing if change lines are supported. Whether and how this uses the back office 40:xx data and whether this data reflects the official statement returned by int 13 is not always reliable, so asking int 13 is probably better ... Who says there is a front office and back office way of dealing with diskette media-changes?? Both seem valid to me! And if the two methods do NOT return the same info, we should CORRECT whatever program (VirtualBox, in this case) which has CAUSED such a problem, rather than requiring all previously-GOOD software to get changed! Also, it would be very easy for UIDE to ask int 13 instead of or in addition to 40:48 bits. Would take more logic, and is NOT needed on any hardware PC. As I am NOT working for VirtualBox (or I damned-well HOPE not!), let THEM make changes to address the problems they have created! But, if what you wrote above is correct, VirtualBox expects people to use ONLY the Int 13h requests, when determining if a diskette has change-line support. And in any event, by indicating NO such support ... they make it impossible for UIDE to cache diskettes ... Indeed. But it is better to not cache than to damage data. Another statement on which you can bet your [rear-end]! Given the new information from Tom, I agree that it is not worth the effort to add heuristic cache flushing, as it turned out that it IS possible to detect that no change line exists in VirtualBox. So VirtualBox users will not enjoy UIDE caching, but please do use int 13 (instead of or even better in addition to 40:48) for the detection of systems without change lines... That will protect VirtualBox users from data loss dangers! So will UIDE/UIDE2 /E, and so I shall leave my drivers as-is. To which I shall add: Maybe you might have read the UIDE.ASM file before making any BASELESS and WRONG accusations about my drivers! The sources are circa 4000 lines long and do not even mention change line. Now that you explain how UIDE works, I was able to find this snippet: mov al,FMCMask ;Use diskette media-change bits and al,es:[MCHDWFL] ; for our number of diskettes. I_FScn: testal,001h ;Can next unit signal media-changes? jz sI_FMor ;No? CANNOT use this old clunker! where MCHDWFL equ 0048Fh. You claimed that you would check 40:48, not 40:8f, but I could not find anything in UIDE which checks 40:48 and RBIL does not give any meaning for 40:48 either. Looking at RBIL for 40:8f, I see that you can check whether drives support 80 tracks and/or multiple baud rates, but not on XT and nothing is said about change lines being flagged by this byte according to RBIL. See my earlier post this morning re: the BIOS Central list of what is present in the BIOS data table at 0:48Fh.I am not surprised if change-line data is not specified for an XT as they were not available till 1985, back in the AT days! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
It's not impossible to cache floppies, Jack. You just need to do it differently than you're doing now ... Back in 1980, I told an old friend of mine about a 750K video-driver package which I had seen (written in C, of course!), and he noted, They've got GUTS, calling that a DRIVER! If I had done your type of diskette caching, your type of re-entrant driver, and all else you seem to suggest, GUESS what that would add, to the size of UIDE/UIDE2!! Since my drivers work in at-most about an 800K-byte DOS system (640K low-memory plus maybe 160K with LOL!), I will keep them SMALL, and NOT end up with any 64K-byte ATROCITY like at least one I have seen! And certainly, it is not impossible to cache floppies.Before the debut of VirtualBox, UIDE/UIDE2 had done so successfully, for years, without any complaints at all! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem
You are WRONG, Tom!! Is he ? or are you being RUDE, Jack? Tom could have written me privately, before publicly saying UIDE assumes change-line support, but did not. I responded in kind! Not Tom, but I'd like to learn from /what exact source/ you got the definition for those bits. My error; the byte accessed by UIDE is 0:48Fh as I noted earlier, when I also noted the BIOS Central website as my source. Now, puhlease! don't feel accused - I'm sure you did not make those bits up and that they work in your test machines and even for the bulk of your users. That you wait for users' complaints before checking the soundness of your assumptions is another question entirely. Unless BIOS Central posts incorrect data, my assumptions WERE sound! You are entitled to choose any method that works on recent gear if you find it convenient. Thank you, and so I shall keep UIDE/UIDE2 as-is. But rather than pretending to support floppies on the whole range of DOS-capable PCs, and claiming that those that do not conform to your model are junk (or is it the users' fault ?) - you /must/ find a way to programmatically assert that your far from universal method /will/ work and take measures otherwise. IMHO you can't leave it to the (clueless, always...) user to assert his or her PC is not conforming to UIDE's model. There is NOTHING wrong with UIDE's model, unless you can positively REFUTE the data provided by BIOS Central, which is what I used back in 2006 when I added caching to my drivers. They have worked on all hardware PCs since then, so I shall NOT assume to be using any far from universal method. And, I say again: Hardware change-lines do work, have since 1985, and any which do not are a MAINTENANCE problem for the user, NOT any reason to re-engineer UIDE. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Jack, PLEASE, don't pull yourself up on the VirtualBox issue, it is rather a more general problem. You simply rely on the contents of the memory region rather than than properly query system via INT13. And that isn't adding much to the logic and overall size of your drivers compared to the indiscriminate reliance on the validity of the BIOS data area. Who says that properly querying system via Int 13h IS in fact proper?? Why would the BIOS include the flags at 0:48Fh if the BIOS designers did NOT intend them to be USED?? And who says it is indiscriminate, if I rely on the validity of the BIOS data?? This time, my friend, you have REALLY overstepped your bounds!! Yes, this will be more likely an issue with a(ny) virtual machine setup than with a real iron box, but then querying the DOS interrupt would rather help for example to make use of the floppy drive caching in a system with more than 2 floppy drives... UIDE/UIDE2 are designed to support a maximum of 2 diskettes. Since diskettes are no-longer offered for general sale, and people now use USB devices, etc., I see no reason to worry about 3 or more diskette systems -- very few ever existed, and they needed special software!! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Eric, Apologies, I misread my own source file (early!) this morning. UIDE and UIDE2 check 0:48Fh (not 448h) for the bits that indicate if drive A: or B: suipport a media-change line. Note the BIOS data lists at: http://www.bioscentral.com/misc/bda.htm This document states that bit 0 and 4 indicate change line support for drive A: and B: respectively, but RBIL states that the bits are about 80 track support. A safe option would be not to read 40:xx coffee grounds but instead use the well-documented int 13 interface... As I just got through noting, in another post, why would the BIOS data include diskette change-line flags if they were NOT intended to be USED?? Until someone can positively REFUTE the data offered by the BIOS Central data-table list, my opinion is that neither you nor any- one else can say Int 13h is better or 40:xx is coffee grounds! Given how UIDE/UIDE2's diskette I-O has never been a problem BUT for VirtualBox, I will keep UIDE/UIDE2 as-is. VirtualBox users now have the /E switch they can specify with my drivers, and all other users of hardware PCs and (NOT so flaky) hardware change lines will continue to run just fine! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
As I just got through noting, in another post, why would the BIOS data include diskette change-line flags if they were NOT intended to be USED?? Until someone can positively REFUTE the data offered by the BIOS Central data-table list, my opinion is that neither you nor any- one else can say Int 13h is better or 40:xx is coffee grounds! There is no need to refute anything, it all comes down to the very simple fact that IBM documented the mentioned INT13h BIOS calls, while vast areas of the BIOS data segment simply are not!!! And this makes using the BIOS data segment WRONG??? Comes to show that you are just out to prove another old engineering truth, good is the enemy of great. NO, you F*g S**t!! I am simply trying to show that I had to MAKE A CHOICE, when I wrote UIDE/UIDE2 in 2006. That CHOICE was NOT to use DOS/BIOS calls except where NECESSARY, and the data as noted by BIOS Central for byte 0:048Fh made it UNNECESSARY for me to issue Int 13h calls! This keeps UIDE/UIDE2 generic for use across ALL possible DOS variants, which was my MAJOR design goal! That, sir, IS A CHOICE, NOT any attempt to do as YOU seem to want to propagandize!! And I still STAND BY that choice, until you or anyone PROVE to me BIOS Central's data table is INCORRECT!! Just as Tom mentioned, this is all going nowhere, Du hast Recht und ich hab meine Ruhe... :-( Well, since you both have moved this thread to another level, I shall reply by saying only Zu BEFEHL, Herr OBERST!!! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
. A scan for devices by PCI class-code returns only devices that match the requested class/subclass/function In that case, the BIOS itself might be to blame - if it scans all possible locations instead of only used ones to return the scan-by-class-code result list ... PCI V2.0C and later versions have all worked just FINE, until the rather poor emulator know as VirtualBox appeared, using its MISERABLE emulation logic for the Intel PIIX3 chipset!! If they DO NOT have such long delay trouble with their ICH9 emulation logic, do you REALLY expect we should believe the PCI BIOS logic is now at fault, after almost 20 years?? The VirtualBox brats should take a long-hard look at their ICH9 v.s. PIIX3 routines, and CORRECT those for the PIIX3!! ... You also have to assume that the BIOS does not cache anything in that call, so to get a LIST of devices for one class, you have to ask the BIOS in a loop what is the first device for that class? the second? and so on, until an error is returned: The BIOS might have to walk the whole addr space for each time, counting devices of the requested class code along the way, and might do so in a non-efficent way / direction in VirtualBox... That is a problem ONLY for VirtualBox! In all other cases and when using a real hardware PC, it does NOT slow down my drivers at all, or anyone else's AFAIK! If the colleges no- longer teach C BRATS how to write decent and efficient LOOP code, then GAWD HELP US!! The best way to be sure to NOT lose time, in particular given the quality of certain modern BIOSes, seems to be to walk the right parts of the PCI address space in own code and use port I/O instead of high-overhead BIOS int calls. I mean int 1a.b1 is documented to use up to 1kB of stack while reading a PCI register using I/O takes only a few handful lines of Assembly code in pcisleep. Sorry, but I am NOT going to bash the PCI BIOS, not after it having been used successfully for almost 20 years! Nor am I going to change my drivers to have some other scheme in their device-scan, merely to handle the possibility of a bad BIOS! If a BIOS cannot run a proper PCI scan, it is NOT going to last long, before many more people than just me gripe REAL LOUD at its vendor, and the vendor shall be forced to FIX IT! The problem here is VirtualBox. It, AND ONLY IT, needs to get FIXED in many areas! All else, which has run O.K. before they came along, needs NO fixes nor any changes! any case, no one has ever complained about the speed of UIDE's or UIDE2's initialzation, except when running VirtualBox! True - on real hardware, even the worst case situation of scanning for controllers might be done in seconds, only VirtualBox is known to take minutes. Then Why-in-HELL do you suggest any OTHER possibilities, as in much of your comment above?? Also, better if you refer to UIDE in general... Honestly I am no expert in any UIDE* source, as things are very packed and rank small size over easy to read structures of the code ... I always did get the job of being The poor bastard who had to make it WORK!, and so I make no excuses for the complex nature of my code! UIDE/UIDE2 do all that they do in only a 7.5K or 7K-byte driver, whose run-time code is 5.2K/4.5K, written in assembly-language (which automatically disquali- fies most C types from understanding it). Do try to understand, as my damn ex-wife never did [part of why she BECAME my ex- 32 years ago!!], that I have a REASON for everything I say and do, same as for everything in UIDE and UIDE2!! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
Eric, Do try to understand, as my damn ex-wife never did [part of why she BECAME my ex- 32 years ago!!], that I have a REASON for everything I say and do, same as for everything in UIDE Just making suggestions for universally faster and more fool-proof UIDE, as I dislike the idea that people have to manually disable floppy caches or tweak their (virtual) hardware to properly load UIDE ... To make a long story short, after my one and your two long posts today, I see NO reason for any further changes in UIDE or UIDE2. Its PCI-bus scan is now virtually instantaneous, and its diskette media-change logic works, without problems. So I will obey our other U.S. engineering joke (along with our K.I.S.S. Principle), which is Don't MESS with SUCCESS! (and mess is the polite word!). With good hardware, UIDE/UIDE2 have run just fine from about late 2006 onward. With imperfect hardware, or any dumb emulator program, UIDE/UIDE2 users are now able to -- (A) Call the BIOS for disk I-O and so avoid disk PCI scans with /E, which still caches disk data after the calls. (B) Ignore hard-disks completely [no caching] with /N1. (C) Run unusual CD/DVD drives via PIO mode [no UltraDMA] with /UX. CD/DVD drives still demand a PCI scan, since they are not declared to me by the BIOS during init. (D) Ignore CD/DVD drives completely [no caching] with /N2. (E) Ignore diskettes completely [no caching] with /N5. I think that is ENOUGH to include in UIDE/UIDE2! Those who use VirtualBox or other imperfect garbage, who do not like having to forego some UIDE drive caching by using the above, should damned-well INSIST that VirtualBox etc. gets FIXED! I am VERY TIRED of having to add Band Aids into my drivers to deal with the FOOLISH errors of OTHERS!! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox U IDE2 init problem
The FAT file system is defined by DOS, and I want UIDE/UIDE2 to have NO run-time dependencies on the DOS system. Nice in theory, but unfortunately doesn't work in practice. Sure seems to, since before this thread, UIDE/UIDE2 have trapped only BIOS Int 13h I-O requests, and no one has ever complained that it needs to do anything more! DOS's management of the change line is under the sole auspices of the block device driver, not hardware/BIOS (INT 13h). Since the early 80's, the device drivers built into the DOS kernel for disks with removable media (floppies, removable hard drives) have not solely depended on the BIOS. Fine for them. But UIDE/UIDE2 are NOT block-device drivers, and never will be, since they need NOT be! ... If you're caching floppies, but ignoring the DOS device driver and just looking at the BIOS, you are out of sync with the OS. Then why, in fact, has no one ever complained about UIDE/UIDE2 diskette problems before VirtualBox?? I also dispute being out of sync with the OS. On a PC system with NO flaky diskette media-change lines, as I expect they all have been from 1985 on, SO WHAT if the DOS system does a timeout check?? It will find no change in the diskette UNLESS the user actually DID insert a new one, in which case the media-change line will also tell UIDE/UIDE2 that a new diskette is present! So, where in all that did we get out of sync?? If I'm not mistaken, this is the exact same reason you refuse to support removable hard drives with UIDE (you're afraid the BIOS change line might be invalid). You are BADLY MISTAKEN as anyone who read BTTR back in 2010 can tell you!! I refuse to support removable HARD disks as I can't be sure ALL variants of DOS have the logic to handle a media-change for a supposed HARD disk! Until I am POSITIVE of this, I will NOT have UIDE/UIDE2 taking the blame for any removable hard-disk NOT causing the DOS system to flush its disk buffers if a disk gets changed!! Also, to be fair in the particular situation that started this thread, this may not actually be the VM's fault ... It could in fact be the VM's fault, but it may not be. Since all diskettes from 1985 onward have had change lines, my strong suspicion is that VirtualBox simply is NOT posting a media-change bit in the BIOS data table, like any real BIOS would do. That is one more omission, or BAD BUG! if you will, in their emulation scheme!! NO re-entrant calls!, I say again! Having UIDE/UIDE2 issue an Int 13h of their own WOULD require re-entrancy! This has been discussed before, also. With few exceptions, TSR's and device drivers should ALWAYS be re-entrant. How can you guarantee, e.g., that a software interrupt (such as INT 13h) will never be called from inside a hardware (IRQ) interrupt handler (like INT 08h)? UIDE/UIDE2 trap only Int 13h calls, actually only I-O calls. Other Int 13h requests (if any!) are passed directly to the BIOS and don't execute on the UIDE/UIDE2 stack. My drivers will execute diskette or non-UltraDMA (or /E disk) I-O requests by calling the BIOS, but that needs no re-entrancy, as in such cases the BIOS becomes an extension of UIDE/UIDE2. So, since UIDE/UIDE2 do one at a time I-O requests only (including a call the BIOS I-O request), and as they have NO need to handle other Int 13h run-time calls, then Why-in-HELL do I need to have re-entrancy in my drivers?? Bloody waste of time!! Granted, an INT 13h call to actually read or write to a disk would not (normally) happen from inside an INT 08, but there's no legitimate reason it can't check the state of the cache or other similar housekeeping functions. You can/should not prevent IRQ handlers from calling functions/services provided by your TSR/device driver. And if an IRQ handler can do it, there's a possibility of re-entrancy. And if the user does such a call from an ISR, while my drivers are in fact still processing a PREVIOUS I-O request, where do I save the ISR call's variables, where do I get enough stack space to handle TWO (or maybe more) such re-entrant calls, etc.?? Also, what check cache status or housekeeping functions have you found to use in UIDE/UIDE2?? As I follow the K.I.S.S. Principle, TAKE A GOOD GUESS how many such functions there are, in UIDE/UIDE2!! What you suggest as legitimate is really DANGEROUS and IS NOT what most DOS device-drivers have EVER supported, including mine, given a long-standing DOS convention known as one at a time I-O!! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list
Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
Eric, When DOS detects an unreliable floppy change line hardware, it should use the floppy label / serial / similar to detect changes in software ... How does DOS ever detect that any hardware is unreliable?? I agree that it is nice to disable floppy caches, but maybe the kernel actually does something detectable in REACTION to detecting a floppy change? For example it might issue an Int 13h drive reset command which in turn can be caught by the UIDE2 driver and treated as a flush cache for THAT drive event? ... What do you mean maybe?? You and others are the kernel experts for FreeDOS, not me, as I still run V6.22 MS-DOS!! Also, I say again that I am NOT interested in any specific logic from the MS-DOS kernel, or the FreeDOS kernel, or in fact ANY kernel, for detecting diskette changes. My worry is that such logic may NOT be generic, and I want UIDE or UIDE2 to run on all DOS systems. Checking the BIOS media- change status has always worked in my drivers for diskettes (despite Bertho's worries about flaky change lines!), and so I will leave my drivers that way. Finally, as noted before in this forum, UIDE and UIDE2 make NO run-time DOS system calls and I also want to keep THAT generic feature in my drivers, as well! -- UIDE2 has only 16 spare bytes before it goes back over a 7K .SYS file! But, I shall find a way! Thanks :-) By the way, any chance to work around the VirtualBox huge-delay problem? Not without knowing WHY they take such a huge delay! In any case, UIDE and UIDE2 must scan for PCI-bus devices, so they can relate the PCI device-addresses to the addresses posted via Int 48h requests. That way, I know the UltraDMA address to use for every controller, since UltraDMA addresses are NOT part of Int 48h -- BAD error by the EDD BIOS people, in 1995! If the VirtualBox people cannot fix the huge delay in their PIIX3 logic, UIDE or UIDE2 still have their /E switch and can still do disk caching, after the BIOS handles disk I-O. If you prefer the BIOS way, would int 1a.b103 be an option? It scans by PCI class so you do not have to loop over bus/device. My drivers are ALREADY doing a PCI scan by class-code, so the huge-delay problem is not related to this. Note that for example PCISLEEP only uses raw I/O in getpci and skips looping over functions if function 0 of a bus and device number pair return PCI ID -1. So you scan only 1 out of 8 in such cases. Each bus has 32 device numbers to scan. Also, often you have far less than 256 bus numbers in use, saves much time. Doesn't matter. A scan for devices by PCI class-code returns only devices that match the requested class/subclass/function, so I lose no time by checking unnecessary busses/devices. In any case, no one has ever complained about the speed of UIDE's or UIDE2's initialzation, except when running VirtualBox! Also, better if you refer to UIDE in general, since UIDE and UIDE2 assemble from the same UIDE.ASM source and do nearly all the same initialization functions. A few differences re: how they allocate XMS memory and where they load, but their device scanning and setup is 100% the same. Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem and slow VirtualBox UIDE2 init problem
-- UIDE2 has only 16 spare bytes before it goes back over a 7K .SYS file! But, I shall find a way! I've never looked at UIDE closely, but there's always room for space improvement in assembly!! ;-) Maybe you should look again at the UIDE.ASM source file! I have boiled down its logic so many times that finding any MORE spare bytes is REALLY becoming difficult, even for me!! VBox lets you choose how much % of processor to use, so it doesn't have to use 100% all the time. I just wonder whether their bugs are due to their tweaked BIOS or some hidden instruction incompatibility or what. :-/ My own personal guess is that their bugs are more likely due to incompetent BRATS messing around with hardware about which they really are NOT qualified to mess with!! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem
Bertho, Given the high level of responsibility [Ha-Ha!] taken by the VirtualBox creators, it looks as if I will have to add another UIDE switch, that disables diskette caching regardless of what its other switches tell it to do. Jack, if I may chime in... I think you're now contemplating the right step. I can understand your frustration with VB in this instance, BUT imho your previous approach has been to ignore a few facts, that have nothing to do with that or another emulator or virtualiser : On REAL (old) PC hardware, the existence of floppy disk changelines is not guaranteed; even if the line is present AND properly connected it MIGHT be flaky or not work at all; or the BIOS might not update the bits you expect. MS-DOS (and, I presume, good DOS clones as well) will use alternate means and kluges to check for media change in the absence of a (credible) change line. Your DOS drivers could have been relying on DOS for checking media change, not on the BIOS or direct HW interrogation in the 1st place! My design goal for UIDE/UIDE2 was to write a driver that uses as FEW DOS system calls as possible.At present, UIDE/UIDE2 are more a BIOS than a DOS driver, and they need to handle only a BIOS Int 13h call after their initialization. I did so (A) to have a SMALL driver, not a Bloody MONSTER! like SMARTDRV or Norton NCACHE2, (B) to avoid DOS calls that may NOT be implemented the same across all DOS systems, and (C) to follow the old U.S. engineering joke known as the K.I.S.S. Principle whose letters stand for Keep it SIMPLE, Stupid!. UIDE/UIDE2 are thus generic for use on any DOS system, using very little of DOS during their initialization only.I want to KEEP my drivers that way!! I also DID try to find a diskette driver that I could include within UIDE, but by 2006 NONE were available, since the BIOS had long-ago taken over diskette handling, and NOBODY offered a separate diskette driver any more! I saw no reasonable choice EXCEPT to use the BIOS change lines and media change status codes, to handle diskettes. This has been the case in UIDE/UIDE2 since 2006, and NOBODY has ever complained to me about diskette media-change trouble until now. So, I DISPUTE your comments about the change lines being unreliable! They have been around from 1985, and if they ever DO fail, that is a maintenance problem for the user, NOT an indication that I ought to reconsider using them in UIDE/UIDE2!! Offering the user an option to switch diskette caching off is much better. As you are aware, SMARTDRV allows a user to select, disk per disk, not just for floppies, to cache or not to cache - and if cacheing, whether to allow delayed writes or just write-through. SMARTDRV has many problems. It takes a LOT of memory and is very heavily linked to MS-DOS, so it may NOT run on other DOS systems!! Also, it has never been updated to use UltraDMA, thus it cannot do I-O directly to/from cache memory (XMS). UIDE/UIDE2 can do both. Delayed writes are nice, but you PAY for them! given the size of SMARTDRV and NCACHE2. I felt it to be MUCH more reasonable if my drivers did a FAST Write-Through implementation, with UltraDMA and direct cache I-O, in only their 912 byte upper-memory size! -- UIDE2 has only 16 spare bytes before it goes back over a 7K .SYS file! But, I shall find a way! No doubt you will. In fact only 12 bytes, and I required only 11 of them for /N5, so UIDE2 still has 1 spare! It is still a 7K-byte .SYS file and it can be packed using UPX down to 6K for use on boot diskettes! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem
Bertho, ... I've not been defending MS smartdrive against UIDE - clearly they are not reciprocally substitutable, there are arguments for and against, either side, and also cases when it is not easy to choose. I've been mentioning smartdrive only for the fact that it lets the user explicitly remove one or several drive letters from caching, which is handy in some cases - not just floppies. Can't imagine WHAT cases, and no one has ever asked me to have UIDE cache or not-cache specific drives. UIDE's /E /N1 /N2 /N5 switches enable or disable caching for entire classes of drives, usually when odd hardware or software makes this necessary. Otherwise, people seem to want caching for everything, or no caching (UIDEJR) at all. So, I DISPUTE your comments about the change lines being unreliable! And I'm disputing your disputation :=) Several brand floppy drives used in PC-AT compatibles in the 1980s were known to have problems with the change line, and also pre-AT drives might not have change lines at all, or no BIOS support. Nowadays people might still be using old drives they recovered from old stocks or dumps ... No-longer a problem, since UIDE/UIDE2 now include /N5 for unfortunates who must run such clunker drives. I still choose to trust the BIOS which has configuration bits to say that a media-change can be indicated for a diskette. That and /N5 should be enough, even with old clunkers! MS-DOS took extreme care to avoid disk corruption, you may peek at the code if you are so inclined. Trusting the change line is /way/ too dangerous! ... Well, I say again that NOBODY has ever complained about UIDE/UIDE2 using only it for diskette media-changes! Probably works BETTER than Gates Co. ever imagined! A pity other things from them don't work as well! SMARTDRV ... takes a LOT of memory and is very heavily linked to MS-DOS, so it may NOT run on other DOS systems!! Also, it has never been updated to use UltraDMA, ... UIDE/UIDE2 can do both. Delayed writes are nice, but you PAY for them! given the size of SMARTDRV and NCACHE2. I felt it to be MUCH more reasonable if my drivers did a FAST Write-Through implementation, with UltraDMA and direct cache I-O, in only their 912 byte upper-memory size! Nobody is denying your drivers are sweet! THANK you!, after all of the above and all in other posts! -- UIDE2 has only 16 spare bytes before it goes back over a 7K .SYS file! But, I shall find a way! No doubt you will. In fact only 12 bytes, and I required only 11 of them for /N5, so UIDE2 still has 1 spare! It is still a 7K-byte .SYS file ... Thanks! As I noted, the K.I.S.S. Principle, and I shall ALWAYS follow it! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem
Ulrich, It's great that you added the /N5 switch for VirtualBox users. It was a really fast reaction. And the anger to be forced by a buggy program to create such a workaround is completely understandable - and makes your reaction even more worthy. THANKS! My Thanks to you, as well! I get few positive comments about UIDE -- people appear to take it for granted, I guess -- and I do appreciate your thoughts! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Eric, et al: thanks for the hint! I have commented out the line in autoexec.bat which loads the UIDE.SYS cdrom driver. Now there is no problem accessing the floppy images. So maybe there is a problem with floppy change signalling versus caches - would be interesting to know whether it is sufficient to keep UIDE but run UIDE in no-cache mode, and if lbacache flop (lbacache with floppy caching enabled) would work correctly with floppy changes in virtualbox. UIDE does not include logic to ignore a diskette drive. If one or two are present, UIDE will always cache them. I never expected any- one would need (or want!) to run diskettes without caching. One can use UIDEJR instead, but UIDEJR is only a driver with no caching and thus would not perform as well. Folks really should INSIST that the writers of VirtualBox Follow the RULES! for PC hardware, instead of leaving you and I (perhaps others as well) to make changes in long-established programs just for them!! Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Wolfgang, I am so happy that there is something like FreeDos available, even for free, that I can play around with. As I usually pretty soon run into very strange challenges for (any) software - some people say, that every computer that sees me for the first time, simply crashes, simply for this fact - I do not want to expect from the developers that they care about my issues by changing their baby. If there is a way to work around the issue, that's fine for me ... Should NOT be a question of changing their baby, since if the VirtualBox people had done a PROPER job of emulation, neither they nor I would need to worry about changes. However, I have now seen that VirtualBox (A) times out if UIDE tests for SATA/IDE drives using their ICH9 logic, (B) doesn't post a diskette media change flag, and God-knows what else!! Backward compatibility must be something they never have heard of, same as Microsoft proves with each new issue of Vista or whatever it is called today! Be-advised that UIDE does not have logic to flush its cache for specific drives; it can only flush its ENTIRE cache when a diskette/CD/DVD changes, or when the user issues a CC command (clear cache) to my CC.COM program. CC issues a BIOS reset to all hard disks, useful if one wishes to verify data written to a disk. So, a workaround for you, if you must ever use multiple diskettes in VirtualBox with UIDE again, is to issue CC if your diskette must be changed. This will flush UIDE's cache and prevent the same diskette problem from occurring. Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Wolfgang, when your harddrive as well as your floppies are virtual: does it make sense to cache them at all? The host operating system probably is already caching the relevant data. One cannot be sure the host system is caching data! You should test this, by running with UIDE (caching) and then again running with UIDEJR (no cache). If there is no speed change, your host likely is doing caching, and you may not need my drivers at all. Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Virtual floppy change problem with VirtualBox
Wolfgang and Ulrich, Hi Ulrich, thanks for the hint! I have commented out the line in autoexec.bat which loads the UIDE.SYS cdrom driver. Now there is no problem accessing the floppy images. This sounds to me as if VirtualBox is NOT posting the media change bits for a floppy-disk in the BIOS, when the floppy-disk is changed. Needless to say, UIDE requires those bits! Nor is UIDE designed to use any other way of detecting a floppy-disk change (if any such way exists), since the media change bits have been part of all PC BIOS programs from about 1985 onward. I suggest you Have another LONG chat! with the creators of Virtual Box, who seem to live in their own world and seem to IGNORE a lot of pre-existing PC hardware conventions Whenever it suits them!. Jack R. Ellis -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Long-term survival of FreeDOS
On Tue, 10 Apr 2012 22:16:50 -0700, Ralf A. Quint free...@gmx.net wrote: At 01:13 PM 4/10/2012, Jack wrote: Cannot answer on all subjects, but re: disk/CD/DVD drivers, I am NOT overly optimistic! Intel/Microsoft want us all to buy into AHCI, and they may have started ordering mainboard vendors to omit SATA/ IDE logic from their BIOS routines. Do you have a source for this statement? Sorry, but this completely contradicts the latest Ivy bridge chipset just released, which includes 6 SATA/eSATA ports... http://www.theregister.co.uk/2012/04/10/intel_7_series_chipsets/ http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/z75-z77-express-chipset-brief.pdf Ralf -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Long-term survival of FreeDOS
This topic is not about DOS vs other operating systems, or the fact that users tend to gradually abandon DOS. It's about the survivability of DOS vis-a-vis hardware ... What will happen with future development of the hardware architectures? Cannot answer on all subjects, but re: disk/CD/DVD drivers, I am NOT overly optimistic! Intel/Microsoft want us all to buy into AHCI, and they may have started ordering mainboard vendors to omit SATA/ IDE logic from their BIOS routines. If this becomes the de facto standard, UIDE and other DOS drivers will NOT be able to run! I am hoping mainboard vendors WILL see the need (despite such orders by the industry) to retain SATA/IDE compatibility modes. Otherwise, the long-avoided Bloody NIGHTMARE of adding AHCI in UIDE will have to be done, and quickly! Related questions are: how adaptable would the (Free)DOS codebase prove, in the event of this happening? How much manpower would be required to recode/adapt (Free)DOS to the new needs? In short, could DOS survive such a situation? Aside from the kernel and drivers, the DOS codebase should survive, as long as 80x86 commands can be executed. If support for them is dropped, NO amount of manpower will save DOS, since EVERYTHING will have to be rewritten in that event! -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New 23-Mar-2012 UIDE/UIDE2 -- Minor SIze Reduction.
Johnson Lam has posted a new DRIVERS.ZIP file, now dated 23-Mar-2012, on his website at: http://johnson.tmfc.net/dos/driver.html The UIDE and UIDE2 drivers now use only 912 bytes of upper- or DOS memory with their /H switch!To do this, UIDE now runs 30 BIOS units (was 34) same as UIDE2, and the logic in both to handle caching requests from other drivers has been revised to save space. See the UIDE.TXT file, for details about this. No change to the other drivers, and the update for UIDE and UIDE2 is only for convenience, not a bug fix. Thus far, no one has needed 30 BIOS units or has called my drivers to do user-driver caching (regrettably). So, this update for UIDE/UIDE2 should not affect anyone. Johnson's website may still display 7-Mar-2012 as its Last Update, but the files now available ARE dated 23-Mar-2012, and Johnson will correct this when he can (very busy!). -- 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] VERY Funny Off Topic --
VERY funny off topic, overheard today, which I just HAVE to share -- What does a U.S. Age-20s Slept Thru High-School type, too old to say The dog ate my homework!!, try to tell our apartment manager re: why he cannot help with his girlfriend's 3-week late rent?? The ATM ate my check!! A valuable lesson, as I know little of the U.S. language BratSpeak!! -- 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
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
Re: [Freedos-user] New 7-Mar-2012 UIDE, Etc. -- UIDE2 Under 7K!
Zbigniew, For your info, I tested the latest 7-Mar-UIDE2 with the latest V5.75 JEMMEX on my own V6.22 MS-DOS, on V7.10 MS-DOS, and on FreeDOS. The latter 2 tests were done using the systems from Lucho's 2008 boot diskette.Every system on that diskette runs with an old 4DOS, and the FreeDOS kernel Lucho used was 2035, the latest available back in 2008. I had absolutely NO problems on my system.JEMMEX was using I=B000-B7FF I=Test X=TEST, and it ran fine.My system has an old AMD3000+ (socket 754!), with a 5-year-old BIOSTAR main- board and 1-GB of RAM. Has run perfectly for 5 years. I must conclude that the problems you are seeing, using JEMMEX and UIDE2, are NOT caused by those drivers. 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
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
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
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
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
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
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
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
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
[Freedos-user] New 7-Mar-2012 UIDE, Etc. -- UIDE2 Under 7K!
Johnson Lam has posted a new 7-Mar-2012 DRIVERS.ZIP file with a much smaller UIDE2, on his website at: http://johnson.tmfc.net/dos/driver.html The UIDE2 driver, for faster speed with a protected mode system (JEMM386/JEMMEX etc.), is now less than 7K bytes in size! To achieve this, I needed to do two changes in UIDE2 -- (A) It will now run 30 BIOS disks/diskettes rather than 34, and (B) it will not handle the /N3 No XMS memory switch. Otherwise, UIDE2 is the same as before. Few PC systems have 30 BIOS units; most DOS systems allow drive letters A: to Z: and so can handle only 26 units! Also, Bernd Blaauw recently asked which driver, UIDE or UIDE2, he should use in his FreeDOS autoloader scripts. I answered UIDE, as it is more versatile, will handle up to a 4-GB cache, and will always have /N3 for FreeDOS support. So, the two new changes in UIDE2 should not affect anyone. Only slight changes to UIDE (assembled via the same source file as UIDE2) and no changes to XMGR/RDISK. UIDE2 should help boot diskettes users and others whose systems need to save file space. Also, I am again back to only a single UIDE.ASM source file -- My own XIDE driver (based upon UIDE2) is now GONE and all of its features have been folded into the new UIDE2! -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New 7-Mar-2012 UIDE, Etc. -- UIDE2 Under 7K!
I don't know, how for the others - but for me no UIDE* driver works together with JEMMEX 5.75 (it breaks immediately at the very start). Not sure, should it work with XMGR - it won't break, but mem /c/p reveals nothing with name UIDE* in memory. Can you be more specific about how the driver breaks?? Does it display its title message and controller/device data, or does it simply crash?? Let me know. Jack R. Ellis -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem after updating to FreeDOS 1.1 with writing of environment variables.
Mark, Yep, just tried Rdisk and it works as expected (when loaded from Autoexec.bat), I can assign a known drive letter and then not have to faff around trying to locate the ramdisk using findtdsk.exe. I don't think rdisk was around in 2003 when we set up our stuff originally, which I why we went tdsk route. I am the author of RDISK, also UIDE and XMGR. Glad you like RDISK, which I wrote in 2009 in response to Johnson Lam (my partner in my DOS activities), who noted HE did not like any of the available RAM disk drivers, either. So I did a simpler driver for him, and that is how RDISK came to be! Interestingly thou, Rdisk suffered the same problem, that tdsk had, in that we stored the ramdrive disk letter in an environment variable %RAMDRIVE% and our watcom app used a GetVar to retrieve it ... Not sure if this is a driver problem. If you wish, send me an E-Mail in private with more detail, and if RDISK can be improved, I shall do so. One last question, all these memory managers and such, is there a recommended set for a modern PC? I definitely recommend either JEMMEX (as you are using) or JEMM386 with a good XMS manager, either HIMEMX or my own XMGR. The other EMM drivers are all NOT under current maintenance, and many have never-fixed bugs!! Japheth works hard to keep his JEMM drivers current and bug-free, so they are the ones to use. JEMMEX alone should work fine for most people. If you don't need any protected-mode features nor any extra upper-memory (B000h to B7FFh, i.e. the old monochrome video area) that must be mapped by an EMM driver, you can first run UMBPCI, then load my own XMGR. XMGR can read the UMBPCI memory blocks and load itself directly into upper-memory. XMGR also has I-O Catcher logic to catch and execute diskette I-O (also hard disk I-O until UIDE loads) in upper-memory, since UMBPCI's Shadow RAM upper memory will not do any DMA! Serious game fanatics prefer UMBPCI/XMGR, as they are slightly faster from not using protected-mode, and many DOS games are written for real-mode speed. Except for JEMMEX by itself, or UMBPCI + XMGR, other memory-manager drivers are usually unneeded. At the moment, my fdconfig.sys looks like: DEVICE=A:\JEMMEX.EXE SHELL=A:\COMMAND.COM A:\ /E:512 /P DOS=HIGH,UMB DOSDATA=UMB FILES=20 BUFFERS=20 LASTDRIVE=Z DEVICEHIGH=A:\UIDE.SYS /S40 /D:CDROM1 and the start of my Autoexec.bat looks like: LH A:\RDISK.COM /S50 /:Y A:\FREEDOS\SHSUCDX /QQ /D:CDROM1,Z Any pointers or help optimizing it further would be appreciated. Looks good to me! My only comment is that if you always use the FreeDOS system, you may want to delay loading UIDE until AUTOEXEC runs, in which case you will have to load UIDE with -- DEVLOAD /H A:\UIDE.SYS /S40 /D:CDROM1 /H DEVLOAD, maintained by Eric Auer, can load .SYS drivers during the AUTOEXEC.BAT file (normally, they load during CONFIG.SYS). In my example line, the first /H tells DEVLOAD to load UIDE high, i.e. in upper-memory, and the second /H tells UIDE to use free HMA space for most of its driver logic. That will save you about 4300 bytes of upper-memory. FreeDOS does not make HMA available for drivers until AUTOEXEC runs, thus the reason for delaying UIDE's loading. You may also want to give UIDE more than just 40-MB of XMS for its cache. The rule I recommend, where possible, is to allocate 3 times the size of your largest cached file, i.e. if your system may have to handle up to 100-MB files, then a 300-MB cache works fine: 100-MB to cache the input file, 100-MB to cache its output copy during file copies, and 100-MB for directories or other files to be SAVED while a big file-copy is going on! If 300-MB is too much or if your largest file is used only occasionally, make the cache 3 times the size of your largest most used file. This scheme will avoid UIDE having to discard directories, to make space for a large new file in its cache, which slows it down a bit when those disk directories ultimately need to be re-read! Finally, unless your WATCOM application requires them, you may want to use BUFFERS=4, or at most BUFFERS=10, in your CONFIG.SYS file. WIth UIDE present, there is no further need for a large number of DOS buffers. UIDE does a much better caching job than the old DOS buffers, and by reducing your buffer count, you may save enough HMA space to put UIDE up there in the HMA, as well! Best wishes, Jack R. Ellis -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Problem after updating to FreeDOS 1.1 with writing of environment variables.
Mark, Thanks, after using all the excellent advice so far, I am **ALMOST** back up and running, the environment variable problem has been worked around, and I have taken onboard the memory saving advice (have about 470k of conventional memory, which should be ample, how much did billyboy say we wouln't need anything more than?). Problem is, now the ghost process is crashing with a read error from the DVD, which I know don't contain any errors. Could this be related to me using UIDE.SYS rather than our previous driver (oakcdrom.sys)? Is there anything I should be aware of? Or any way to help diagnose the error? My config and autoexec now look like: Config: DEVICE=A:\JEMMEX.EXE SHELL=A:\COMMAND.COM A:\ /E:512 /P DOS=HIGH,UMB DOSDATA=UMB FILES=20 BUFFERS=4 LASTDRIVE=Z Autoexec: DEVLOAD /H A:\UIDE.SYS /S511 /D:CDROM1 /H LH A:\RDISK.COM /S10 /:Y A:\FREEDOS\SHSUCDX /QQ /D:CDROM1,Z I agree with Bernd Blaauw's comments today, that perhaps a basic UIDE will help you resolve your Ghost problems. In general, you may want to go back to your original CONFIG/AUTOEXEC files, then put in all of our advice one line at a time. This may help to positively find the problem. I have never worked with Ghost, but if it is an old DOS program, it may be dependent on exactly WHICH areas of XMS memory are in-use and so available for it. There are two more UIDE switches you can test, to see if this is so: /R15 and /R63.They reserve 15-MB and 63-MB of XMS memory.This will make UIDE load itself after the first 16-MB or 64-MB of memory (the first 1+ MB is the DOS system plus its HMA space). Certain Sound Blaster cards did only 24-bit DMA and so cannot use any memory beyond 16-MB. Certain other game programs were NEVER updated to the V3.0 XMS Specification (up to 4-GB of memory) and still use only V2.0 XMS logic (64-MB maximum). So, UIDE's /R15 and /R63 switches are intended to accomodate such ancient hardware/software! If a line-by-line re-update of your CONFIG.SYS and AUTOEXEC.BAT fails to determine the Ghost problem, do try UIDE with /R15 and /R63 as the last resort. Worth a try! Also, I do not completely agree with Bernd about problems caused by the use of UMBs (upper-memory blocks). There are a few drivers not able to detect various parts of upper-memory: JEMM386/JEMMEX still do the old Microsoft tests for compatibility (newer odd peripherals memory sometimes confuses them), and a few of the newer chipsets might not-yet be supported by UMBPCI. But, once detected and put into use through JEMM386/JEMMEX/UMBPCI, upper memory should NOT be your problem. I have a small update on my original email (I haven't had a chance to try the items below). When I run Ghost, the CD drive is listed twice, once via it's drive letter and once via it's ATAPI direct access. Access via drive letter fails repeatably. Access directly works. I don't know if that sheds any light on things. This late E-Mail MAY be telling me there is a driver CONFLICT between UIDE and whatever Ghost I-O logic may be present. If so, you should try UIDE with its /N2 switch, which asks UIDE not to run CD/DVD drives. If this eliminates your Ghost problem, then (A) you need to disable the Ghost I-O logic and run your CD/DVD drives only through UIDE, or (B) vice-versa, i.e. you must load UIDE with /N2 to avoid your Ghost errors. NOT any fun, either way, I know! But, I have never used Ghost and do not know what its writers do in running CD/DVD drives! Best wishes, Jack R. Ellis -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New UIDE Available -- 64K Boundaries Fixed.
Johnson Lam has posted a new DRIVERS.ZIP dated 24-Feb-2012 on his website at http://johnson.tmfc.net/dos/drivers.html. In it, UIDE and UIDE2 are corrected so that they again handle 64K UltraDMA boundaries properly. A user I-O buffer which crosses-over a 64K address boundary will cause the drivers to move output data to, or input data from, their own XMS buffer which is aligned with NO boundary and will handle actual I-O. Like I wrote before on this forum, note that I suspect this problem may affect only old year-2000 and earlier chipsets, since the previous UIDE/UIDE2 have not given any big number of data errors for users! But I want the UIDE drivers to be compatible with ALL UltraDMA controllers, so they are fixed! Also, UIDE/UIDEJR are a bit smaller and UIDE2 is MUCH smaller due to my experiments in writing a 7K-byte version of UIDE2 for my backup/restore diskettes. My run-time driver logic is good, but my driver initialization logic is often quick and dirty since it disappears after the driver loads! That has now been remedied, very much so in UIDE2! A minor error -- I date stamped XMGR/UIDEJR in the files on Johnson's website to 2-24-2011, not 2012!A typing error by me, which Johnson shall correct. XMGR/UIDEJR do show the year 2012 in their title messages, and they do work fine! -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New UIDE -- Website Correction!
In my previous post about the new 24-Feb-2012 UIDE/UIDE2 drivers, I mistyped Johnson Lam's URL with an extra s! The correct URL for the new drivers is -- http://johnson.tmfc.net/dos/driver.html My apologies -- Age 66 is SO much fun! as I often say! -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] UIDE Update Coming -- DISGUSTING Implications!!
A Heads Up (warning) message to all users of UIDE and UIDE2 -- Some time ago, I considered Read-Ahead for UIDE/UIDE2. But effective Read-Ahead requires knowing file sizes, to prevent reading too FAR ahead and losing time! File sizes demand DOS calls, and I want UIDE/UIDE2 to remain generic (no DOS calls) and continue to use only Int 13h. In any case, I did revise the drivers' UdmaIO/DoDMA routines, to put more setup logic in DoDMA so it could be an internal driver for Read Ahead. This created a bug! For disks, the SetAdr subroutine that detects 64K UltraDMA boundary crossings is now being called BEFORE the IOLen byte count is set for requests! SetAdr must know that count! CD/DVD requests, and the non-caching UIDEJR driver, were not affected. Easy to fix, simply re-arrange UIDE/UIDE2's logic to what it was before. However, what this bug IMPLIES has left me rather DISGUSTED! I shall NOT believe that all DOS kernels/programs do disk I-O using only perfectly-aligned buffers with no 64K UltraDMA boundaries! Many such kernels/programs were written BEFORE 1994, when UltraDMA was thought-up! So, the only way recent UIDE/UIDE2 drivers could run O.K., without users seeing a LOT of data errors, is that 64K UltraDMA boundaries NO-LONGER EXIST! Newer DMA controller chips likely increment all 32 address bits after DMA byte/word transfers, not just the LOWER 16 bits as in the 1994 Intel Bus-Master Specs. That was what created such 64K boundaries! And NOBODY in Santa Clara, California nor in Redmond, Washington told ME one word about all this, that UIDE need no-longer worry about UltraDMA boundaries! This despite comments about UIDE showing up all the time on MSN and others of their forums! So, pardon me, if I am really left DISMAYED and DISGUSTED by the current computer industry, that PROVES all-the-time how they only want DOS and efforts like ours to just go away! Small wonder, that my computer is unchanged past 2006, and my software is unchanged past 1994 V6.22 MS-DOS and 1998 V4.0 Windows/NT.I too can play their little go away game, or as my late Mother might have said, So SCREW them!!! I have the bug fixed in my personal drivers, and I shall soon issue an updated DRIVERS.ZIP file through Johnson Lam's website, when he recovers from another type of bug called the FLU! -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] USB/ASPI to DOS, 4K sectors.
Jack has his own private reasons for not being a fan of ASPI, thus his UIDE driver (PCI IDE/SATA storage and optical disk driver) doesn't implement nor hook into ASPI. I'm not aware of opensource CD-writing software that doesn't require ASPI. Not entirely true -- UIDE can call Int 13h drivers for all types of hard-disks, and upon return from their drivers, UIDE will cache their read/write data, as well. If a SCSI disk has such a software driver or even a BIOS chip on its interface card that handles Int 13h calls, UIDE will cache such disks. What UIDE will NOT permit is handling any BIOS units flagged as being removeable!! One CANNOT be certain all DOS variants will handle a media change (new disk) within their Int 13h coding, which was done at a time when Int 13h hard-disks really were HARD! As I will NOT have UIDE get blamed for an older DOS system failing to flush its disk buffers on media-changes, UIDE will NOT handle removeable hard disk drives! That includes USB types! My private reasons for not liking ASPI are many -- 1) ASPI is too complex. Whatever happened to a SIMPLE interface that provides read/write and perhaps format commands only?? All other functions are rarely used by disks and should be diagnostic-only. 2) ASPI is mainly for SCSI drives, which are expensive, same as their $200+ controller cards. You get IDE for nothing, last I heard. 3) In 1998, I came back to California to take a job at Adaptec, after 4 years in Utah, only to find that the man who would have been my boss hadn't cleared my paperwork before offering me the job, i.e. I had NO job!! Absolutely UNETHICAL, and INEXCUSABLE, and I have had nothing to say for that man, nor for Adaptec, from then on! If the idea of doing drivers for USB is still open, why NOT write a simple Int 13h driver that handles disk reads/writes only, instead of obeying the full SCSI/ASPI set of rules simply because they ARE the so-called rules?? In 1980, an associate of mine took one look at a 750K video package [done in C of course!], and he noted They've got GUTS calling THAT a 'driver'!! I have precisely the same feelings about a lot of the software for using USB, thus far. Something simpler/Better/SMALLER for USB disks and CDs/DVDs really is NECESSARY, people! Until we get it, I plan to avoid all USB devices like the PLAGUE! -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
I knew this would provoke a comment from you, Jack. Yes, you always were a provoker, weren't you, Bret? The purpose of a cache is to put as much data in RAM as it can, so that the disk is accessed as little as possible. It's true that the cached data does eventually get written to disk, and that part is slow. From a speed perspective, though, a well-designed cache can be competitive with a RAM disk. Exactly why I designed UIDE to have all the features I noted before, along with using only 944 bytes of memory (and some HMA which nothing but MS-DOS HIMEM ever used before) and using XMS for its cache tables and cache data. Try to find any Write Back caches that do so much, for so little memory! The advantage of a write-delay cache is that that the writing can be done when the system is idle (a simple form of multi-tasking). The end result is that even though disk writes actually take the same amount of time they always did, the SYSTEM actually runs much faster. In my experience and opinion (and it is only an opinion), write-through caches don't provide enough speed benefit to be very helpful, and I don't use them. Well, we remain on different sides of a fence! I say Write Through caches provide a LOT of benefit, especially UIDE which can cache up to 4-GB of data! Assuming only 2.5 or 3-GB is assigned to UIDE, one can have 500-MB+ for a nice RAM disk like my RDISK offers, and so one gets The best of both worlds: A (big!) RAM disk for fast files, plus a (big!) cache for ordinary disk files. UIDE/RDISK handle GIGABYTES, not KB or MB like too many other never-upgraded RAM disk and Write- Back cache programs! You can KEEP all those old guys, and I shall continue to do the BEST possible in UIDE/RDISK, for a LOT less memory! There is a REASON why Write Back caches are all so large -- they demand MANY hooks of a non-generic type into a DOS system ... Yes, write-delay caches are MUCH more complicated than write-through caches. But, they also provide MUCH more practical benefit, IMO ... How I just DETEST Internet abbreviations, which are always such LAZY and/or BAD English! But FYB, IMO it is rather IMPRACTICAL to use so much system memory in SMARTDRV/NCACHE2/etc. DOS is in fact memory limited, and if I can have 90% the benefit of most Write Back caches for 90% LESS memory by using UIDE, THAT seems a little more PRACTICAL! Even with that being said, I don't use SMARTDRV all the time. I only use it in certain situations when it provides noticeable benefit, and in those particular situations a write-through cache doesn't help. Why not just use UIDE all the time? You would get UltraDMA I-O rather than whatever your BIOS currently does, and I bet your NET system speed would be greater, from having SOME type of cache active at all times! Also, FWIW, you can disable write-delay caching in SMARTDRV if you want, in which case it works sort of like UIDE or LBACACHE (except that it will also _natively_ work with non-INT 13h disks like USB and SCSI), but at the expense of requiring more memory. SCSI disks are rarely seen on PCs, due to their high disk and controller cost. USB disks are also rarely seen, since they are not-yet reliable, nor in many cases are they fast-enough to replace hard disks. SATA/IDE own the hard-disk market and probably will for a LONG time. So, I am not-at-all bothered by UIDE handling only Int 13h disks, especially as it still CAN be called by other drivers to cache THEIR disks, as well! -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
Re: 4K sector sizes, I realized today that UIDE, UIDE2, and UIDEJR likely will NOT be affected at all -- 1) DOS has a 64K-byte limit for read/write requests, in fact 127 sectors of 512 bytes (the UIDE drivers do accept 128). Since 4K-byte sectors fit into this limit, no physical-level driver changes are needed. 2) All 3 UIDE drivers do ONLY physical block I-O and know nothing about directories, file systems, etc. The drivers remain DOS independent, i.e. they just read/write sectors at the orders of the DOS system and user programs. MUCH simpler and a LOT smaller! 3) UIDE/UIDE2 require, and UIDEJR can set, a 64K buffer in XMS memory for misaligned or other I-O unsuited to UltraDMA. Since DOS cannot do more than 64K I-O at a time, no change to the UIDE drivers' UltraDMA buffering is needed. 4) UIDE/UIDE2 set cache blocks of varying sizes, 8K for a 5-MB cache, up thru 64K for an 80-MB+ cache. So, the drivers have enough cache blocks in all cases to be effective, in handling both directory sectors and data files. 4K disk sectors fit evenly, into any UIDE/UIDE2 cache-block size same as 512-byte sectors do. So UIDE/UIDE2 will need NO changes for caching the larger disk sectors! About all that MAY be needed in the 3 UIDE drivers is some init logic to select using 4K-byte sectors, if a hard-disk demands this (FOOLISH if so, in my opinion!). Assuming boot or FDISK/FORMAT problems are dealt with as required, my comment about 4K-byte sectors is Bring 'em on! The 3 UIDE drivers will run fine with them and so regular DOS I-O should not be any problem! [In the U.S.A., we have an old engineering joke known as the K.I.S.S. Principle, whose letters denote Keep it SIMPLE, stupid!. Less and less of a JOKE, as time goes by and computers become unjustifiably COMPLEX! I and the UIDE drivers still OBEY the KISS Principle, insofar as is possible!]. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
To set the record straight on caches and on UIDE -- Can you recommend any free int 13 or block device based delayed/ pooled write caching software? As far as I can remember, all modern (LBA compatible, given disk sizes on current PCs) implementations of this are commercial. I don't know of any, but there's definitely a need for one. I normally don't use caches at all, but when I need one it needs to be a write-delay cache and I use MS SMARTDRV. I actually don't like SMARTDRV very much (it uses too much memory and requires a reboot to uninstall), but I have it and it works OK. I agree with the above -- Write Back (delayed-write) caches usually are commercial, as they require a LOT of work and must be sold for a price. And I too absolutely HATED SMARTDRV -- Takes the most memory but caches the LEAST amount of data for it! I used Norton NCACHE2 for years, which is also a memory hog, but not as bad for the amount of data it handles. I don't find write-through caches like LBACACHE and UIDE to provide enough speed benefit to be very helpful (though they might increase disk life to some degree). In addition, LBACACHE and UIDE are INT 13h caches instead of INT 21h caches (like SMARTDRV is), so they don't work with all disks (including USB and SCSI). When I really need to increase disk access speed (a big problem in some VM's), I copy my commonly-used utilities and batch files to a RAM disk. No cache will ever compete with a RAM disk. RAM is always faster than disks with their seek/rotational latencies and their much slower transfer rates. But I dispute your comment about Write Through caches offering not-enough speed benefit, and I bet all VERY happy! users of UIDE might argue with you, as well. There is a REASON why Write Back caches are all so large -- they demand MANY hooks of a non-generic type into a DOS system, to handle Ctrl/Alt/ DEL and other events that require a flush of sectors not-yet written to disk. UIDE only needs to hook the Int 13h vector to do its functions. Also, UIDE is not just an Int 13h cache -- It CAN still be called by user drivers which desire its caching, though I am sadly aware that no one has ever done this. DOS driver development, or enhancement, isn't done that much any more. I did everything possible to make UIDE a FAST Write Through cache. It integrates caching with UltraDMA I-O for disks/CDs/DVDs; it can do direct UltraDMA to/from cache buffers to save time; it uses a binary-search when looking for cached data blocks (NOT hashing, which breaks-DOWN in speed at about a 35%-40% full search table); and it is only 5.2K (UIDE) or 4.5K (UIDE2) of assembly-language, as I REFUSE to have God-forsaken C in any SYSTEM driver as important as UIDE is!! But, if you wish to continue giving-up 40K+ for SMARTDRV, 80K+ for Norton NCACHE2 or however-many K for other Write Back schemes, feel free to do just that! I and others will continue using the 944-byte UIDE/UIDE2 and will be VERY happy! with the speed increase we DO get, from doing so! [And if there are still those who do not understand how UIDE/UIDE2 manage to require only 944 bytes of upper/DOS memory, just call it Sorcery!!]. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re : Support for 4k byte sectors
For what it is worth, my take on 4K-byte (or other-than-512 byte) sectors for DOS systems is very-much the same as Eric's and I shall reply to some comments from one of his posts -- Also depending on your BIOS, you could have a limit of at most 2^28, 2^32 or 2^48 sectors per disk ... Not a problem for a driver, as drivers usually assume the programs doing I-O will not try to access PAST the end of a disk! The disk directory controls how much data shall get read/written, and the disk driver takes its orders from a DOS system. Absolute disk size is only a problem when specific HARDWARE commands are needed with different sizes. In the SATA/IDE world, there is only 28-bit or 48-bit LBA addressing, and a 48-bit drive can accept 28-bit commands. Thus, in my UIDE driver, I issue 28-bit commands for up to 28-bit addresses, while I issue 48-bitters for larger addresses. Runs fine! ... There also is a DOS UIDE cache-and-driver. For example LBACACHE is one of the tools which assumes 512 bytes/sector and uses only the first 2^32 sectors which is 2 TB for 512 bytes/sector. As noted above, UIDE (also UIDE2 and UIDEJR) handles 48-bit LBA addressing, if any DOS system were ever to give it an Int 13h AH=42h/43h LBA block with addresses so large. I depend on the DOS system to determine if this is necessary, as UIDE does physical I-O only, not logical directory I-O where the 32-bit directory limit is of concern.Only the 48-bit LBA address limit matters to me and my drivers. By the way - a DRIVER could interface with any disk with any sector size and then just provide an int13 or int25/26 interface with 512 byte sector size for data transfer to DOS. For transfers which do not access (aligned) blocks of 4 kB size, performance will be worse than native, and you cannot boot from such a disk, but at least this would WORK and you could even have a driver as part of the boot chain before DOS is loaded, just as Ontrack / Ezdrive MBR-loaded drivers which added LBA support to PCs without a LBA BIOS, decades ago. Making the KERNEL sector size of DOS 4 kB has the side effect of BUFFERS also being 4 kB each - wasting 3.5 kB in each buffer when you access a 512 byte / sector disk with such a kernel. I agree with much of the above. Changing DOS, and all user apps, for any new sector size at THIS late date would be a Cast-Iron BITCH, in my opinion! [U.S. expression for BAD wives/girlfriends, who are usually made of softer items!]. For the moment, UIDE supports only 512-byte sectors, same as LBACACHE and almost every other DOS hard-disk driver. But, if new 4K-byte sector schemes provide a RELIABLE means for a drive to tell its driver what sector size is in use, I can change UIDE to detect that size! Not-much help for booting or with independent programs like FDISK, etc.But, Eric is correct: Changing only the DOS disk driver to accomodate large sector sizes, then letting the driver interface with the existing DOS system at 512 bytes/sector, would be a HUGE simplification of this entire issue! -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] UIDE.SYS delays boot process in VirtualBox
Anybody has an idea how to solve this with free software? Would the eltorito.sys driver help? Wasn't the solution to enable IO APIC or something like that? So a different enabled chipset. ELTORITO.SYS can help, but only if you configure the VM to start with booting from CD, after which you boot from harddisk. I have never used El Torito as I have no CD boot disks (only diskettes) on my system, so I have no idea if El Torito helps or not. Loading UIDE at runtime instead of boottime is also possible, in some theoretical CDROM.BAT for example ... Doubtful this would help at all, since UIDE is going to do exactly the same checks of the PCI bus for CD/DVD drives, whenever it gets loaded. Alternatives are creating and using an ISO file: OMI.EXE D: C:\FDBOOTCD.ISO Or replacing the CD-driver by the closed-source generic OAKCDROM.SYS or VIDE-CDD.SYS drivers [http://www.opus.co.tt/dave/indexall.htm]. I do NOT recommend any of the older generic drivers, since none of them have UltraDMA logic, and none use file/directory caching. Omitting both of these items will cause CD/DVD transfers to run 3 or 4 times slower! Also, a generic driver normally uses only Legacy IDE device addresses and cannot see a controller whose addresses might be assigned by PCI to other values. This is true for VIDE-CDD, OAKCDROM, my old XCDROM, and about all other generic CD/DVD drivers. Note also that GCDROM/XGCDROM (BAD hacks of XCDROM!) claim to support other addresses, but in fact they have PROBLEMS! Jack's UIDE.SYS driver performs chipset initialisation which is apparently still implemented in a buggy way in the VirtualBox software. No other way possible for UIDE! CD/DVD drives are not part of the BIOS, so UIDE must detect them by (A) finding all SATA/IDE controllers on the PCI bus, then (B) examining each controller's device slots for ATAPI CD drives. If some of the VirtualBox chipset options exhibit LONG delays when UIDE issues an Identify ATAPI Device command, VirtualBox needs to get FIXED! -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Memory
1. Would like to ask how much memory does FreeDOS support, e.g. 4 GiB? Yes you'll be limited to a maximum of 4GB if you have 4GB or more. In practice this maximum could be anywhere between 2GB and 4GB (usually 3.3GB or 3.5GB) due to PCI chipset device mapping into the top of memory. On older or uncomplicated mainboards, PCI should not take that many addresses. And yes, no one ever vioced any serious interest about more than 4-GB of memory, so Japheth and I never pursued it in HIMEMX or XMGR. Can be done, but it requires strong agreement on all the conventions used for the two drivers to access over 4-GB of XMS. 2. Does it faces 640 KiB limitation as MS-DOS, e.g. Do I have to load high drivers to save on conventional memory? yes. To access beyond 640KB load a driver (XMGR, HIMEMX, whatever) to access extended memory (XMS). In fact, one needs an XMS driver (XMGR, HIMEMX, MS-DOS HIMEM, etc.) and an upper-memory provider driver (JEMM386, MS-DOS EMM386, etc.). The combined JEMMEX can also be used. If one uses only real mode, the UMBPCI driver can enable Shadow RAM (BIOS usage) as upper-memory, and XMGR can then provide that memory to DOS. No need for EMM drivers in that case, but note that UMBPCI may not run with all newer chipsets. The main point is that an XMS driver by-itself does NOT provide upper memory to the DOS system. This is done by the EMM driver, or by the specific UMBPCI/XMGR combination. [If XMGR does not find Shadow RAM enabled by UMBPCI, it works the same as HIMEMX/HIMEM and waits for an EMM driver to enable conventional upper-memory]. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS boot problem
Wayne, I just installed FreeDOS on a newly created FAT32 partition on my SATA HD. The other partitions are in NTFS and running Windows/XP. Since FreeDOS doesn't see XP it didn't edit my boot.ini. I have been trying to code it myself with such things as: C:\FDOSBOOT.BIN=FreeDOS D:\FDOSBOOT.BIN=FreeDOS X:\FDOSBOOT.BIN=FreeDOS multi(0)disk(0)rdisk(0)partition(1)\FDOSBOOT.BIN=FreeDOS multi(0)disk(0)rdisk(0)partition(2)\FDOSBOOT.BIN=FreeDOS multi(0)disk(0)rdisk(0)partition(3)\FDOSBOOT.BIN=FreeDOS without any luck ... I also tried to use partition logic to rewrite my MBR, but since it is a SATA drive, it is not supported. Can anyone help either with code for boot.ini or with a tool that will rewrite my mbr??? PLZ? I am the author of the UIDE driver, which is now part of the FreeDOS base software list (Thanks again, Jim Hall!). I still use an old V4.0 Windows/NT (1996) -- Saves me $250 every 6 months, and prevents having to put-up with Gates Co.'s latest collection of new bugs! Win/NT loads itself using a multi(0)... statement in BOOT.INI with a similar format as you show above. Win/NT does this using its own boot sector, that becomes the master boot sector for all hard-disk boots (power-up, pushbutton reboot, etc.). As Win/NT installs, it discovers that MS-DOS (mine is still V6.22 from 1991!) was also present, so it copies the original DOS boot sector to a file named BOOTSECT.DOS, which is the sector it loads when you select a line in BOOT.INI that begins with C:\ (i.e. you want to boot from DOS). I have never used any later version of Windows, and so I do not know if they allow MULTIPLE lines in BOOT.INI that do not begin with some multi(0)... data, i.e. multiple choices for booting DOS systems. If they do, Fine and Dandy! If not, you may be STUCK with only a single C:\=FreeDOS statement in your BOOT.INI file! You need to examine your Win/XP system to see if it does include a BOOTSECT.DOS file. To do this, you might need to reinstall MS-DOS, then install Win/XP after that, since my nose is telling me Win/XP may NOT create BOOTSECT.DOS if it finds no MS-DOS (and not FreeDOS!) as it installs! Gates Co. are famous for such unfriendly items in their software! If you have no MS-DOS, try to find Wengier Wu's V7.10 MS-DOS boot diskette files, on the Internet -- Many users in China, and I, use Wengier's files, and they run O.K. If installing some variant of MS-DOS, followed by your Win/XP, does NOT give you a BOOTSECT.DOS file, Gates Co. have gone over to some other scheme than what I have in Win/NT, and I cannot be of help you! If Win/XP does in fact create a BOOTSECT.DOS when it finds a legit copy of MS-DOS loaded first, you then need to copy the FreeDOS boot sector (512 bytes only!) into BOOTSECT.DOS for Win/XP's boot use. I use an old Norton DISKEDIT to extract the DOS boot sector -- You may need some other scheme to write the DOS boot sector to a file, then copy it over to BOOTSECT.DOS as above. I would be EXTREMELY cautious about loading Win/XP first, and then cold loading FreeDOS on top of it! This may make FreeDOS overlay the actual Win/XP boot sector -- NOT what you want! But it seems the REVERSE, installing FreeDOS followed by Win/XP, might cause THEM to overlay the FreeDOS boot sector with THEIR own! So you need to have a saved copy of the FreeDOS boot sector, install Win/XP, and then overwrite their BOOTSECT.DOS (if present!) with the saved FreeDOS boot! Complex, but it Works for me!, and has for 15 years! Gates Co. may not have designed a general purpose multi-boot for Windows/NT, but with some knowledge and research, any DOS can be made to work! I hope this helps you! Jack R. Ellis -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos4Kids (and Kids-at-heart)
On the topic of wear leveling I would go with the DOM products, as they are designed as hard drive replacements. It's pretty easy to burn up FLASH so wear leveling is important. FWIW, they claim that FLASH has unlimited read capability, but is limited in the number of writes. So, at least theoretically, wear-leveling should only come into play when writing to disk. To extend the life of the system, you should try to do as much as you can in RAM (like using RAM disks for temporary files, etc.) and minimize writes as much as possible. This is true for regular hard drives as well. Absolutely UNBELIEVABLE to me that FLASH devices are used AT ALL in hard-disk replacements!! Last I knew, FLASH devices are writeable only about 10,000 times. That is a LOW number of writes for disks if one considers DIRECTORY updates that any DOS system will do VERY often!! Even using an old Write Back (delayed-write) cache like SMARTDRV, or Norton NCACHE2, I doubt that writes could be minimized enough to make limited-life FLASH device disks worth their cost!! If the DOM products have normal RAM chips (not FLASH types) and are as compatible with IDE controllers as everyone seems to say, then my next hard disk purchase shall be another actual HARD disk or a DOM module if necessary, NOT any sort of FLASH type! Allows me to stay with UIDE, which may not use delayed-writes but takes only 944 bytes of upper/DOS memory [plus a bit of invisible HMA] and gives me up to 4-GB caches! Try to get even 1-GB using any Write Back cache, and I have 5 words for you: Good LUCK -- You'll NEED IT!! -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos4Kids (and Kids-at-heart)
Mike, Most modern flash devices have cells that are writable at least 10 times that - 100,000 cycles is the minimum you will find. Better devices have even higher cycle counts. Glad to hear, but I would still prefer a hard-disk whose lifetime is measured in years, not in cycles. DOM products have FLASH in them - Nobody said anything about DRAM. If they had DRAM they would have to be continuously powered. Sad how a simple battery is not included in such devices, so maybe low-power DRAM could be used for faster writes and longer lifetimes. Products like Disk on Module that are designed as hard drive replacements usually have better wear leveling capability than standard USB thumb drives, as the directory meta data update issue is well known. SSDs take this to another level by over provisioning which means including more capacity than is advertised so that they will have enough spare capacity to make it to their rated lifetime. I have never used any sort of solid state memory devices to replace a hard disk, so the whole thought of wear leveling is a bit foreign to me. With hard disks, one just uses them, with no need or worry about such techniques, for their 3- or 5-year lifetime.Maybe hard disks could last better, using a cache or other access minimization schemes -- But knowing how manufacturers make such disks last EXACTLY their warranty period, I really doubt it! For applications where fast access is required nothing can beat a FLASH based device. Part of the equation there involves unit life; if you use a FLASH based device in an environment with lots of writes then you expect to be replacing it on an accelerated schedule. The write and read throughput is far above what a conventional spinning disk can provide, although the capacities are far smaller. Shall stay with hard disks, then. On my home desktop system, I am NOT concerned about absolute speed (not with UIDE, anyway!) nor power consumption, but I AM still concerned over all noted in this thread re: FLASH-disk cycle limits! For me, and I expect a LOT of others like me, a garden variety $40 hard disk should do just fine WITHOUT any such concerns! Jack R. Ellis -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDos4Kids (and Kids-at-heart)
Andrew, I anticipate replacing the dying and clunky old hard-drives for SD cards on a 44-pin IDE adapter for better performance and improved efficiency. I imagine that the recent improvements with FreeDOS' EIDE would facilitate a hardware upgrade like that - am I understanding that correctly, please? I am the author of the UIDE disk/CD/DVD caching driver, and I assume your reference to EIDE is in fact addressing the UIDE driver. I have not tested UIDE with SSD disks, nor has anyone commented on such testing. FreeDOS users are often Charlie Poor-Boys with not enough extra money for such luxury equipment. The best I can say is that you should test UIDE on your systems using SSD disks. If they respond the same as normal hard-disks, including all PCI init functions, UIDE should pick them up and run them O.K. If not, only a minor loss, as SSD disks are so fast that they really should not need caching. You can then run UIDE with its /N1 switch which causes it to ignore hard-disks but continue to cache diskettes and CD/DVD drives. They need caching, for they are otherwise SLOW! Jack R. Ellis -- RSA#174; Conference 2012 Save $700 by Nov 18 Register now#33; http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] 4th-Grade English.
Mark, The way this post has degenerated I think demonstrates exactly what the original poster was trying to say ... Logic and analysis should be able to be demonstrated regardless of the language abilities of the poster. My error, to have titled this thread 4th-Grade English, which did get peoples' attention, but in the wrong way. THANK YOU for your insight, in the same sense as Captain Armstrong [in your 1980s Anzacs series], who initially addressed his all-volunteer platoon by saying, You shall be treated as intelligent adults! Jack R. Ellis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] 4th-Grade English.
It is VERY TIRESOME, having to respond to posts on this board with I DID NOT say ... or I DO NOT agree ..., when one's REAL words are either misunderstood or often TWISTED for some other agenda! Many such replies would cause their writers to FAIL, QUICKLY, in almost all U.S. High-School Debate classes, from NOT speaking to the POINT of whatever the original post was! Is it REALLY true, that (A) using 4th-grade English [age 9 level], (B) proof-reading SEVERAL times before making posts, and (C) doing all possible to be CLEAR, are now NOT-ENOUGH on boards like this?? Or does the U.S. Slept Thru High-School DISEASE [as so many here took GREAT SPORT in achieving!] now afflict not just OUR last 2 or 3 whole generations of total idiots, but EVERYBODY world-wide?? COME ON, People!! DO NOT twist posts to suit your OWN agendas! PAY ATTENTION to the POINT of what people try to post, both here and elsewhere!! And DO realize you just might have to WAKE UP! from such teenage slumber, and USE YOUR BRAINS, now-and-then, to UNDERSTAND what is obviously technical data, not just Tee-Hee! babbling from Slept Thru BRATS!! Sorry, but THERE IT IS!!, as the British might say! -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
about a force-on A20 method. Glad to hear that, since your own FreeDOS is already DOING so! It is not, but probably it should ... Baloney! [polite B word], as I just noted above! XMGR doesn't handle the usually-ignored BIOS calls ... Why do I say such calls are usually ignored? Because XMGR has NEVER supported them, and no one has ever complained That simply means that all modern systems support port 92 and or keyboard controller style A20. It does not mean that BIOS calls for switching A20 would be broken in BIOS. I never said or implied the BIOS calls WERE at-all broken! I simply said that it appears nobody USES them, for the same reason you note: Keyboard or Port 92h logic works fine. Proves your point that using the BIOS to manipulate A20 is not necessary, nobody has yet reported non-BIOS to cause problems. Agreed, and I can save adding all that logic into XMGR! Hallelujah!, and Saints be Praised! [take your pick]! The kernel already IS doing part of the work! Try ALL of the options on Lucho's boot diskette! You will find that only MS-DOS and PC-DOS are not hard-enabling A20, when they load. DR-DOS, the Russian PTS-DOS, ROM-DOS, and FreeDOS all DO hard- enable A20. The FreeDOS kernel contains no 8042, port 92 or int 15.24 style A20 manipulation code (or it would be very well hidden) so the only A20 work of the kernel are calls to XMS driver functions number 5 and 6. Maybe an obscure side-effect of something else distorts your measurement? The boot menu used by Lucho might enable A20 but the MS / PC DOS kernel then disabled it again? REALLY doubtful, since when I do NOT use Lucho's boot diskette I get the SAME results! I suggest you need to investigate your very well hidden comment, above! I still cannot find *how* the FreeDOS kernel would enable A20 before XMS drivers are loaded ... If I had to guess, I suggest you investigate whatever logic burns up all HMA space for DOS buffers. FreeDOS HMA is not available for drivers like my UIDE until after AUTOEXEC is run! That is why I tell FreeDOS users to run your DEVLOAD [in AUTOEXEC] to load UIDE, if they want to load UIDE into HMA space. SOMETHING is enabling A20 in the FreeDOS kernel, and it does NOT happen, no-matter WHAT loading scheme I use, with MS-DOS or PC-DOS! Look a bit further!, my friend! ... Given that, I am NOT in favor of adding such a hard-enable for A20 in my XMGR driver. If other XMS managers offer such an option, I hope their users Know what they are doing! As all options, the user has to decide whether to use that, yes. How carefully you avoid my problematical comment! Jack R. Ellis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
want is MONEY! decisions [i.e. cheap solutions] HAD NOT been made, and just-a-bit more THOUGHT had been applied!! The kernel already IS doing part of the work! Try ALL of the options on Lucho's boot diskette! You will find that only MS-DOS and PC-DOS are not hard-enabling A20 when they load ... So some drivers can't cope with buggy BIOS/kernels with regard to A20 (and E820) ? I did NOT say that, either -- I only replied to Eric's suggestion about the kernel handling A20 by saying most of them already DO handle it! Perhaps mistakenly, since there ARE still programs which will not like kernels that hard-enable A20, as I noted! One of the reasons why I choose to REMAIN with V6.22 MS-DOS, even despite my many-other thoughts about Gates Flunkeys -- He and all his F's in fact DO handle A20 as their XMS specs recommend! Jack R. Ellis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Alain, In creating JEMM386, Japheth did not merely improve things! He made FD-EMM386 RUN PROPERLY! Finaly you agree with me! Michael Devore's emm386 was tested very very much by the members of FreeDOS and Michael fixed ALL issues. I DO NOT agree with you, and HE DID NOT fix all issues! As far as I know, the many bugfix items I noted in my E-Mail to Eric REMAIN in FD-EMM386! They were fixed ONLY when Japheth did so within his own JEMM386, and FD-EMM386 itself remains NEVER-UPDATED!! Michael started with something, I don't remember what. But he grew so much disgusted with these fights that when the last issue got fixed, he *disapeared* Read the FD-EMM386 source file, to see what he started with. You should more-correctly say When the last issue HE KNEW ABOUT got fixed, he *disappeared*! If that were not so, then like I noted to Eric, HOW do you explain all those bugfix items which Japheth had to address LATER??!! But, Have it your way, Alain! If you wish to continue with a 5-year-old FD-EMM386 that has known BUGS and is NO-LONGER on the Base Software list for FreeDOS, then You go right ahead! and use FD-EMM386. As for me and quite a lot of others, I will use JEMM386, which I consider to be FAR superior and always WILL be! Jack R. Ellis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Jeffrey, As for me and quite a lot of others, I will use JEMM386, which I consider to be FAR superior and always WILL be! What exactly are the advantages of JEMM386? 1) Under current maintenance, not abandoned like FD-EMM386. 2) Many never-fixed FD-EMM386 bugs ARE fixed in JEMM386, as you can read in the JEMM ChangeLog at www.japheth.de. 3) Part of the FreeDOS Base Software list, meaning Cleverer minds than me! value JEMM386 above FD-EMM386, for FreeDOS. Is there a noticeable difference over FD-EMM386 if I am only using EMS for ramdisks/drivers? If you mean the very-old Lotus/Intel/Microsoft Expanded Memory then I cannot comment, as I have never used actual EMS memory. If by EMS you actually mean XMS memory, there should be little performance difference, as the XMS driver handles allocation/use of that memory. Are the bugs dependent on hardware? Most are not, but a few are. Read the JEMM ChangeLog, then you can decide which hardware-dependent problems might have affected its predecessor FD-EMM386. Jack R. Ellis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
Alain, First of all, let me clear one MISUNDERSTANDING ... The EMM386 that works ok is from Michael Devore, which was extensevely tested by the members of FreeDOS. Most of your answer regards Gates Co. product, sorry for the confusion NEITHER a misunderstanding, NOR any confusion, at least not in MY mind! Do note what I posted AFTER my comments about the EMM386 drivers from my [obviously] much adored Gates Co. -- ... I also want NOTHING to do with FD-EMM386 and anyone who wonders why can read the Revision Notes for JEMM386, to view all of what Japheth had to do BEFORE poor old FD-EMM386 worked even plausibly as the new JEMM386! Extensively tested, you say?? If so, and given that the last FD-EMM386 upgrade is still dated 27-Aug-2006, then how would you explain all the updates, in Japheth's Changelog for his JEMMEX and JEMM386 drivers, that are dated AFTER 27-Aug-2006??!! Also, note that JEMM386/JEMMEX are now part of the FreeDOS Base Software list, while FD-EMM386 is no-longer so included. I have reviewed Japheth's Changelog, I believe much of what he had to do changing FD-EMM386 to JEMM386 are Flat-Ass DISASTERS and I shall continue to AVOID using FD-EMM386, just like I would avoid the PLAGUE!! About the A20 issue. I used it because I had a very strange problem: After a crash (with only XMS) the machine never booted again from the disk!!! I had to boot once from a CD and reboot again from the disk. That never happened to me and is completely unheard of ... I suggest that a lot of other things besides the A20 line could have caused such a problem. In my opinion, you need quite a bit more evidence, BEFORE you can fault the A20 line only because your crash appeared to occur with only XMS!! Jack R. Ellis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
In my previous post about FD-EMM386 being changed to JEMM386, and to be perfectly clear, those Flat-Ass DISASTERS I noted are not at ALL in JEMM386 but are in FD-EMM386 and had to be CORRECTED by Japheth! Sorry for any confusion caused by me -- JEMM386/JEMMEX ARE the EMM drivers of choice, in my opinion! -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
RUNNING, and maybe copy-over added files to use if the system boots from a hard-disk, WHO NEEDS an EMM driver in a diskette boot?? I use UMBPCI/XMGR on my own diskettes and have NEVER required an EMM driver when they boot my system! Finally, it is a bit LATE in the game! to be thinking of new schemes for handling the A20 line. My own XMGR has exactly 4 methods: (A) IGNORE A20 if it is found enabled when XMGR loads i.e. the DOS kernel turns it on forever. If you mean FreeDOS: No the kernel does NOT turn on the A20, it asks the XMS driver to do that. But it would be NICE if the driver could explicitly switch A20 ON and THEN does not touch it any more ... You are BADLY misinformed! Make a copy of Lucho's old boot diskette (from the COMBOOTF.EXE file on Johnson Lam's website) and boot from it using Lucho's Option 5, which is FreeDOS. Would you care to GUESS the first message XMGR will give you?? Something like NOTE: A20 line found on!, maybe??!! And if XMGR is the first actual DRIVER loaded, then what-else BUT the FreeDOS kernel is hard-enabling A20??!! A Hairy Thunderer or Cosmic Muffin, perhaps??!! In short, I would be happy about a force-on A20 method. Glad to hear that, since your own FreeDOS is already DOING so! (B) Use keyboard-port logic if /PN was given. (C) Use port 92h i.e. IBM PS/2 logic if /PA was given. (D) Ask the BIOS if port 92h logic is there, if neither /PA nor /PN is given. Fair enough. I hope the BIOS is reliable for the detection. So do I, as such calls were defined by Gates Flunkies about 20 years ago! XMGR doesn't handle the usually-ignored BIOS calls ... What makes you think they are usually ignored? Would the BIOS not at least ANNOUNCE that they are ignored, detection-wise? Knowing the children on that island in the South China Sea who write BIOS programs, I doubt any BIOS would make such an announcement. C is the top language for their masters, who are all cheap anyway, thus TRAINEES get most BIOS work since it tends to be Horror of HORRORS ASSEMBLY-language!! Why do I say such calls are usually ignored? Because XMGR has NEVER supported them, and no one has ever complained to me that the A20 BIOS calls SHOULD be supported! One more nice idea by Gates Co. that I expect nobody uses! In any case, BIOS calls tend to do (B) or (C) anyway, just in a slower way, so you are right to ignore those calls, and the ancient stuff as well, of course :-) Of course! So, why don't we just leave current A20 handling as-is?? See above. Or maybe the KERNEL could do part of the work ... The kernel already IS doing part of the work! Try ALL of the options on Lucho's boot diskette! You will find that only MS-DOS and PC-DOS are not hard-enabling A20, when they load. DR-DOS, the Russian PTS-DOS, ROM-DOS, and FreeDOS all DO hard- enable A20. To use an old U.S. phrase, Don't MESS with success! [and the word mess is the polite 4-letter word!]. Note that my suggestion is NOT related to Alain's I had vague problems and think A20 changes help. It is more my GENERAL suggestion - namely that we should stop switching around a dusty rusty address gate line. Let's just make SURE at boot that the gate is OPEN, then keep it like that. As an OPTION for the command line of any XMS driver, for example ... I disagree. MS-DOS and PC-DOS have good reason for NOT hard- enabling A20 that the other kernel designers have forgotten. There ARE still a few programs which use their OWN enables and disables of A20, and those programs FAIL if the line MAY NOT be switched-off or switched-on! I do not recall exactly what programs they are, but I DO recall that the LOADFIX program in MS-DOS and Windows specifically remedies one such problem! Given that, I am NOT in favor of adding such a hard-enable for A20 in my XMGR driver. If other XMS managers offer such an option, I hope their users Know what they are doing! if they use that option!! [And Know what they are doing has become just as problematical as some of the A20 issues themselves!]. Jack R. Ellis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Undeserved Comment Re: EMM/JEMM, A20, Etc.
I am DISMAYED by some of the recent comments on this board regarding old EMM386 v.s. JEMM386/JEMMEX, the A20 line etc.! First, I use and recommend JEMM386/JEMMEX with my UIDE and other drivers. I absolutely REFUSE using old EMM386 by Gates Co. because it has (A) Never-fixed BUGS in its VDS logic, (B) FAR too much Custom Crap for wretched Win/311 as anyone can see in its 1.8-MB of source files, and (C) is a 125- or 130K driver that eats FAR too much run-time memory! It sucks! in short, and I view UIDE lucky to be able to use its OWN UltraDMA, instead of what Gates and all his flunkies left us with as DMA when they DROPPED MS-DOS in 1995! I also want NOTHING to do with FD-EMM386 and anyone who wonders why can read the Revision Notes for JEMM386, to view all of what Japheth had to do BEFORE poor old FD-EMM386 worked even plausibly as the new JEMM386! Re: JEMM386/JEMMEX failing on some systems, this is likely due to modern address spaces that the JEMM drivers can't detect. But Japheth once told me that he CHOSE to retain all of EMM386's memory-detection logic, so his drivers are compatible with what Gates Co.'s [never updated] TRASH will do!So, do you really expect EMM386 will do a much better job of detecting memory?? I would NOT!! If some system has a problem loading JEMM386, or loading EMM386, its user MUST experiment with the I= and X= commands, to selectively include/exclude address areas, until a desired EMM driver DOES load successfully! Never-was, and never- will-be a fully automatic PC system, and sometimes a few experiments loading drivers (mine included) are NECESSARY! Finally, it is a bit LATE in the game! to be thinking of new schemes for handling the A20 line. My own XMGR has exactly 4 methods: (A) IGNORE A20 if it is found enabled when XMGR loads i.e. the DOS kernel turns it on forever. (B) Use keyboard-port logic if /PN was given. (C) Use port 92h i.e. IBM PS/2 logic if /PA was given. (D) Ask the BIOS if port 92h logic is there, if neither /PA nor /PN is given. XMGR doesn't handle the usually-ignored BIOS calls, any of the ancient Compaq, H/P, ATT 6300 or other 1990s-vintage schemes to handle strange A20 logic (all of which caused Gates Co. HIMEM.SYS to reach 30K!), etc.Except for a bug in its port 92h logic, back in 2009, nobody has ever complained to me that XMGR's A20 logic was inaccurate, inadequate, etc.! So, why don't we just leave current A20 handling as-is?? For 99.44% of us, it works fine! Any strange system on which it does not work usually needs TROUBLE-shooting, NOT yet-another new A20 handling scheme!! -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] UIDE Drivers Updated, UIDE-S Eliminated!
Johnson Lam has posted a new 16-Oct-2011 DRIVERS.ZIP file on his website at http://johnson.tmfc.net/dos/driver.html. In it, UIDE has again been reduced down to a 7.5K-byte file, same as UIDE2, for boot diskettes and other systems having limited space.So, UIDE-S is no longer needed, and it has been eliminated! UIDE2's performance is also improved, and all other drivers have merely been re-dated to 16-Oct-2011. To get UIDE below 7.5K, I had to delete its /M switch./M saved only 256 bytes of HMA, not enough to matter, as UIDE uses only 4336 bytes of HMA in all cases. Even poor MS-DOS V7.10 (short on HMA due to long-filename and Win95/98 logic) still has 9100+ bytes of free HMA, and a BUFFERS=4 command in CONFIG.SYS can reduce what the kernel needs! Most other DOS systems have MUCH more free HMA and should be no problem if loading UIDE with a /H switch. UIDE can be re-assembled with SBUFSZ equ 256, if anyone absolutely requires its 256 byte binary-search buffer (runs maybe 1% slower)! The UIDE2 driver now runs a hair faster for protected-mode users, due to re-adding the old ScnD subroutine which uses a scasw command (not a full binary-search) in deleting old cache-table entries. ScnD is used with UIDE2's /H or /HL switches, as its HMA caches are small enough for such logic. Large caches in upper/DOS memory still use the current UIDE2 SrchD routine, for better speed with bigger search tables. The UIDE caching drivers now consist of only -- 1) The UIDE.ASM source file (assembles both drivers). 2) The UIDE.SYS driver for up to 4-Gigabyte caches. 3) The UIDE2.SYS driver for fast caches in protected-mode. I hope such a simplification is of benefit for UIDE users! -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New 7-Oct-2011 UIDE Drivers, Fixing A BUG In The EDD BIOS!
Johnson Lam has posted an updated 7-Oct-2011 DRIVERS.ZIP file on his website, at http://johnson.tmfc.net/dos/driver.html. The site still has a Last Update date of 9-30, but the files which download ARE dated 10-07-2011 and have been verified O.K. This update is not more driver improvements but fixes a BUG in some of the EDD BIOS logic being used today! Daniel Nice noted that on 3 of his 5 systems, a USB memory stick declared to the BIOS as a hard disk caused the UIDE drivers to duplicate his last actual hard disk! He found the EDD BIOS is NOT updating the DPTE pointer for a USB stick disk -- The BIOS declares 30 bytes of EDD data, but in fact returns only 26, leaving the last actual hard-disk's DPTE pointer still there!! This is clearly an ERROR in the BIOS, that needs to be CORRECTED by those [children, usually!] who create BIOS programs! Daniel suggested a workaround of setting the DPTE pointer to all-ones before UIDE issues Int 13h AH=048h. That worked fine! The UIDE drivers can again handle all real SATA/IDE hard disks without getting confused when USB-stick disks are also in use. Users should upgrade immediately to the 7-Oct-2011 UIDE drivers, if (A) their system BIOS lets USB memory sticks be declared as hard disks and (B) their system also has one or more REAL hard disks attached! Many Thanks to Daniel, who in fact did all my Leg Work! in his analysis and resolution of this Bad BIOS BUG! -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Tom's ALWAYS Good Ideas!
Re: Tom Ehlert's help, Eduardo Casino replied -- A big THANKS to you. Optimising the memcpy routines was my next objective, so you saved me a lot of fun ;) Tom's ideas are ALWAYS good! Maybe half of my UIDE drivers has been much hard work, but the other half is Tom's suggestions in 2003 of (A) using XMS memory as a buffer for UltraDMA I-O which is misaligned or crosses a 64K boundary, and (B) using free HMA space to save upper/DOS memory and putting much of my drivers there! Tom is often quiet in the background, but when he DOES speak, it MATTERS! Jack R. Ellis -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New UIDE Drivers -- Common Core Logic.
Johnson Lam has posted a new 30-Sep-2011 DRIVERS.ZIP file on his website at http://johnson.tmfc.net/dos/driver.html. The UIDE, UIDE2 and UIDE-S drivers can now be assembled from the UIDE.ASM source file, using a /dPMDVR switch for UIDE2 and a /dMINDVR switch for UIDE-S (protected or minimum options). The three caching drivers now have common core logic, and each runs 10 controllers, 34 BIOS disks/diskettes and 8 CD/DVD drives. A lot less upgrade work for me with only 1 source file, also a bit more reliability for users! XMGR, RDISK, and UIDEJR (quite different and still has its own source file!) are unchanged, and are merely re-dated for consistency, as always. Note: By error, the UIDE2.ASM source may still be included, in the 30-Sep-2011 DRIVERS.ZIP file. UIDE2.ASM is obsolete and should no longer be used -- It shall be deleted soon! -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Upgraded UIDE2 and UIDE-S Available!
Johnson Lam has posted an updated 23-Sep-2011 DRIVERS.ZIP file, with all UIDE drivers improved, on his website at -- http://johnson.tmfc.net/dos/driver.html UIDE-S now runs 30 BIOS disks/diskettes and 8 CD/DVD drives, and it also sets the UIDE$ default name when no CD/DVD drives are found, making it more identical to the full UIDE.FreeDOS autoloader scripts could now use UIDE-S, if they can otherwise deal with XMS memory. I am still unable to fit /N3 switch logic (87 more bytes) in a 7.5K-size UIDE-S! UIDE2 now leaves the entire 4608-byte driver (exactly 4.5K!) in upper or DOS memory, when its /HL switch is given. /HL thus allows a 280-MB HMA cache for V7.10 MS-DOS and 425-MB+ for other DOS systems -- My own V6.22 MS-DOS can set 600-MB reliably (used to CRASH above 585-MB)! The 25-MB larger cache may help V7.10 MS-DOS users, and perhaps others, who want a faster cache for protected mode. UIDE2 is also back to 34 BIOS units and 8 CDs/DVDs, same as UIDE like before! UIDE and UIDEJR have minor size reductions, and all other drivers have merely been re-dated to 23-Sep-2011 for consistency, as always. I hope protected-mode users like the new UIDE2. Except for differences in doing protected caching, it is now identical to UIDE in features, still fits in a 7.5K file, and UIDE2 is one of my best drivers ever! -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] UIDE Drivers Updated, New UIDE2.
Johnson Lam has posted an updated 9-Sep-2011 DRIVERS.ZIP file, on his website at johnson.tmfc.net/dos/driver.html, which contains a new UIDE2, also updates to the other UIDE drivers. UIDE2 uses old-style protected mode caching, that was in UIDE until August, 2010. Try as I may, I simply cannot get the current all-XMS UIDE to run any faster in protected-mode (JEMM386 etc.). All of its cache tables are in XMS memory. This requires a slow Int 15h trap thru JEMM386, to fetch any XMS data.Absolutely NOT any fault of JEMM386, but due to Intel's too-complex 80386+ protected mode scheme! UIDE2 sets its binary-search table in memory beyond the driver, which avoids 50% of XMS accesses and saves time -- fewer Int 15h traps in protected-mode. As it uses more HMA or memory for its search table, UIDE2 does have cache-size limits, noted in the UIDE2.ASM file. But it is still up to 5% faster for protected-mode, and so UIDE2 is Back in service! for users who run JEMM386/EMM386 etc. I was also unhappy about UIDE-S running only 4 CD/DVD drives, since there may be a few CD copier PCs with up to 6 CDs.So, UIDE2 and UIDE-S now handle up to 6 CD/DVD drives! Any users who in fact have 7 or 8 CD/DVD drives can still use the full UIDE or the non-caching UIDEJR, which will run up to 8 CDs/DVDs (UIDEJR with its /U8 switch). UIDE2 and UIDE-S are still 7.5K-byte .SYS files, for boot diskettes or other space-limited systems. UIDE2 also handles the /N3 No XMS switch and sets the UIDE$ default name if no CD/DVD drive is found. So, UIDE2 can be run with FreeDOS automatic loader scripts on their distribution CDs. (Not possible for UIDE-S, which now barely fits into 7.5K!). -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
