[Freedos-user] Hello EMM386/HIMEM 2.26, Good-bye Michael
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files emmx226.zip, EMM386 2.26 and HIMEM version 3.26 memory manager, mostly executable files; and emms226.zip, source code files. The FTP-challenged may find the files at http://www.devoresoftware.com/emm386 . EMM386 2.26 is really more like version 2.25.1, but we have enough decimals already. Nothing major, 2.26 modifies the way the default NOALTBOOT option works to improve compatibility with some types of rebooting the computer, particularly with FDAPM. There is also minor improvement in behavior when attempting to run HIMEM and EMM386 on sub-80386 machines. Final comments follow: As far as changes, the NOALTBOOT change was already discussed on freedos-devel. FDAPM should be happier for the WARMBOOT or COLDBOOT options on some machines, and, if we're lucky, Ctrl-Alt-Del may work more universally in complex environments. HIMEM and EMM386 now both state that 80386+ CPUs are required on the help screen and they are UPX-compressed with the --8086 option, also as previously discussed on freedos-devel. I am permanently off-list immediately following this post, unless I am e-mailed notice of a major HIMEM/EMM386 emergency or goof before FreeDOS 1.0 release which requires my expeditious attention. This is not a reflection on FreeDOS, but rather a simple statement of retirement from the job: I'm tired of working on HIMEM and EMM386, I'm done with my work, and it's time for me to move on to other projects. If you will indulge me for two paragraphs, I have a few closing suggestions. They carry no greater weight than anyone else's opinion here. Perhaps less. HIMEM and EMM386 could certainly stand a significant clean-up and rewrite at some point. That said, major feature additions and changes should not be in the EMM386 2.x line, which, I think, should be declared a mature version. Whether that means there will be an EMM386 3.x or another memory manager name/revision as next in line is really immaterial. However, small updates, fixes, enhancements, and changes -- such as several of Arkady's changes, like the build DIF -- should easily fit into EMM386 2.x development and revision and are appropriate to incorporate. I strongly recommend against making optimizations in 2.x which have operational side-effects and which depend upon applications always following a specification. A number of the quirks and revisions in EMM386 and HIMEM have accumulated due to misbehaved programs tested over the years. In theory those revisions shouldn't be necessary, but in actuality they are quite necessary for the programs to work. For those interested in being involved in further development, Tom Ehlert is the HIMEM and EMM386 maintainer and holds copyright on the current code. It is incontestably correct to ask him about his preferences and desired degree of involvement in future development on the memory managers before leaping in and changing stuff around. I am confident that the talented people here can quickly reach peaceful accord on how future HIMEM and EMM386 work and releases should proceed. For anyone who needs personal help or has questions concerning the current HIMEM and EMM386, or related FreeDOS and programming topics, they can contact me at my FreeDOS e-mail address: [EMAIL PROTECTED] However, please do not abuse the invitation. I am not interested in the latest FreeDOS gossip or debate, even if it directly or indirectly involves me. *Especially* if it directly or indirectly involves me. Allow me my blissful ignorance. Good luck and good work, everybody. Ciao. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Compatibility EMM386/HIMEM 2.25 New Release
At 06:50 PM 8/21/2006 +0200, Norbert Remmel wrote: You should also be prepared to send/sponsor this network card to I really would like to do but my boss would cut my head off if I would AT That's just another way to solve the problem :D AT SCNR ;) What is SCNR? Don't know either. But he is right... Cutting my head off would really solve the problem. :-) BTW. Who will go on developping himem/emm386? Is it really true Michael is stopping his memory management application for freedos? :-( Well, first of all it isn't my application, it has many other hands in it, at least some of them still active. Second, I've finished up the feature set I'm interested in and am tired of working on it. That's the kiss of death for programming progress, since the maintainer needs to keep active and interested for success. (The gap appears to be getting filled, so that may be excellent news). Third, the last 2.x version of EMM386 is quite stable for most tested environments I know of, although I know your's is still having problems. I try to never leave people who depend on my work hanging. So even if I'm off list soon, if you continue to have problems with EMM386 that I can help with and -- the big if -- if I can duplicate the problem, I'll see what I can do about fixing it and e-mailing the fixes back to a few of the people here. Someone will have to take over integrating the revisions for public consumption, but that too, I think can be handled by people here without too much stress and complexity. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] corrupted directory sector from using SMARTDRV 6.22 with FreeDOS?
At 05:15 AM 8/21/2006 -0600, [EMAIL PROTECTED] wrote: This problem occurs when using SMARTDRV.EXE (with write caching enabled) from MSDOS 6.22 with FreeDOS. Replacing either avoids the problem. SMARTDRV is pretty particular on some machines. I just pulled the following from the Microsoft site, it sound relevant to the issue. Let us know the results. Double Buffering and Bus Masters Certain disk controllers support a concept called bus mastering. This is where the actual disk controller takes over the bus in order to transfer data to or from system RAM. Some SCSI controllers have this feature. A problem occurs when running in the virtual 8086 mode that Windows 3.0 and 3.1 virtual machines provide. Memory managers such as QEMM and EMM386.EXE also use virtual 8086 mode. The read or write address that is passed to MS-DOS is often not the same as the actual physical memory address. This can cause data to be read from the wrong location or cause data to be written to the wrong address, which in turn can cause erratic system behavior, general protection faults, and the system to stop responding (hang). Microsoft created a standard called Virtual DMA Services, which provides an interface that allows these bus-master controllers to get the correct address and avoid the problems mentioned above. However, some older bus- master controller cards do not support this standard. To allow SMARTDrive to work with these older bus mastering cards, a feature has been added to SMARTDrive that provides a memory buffer that has the same physical and virtual addresses. This avoids the system instability problem at the cost of 2.5K of conventional memory and a small amount of performance (the cost of moving the data to and from the buffer.) To use this feature, place the following line in the CONFIG.SYS file: DEVICE=SMARTDRV.EXE /DOUBLE_BUFFER+ NOTE: This line does not install the cache, only the double-buffer driver; the cache must be installed in the AUTOEXEC.BAT file. Most disk controllers do not need double buffering. This includes all MFM, RLL, and IDE controllers as well as many ESDI and SCSI devices. The Windows 3.1 Setup program will not install the double buffer driver in most cases. In the cases where Setup is unable to determine if double buffering is needed or not, it will install the driver based on the reasoning that it is better to error on the side of safety. A feature has been added to SMARTDrive to help determine if double buffering is unneeded and allow removal of the driver. Once the system is running with SMARTDrive loaded, type SMARTDRV (without quotation marks) at the MS-DOS command prompt. The following will appear: Copyright 1991,1992 Microsoft Corp. Cache size: 1,048,576 bytes Cache size while running Windows: 1,048,576 bytes Disk Caching Status drive read cache write cache buffering A: yes no no B: yes no no C: yes yes yes D: yes yes - Microsoft SMARTDrive Disk Cache version 4.00 For help, type Smartdrv /?. NOTE: The double buffer driver must be loaded for SMARTDrive to determine if there is a need for buffering. If the double buffer driver is not loaded, all entries in the buffering column read no. To determine if double buffering is required, look at the column labeled buffering. For each drive that is being cached, it can have one of three values: yes, no, or -. Yes indicates that double buffering is needed and being performed; no indicates that buffering is not needed. - indicates that SMARTDrive has not yet determined the necessity of double buffering.If the buffering column has all no entries in it, the double buffer driver is unneeded and can be safely removed from the CONFIG.SYS file. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Compatibility EMM386/HIMEM 2.25 New Release
At 09:37 AM 8/21/2006 +0200, Norbert Remmel wrote: During testing I discovered a bug concerning STR-ALT-DEL usage. When pressing these keys, freedos crashes with invalid opcode outputting some memory addresses and registers. As I remember this wasn't like this using earlier versions of himem/emm386 but I didn't test so far. Okay, here's where we have a fundamental conflict. It's also causing problems with FDAPM and WARMBOOT options, perhaps other FDAPM options. It is the difference between ALTBOOT and NOALTBOOT options in EMM386. ALTBOOT was the default prior to 2.25 for a while, and NOALTBOOT is the new default, and was the original default when EMM386 was first written up to an unknown version. The problem is that EMM386 no longer hooks and processes the keyboard keys by default to try and force a proper reboot through direct keyboard port access. It leaves things to the default ROM/BIOS reboot code. The keyboard hook happens when ALTBOOT option is active. Some environments and applications can have the machine state set so that a normal ROM/BIOS reboot doesn't work, which is why there is such a thing as ALTBOOT. Unfortunately, a lot of things fail to work, or fail to work correctly if ALTBOOT is active, which is why it was changed to not the default setting in 2.25. Here's a breakdown of the pros and cons: ALTBOOT active positives: All FDAPM options related to rebooting and power-off should work. Some applications may not properly reboot when you press Ctrl-Alt-Del if ALTBOOT is not present. ALTBOOT active negatives: Qemu has an almost unusable keyboard due to frequent loss of status keys, plus missing and doubled keys. VMware is reported to have keyboard or other failure. Ensemble with GEOS will simply lockup during start if ALTBOOT is active -- GEOS doesn't like things hooking and messing with the keyboard interrupt. There are reports from other users that there are additional applications which do not like the keyboard hooked and (pre-)processed this way, but I don't know the exact applications. So here's where we're at: I can either make some environments work properly (or at all) by leaving ALTBOOT as optional as in version 2.25. That means those who are having problems with FDAPM or Ctrl-Alt-Del need to specify ALTBOOT as an option with EMM386. OR, I can switch ALTBOOT back as the default, and Qemu, VMware, and Ensemble users will have to know to specify the option to make their machines work properly. It's not an easy decision, but personally, I think we're better off getting people booted up and running properly as a default (NOALTBOOT), and then telling them if they have problems with FDAPM or Ctrl-Alt-Del to specify ALTBOOT as an EMM386 option. But maybe I'm wrong, if someone can convince me otherwise. Obviously the best solution would be for everything to work under one option, but I don't see that happening unless someone can come up with a good workaround really soon (I wouldn't count on this, but it could happen). Even MS-DOS EMM386 does not use its own ALTBOOT by default, but warns that it may be necessary or desirable for some environments. [technical follow-ups to freedos-devel] - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Compatibility EMM386/HIMEM 2.25 New Release
At 09:37 AM 8/21/2006 +0200, Norbert Remmel wrote: During testing I discovered a bug concerning STR-ALT-DEL usage. When pressing these keys, freedos crashes with invalid opcode outputting some memory addresses and registers. Eric made a change suggestion which seems to clear up the problem with FDAPM and some options and the default NOALTBOOT of EMM386. If we're lucky, it will clear up your Ctrl-Alt-Del problem, too, otherwise you may need to use the ALTBOOT option. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] corrupted directory sector from using SMARTDRV 6.22 with FreeDOS?
At 02:50 PM 8/21/2006 -0600, Eddie wrote: I was really hoping that this problem had been silently fixed by all of the other work that has been done recently. I was disappointed when the same problem cropped up again - because that means more work. So far I haven't done the work to isolate the problem to a repeatable failure. But I figured that I should send up a red flag so that the rest of you could be watching for the problem. Well, if you want to e-mail a copy of your SMARTDRV and the options you're using, I'll take at least a quick look at what internal calls it might be making, see if anything jumps out and bites my nose. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Test HIMEM version for feedback
I've uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ the file himem324.zip, containing a revised HIMEM executable and source file changed from version 3.23. This is an alternative version of HIMEM I'm making available for testing. It is only slightly modified from the previous versions of HIMEM, in that it reorders the test for A20 control, so that the BIOS method comes after the FAST, PS2, and KBC tests, rather than being first in line. Anybody who has a machine which selects the BIOS A20 method and then acts flaky, or anyone else who is interested or has nothing better to do, please give me feedback on whether there is any difference in your test between HIMEM 3.23 and 3.24. Of course, if previous HIMEMs didn't select the BIOS A20 method on your machine, it shouldn't matter since the behavior won't change. Why, you may ask, is this possibly a good idea? Well, in the last few days I've got a couple of reports from people who have machines which pass the initial A20 BIOS method test, but then fail later on and crash. Yes, you read it right: BIOS works, then it doesn't. Forcing a different valid method via HIMEM's /METHOD option clears up that problem for them. Why, you may ask, is this possibly not a good idea? Because the A20 stuff was already publicly tested a while ago with several volunteers on the list, and the current A20 method order was arrived at as most compatible for their machines. BIOS theoretically should be the most compatible on all machines if it's supported. That theory appears to have a hole in it. Or maybe this will uncover some long-lost subtle bug in BIOS method handling. f you ever saw BIOS A20 control feedback from HIMEM, please let me know how it goes. We can decide up to deadline enforcement on whether HIMEM 3.23 or the test 3.24 is better for FreeDOS 1.0. They're the same code, slightly rearranged. I'd just like to avoid a startup problem situation for some machines which requires CONFIG tinkering to fix, if possible. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Version 2.23 EMM386/HIMEM New Release
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files emmx223.zip, EMM386 and HIMEM version 2.23 memory manager, mostly executable files; and emms223.zip, source code files. This release of EMM386 and HIMEM should improve compatibility with some DOS-extender applications, such as Doom, under various configurations including the Qemu and VPC 2004 virtual environments. It corrects a problem with using the 'G' gigabyte suffix for numeric parameters in EMM386 and HIMEM. For developers, a new build system to allow multiple compilers to construct the managers was also added by Arkady V.Belousov, although not yet officially supported. If anyone had problems running certain applications under a virtual environment, or real DOS, a tryout of this release is recommended. Not really much more to say about it that hasn't already been said and I'm too worn out to ramble on. Please post any questions, comments, bug reports, or feedback to the list, Bugzilla or my e-mail directly. Unless something was mispackaged or involves a critical error with an obvious fix, this will likely be the EMM386 and HIMEM release to go with FreeDOS 1.0. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Updated 1.0 Testing CD
I still can't read your list mails very well, but I was able to pick through most of this. (No, my e-mail utility which has worked for a good many years and doesn't fail on other user comments is not buggy and therefore in need of replacement. Although, it could use an update or change-over for other reasons.) At 07:11 PM 8/4/2006 +0400, Arkady V.Belousov wrote: I think, build subsystem _should_ be _added_ before final EMM386 version will be released - else, because no more permanent, than temporary, EMM386 may never get build subsystem From your remarks we've gone from you can't use the current build system exactly as-is to EMM386 may never get build subsystem. That's a big leap of logic. I think it may have fallen short and fell into the Chasm of Unwarranted Conclusions. BC I don't think it's too hard for a developer to add his makefile BC himself. Yes, he may. But, for example, with different option set resulting executable may work differently (if work at all). Nothing you've listed will change behavior here. You can worry about what would change behavior after the EMM386 rewrite and operational update which presumably is forthcoming post-1.0. You're part of the post-1.0 EMM386 rewrite team, correct? The more so, I don't know, how Michael packs executables As I've stated on this list, several times, the executables are packed using UPX. , so I can't reproduce _identical_ binary. The more so, currently EMM386 sources are _not_ compilable Uh, yeah, they are compilable. Several people have done it, including me. Michael uses some subtle trick to workaround this in his makefiles. Nope. It's pretty much the original build with the file names updated and directories redirected. Finally, quoting portions of my recent e-mail for public record: Every single person who worked with EMM386 or HIMEM source so far has been able to get it to compile sufficiently to work using a free compiler. I even wrote a translator to make it work with an open source assembler so others could build without technically violating copyrights. But I'll make one more compromise. If Arkady wants to put in place _additional_ files which satisfy him and don't modify _existing_ files, I'll take them into the distribution. Why is this on freedos-user? freedos-devel is a better fit. But since it started here, I'll keep the replies together... - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Updated 1.0 Testing CD
At 01:22 PM 8/4/2006 +0200, Japheth wrote: Barring the fileset I requested, or other testable indication that your problem occurs with anyone else, I should not think that would be a problem. In other words, no need to wait for EMM386 3.0 - codenamed The Arkady Factor. Since the error is evident in my eyes, I will not spent any more time to proove this. But indeed there is no need to wait, and for those who might run into the problem as I did, you can download a fixed Emm386 at I asked you for an exact duplicate of a file which demonstrated the problem on your machine so I could duplicate the problem. This is trivial to provide and no effort for you. You apparently aren't interested in doing that, but rather in acting up and pushing your own and others' agenda. Very regrettable behavior. No explanation for the how only nondefault /NOX2MAX32 option could trigger this problem on YOUR machine was provided, so your remarks on the fix are at best incomplete, and possibly rank speculation. I'd look at the problem if you gave me a link to download a program that exactly matches one of the programs you have, and clear up the issue without waving my hands past the open /NOX2MAX32 question. Are you willing to do that trivial task and demonstrate an actual interest in helping to correct the issue, or will you just preach and post here? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Updated 1.0 Testing CD
At 10:29 AM 8/4/2006 -0500, I wrote: At 01:22 PM 8/4/2006 +0200, Japheth wrote: Barring the fileset I requested, or other testable indication that your problem occurs with anyone else, I should not think that would be a problem. In other words, no need to wait for EMM386 3.0 - codenamed The Arkady Factor. Since the error is evident in my eyes, I will not spent any more time to proove this. But indeed there is no need to wait, and for those who might run into the problem as I did, you can download a fixed Emm386 at I asked you for an exact duplicate of a file which demonstrated the problem on your machine so I could duplicate the problem.' Oh, and a simple CONFIG.SYS and AUTOEXEC.BAT, too. My mistake, there, I forgot to ask for that. It's standard operating procedure for everyone when a problem cannot be duplicated from a general description to ask for the exact files and the machine configuration for testing. Typically, people do provide that information, I can't see why it should be a problem. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Updated 1.0 Testing CD
At 08:29 PM 8/4/2006 +0400, Arkady V.Belousov wrote: you. In Japhet' source, I see _at least_ one important change: you eliminate retf 2, but forgot ret 2 in NEW15 (where you explicitly STI before exit). This not need any demonstrations. Nor was it reported. But I agreed, that there not enough explanations what changed. For example, I see, that eliminated call to INT 67/3F - but no commented why. Also, I not see explanation, if move reading keyboard port after checking Ctrl/Alt status is optimization or have some additional impact. If he wants to be a maintainer of the EMM386, he could ask and I might have considered sponsoring him to do it, since I'm publicly on record as being done with adding any new features here. New blood is always good, if they have the talent and he does. However, it appears that the entire intent of this scouring of source code and run of changes was to eventually force a conflict by taking offense where none was intended or to refuse a simple request because it wasn't necessary. Then branch off a new EMM386 the same as HIMEM, and stir up more trouble or to make some dumb point, as has already happened with HIMEM. That's a pretty sad commentary on things. Behavior like this is another reason I'm not terribly interested in continuing as maintainer. But I and the rest of the FreeDOS users do appreciate the actual bugs found along the way. Good job on that. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Updated 1.0 Testing CD
At 06:37 PM 8/4/2006 +0200, Japheth wrote: The issue is of minor general interest, since most FD users will use FD Himem and FD Emm386 with the standard parameters. I've finally been able to duplicate a problem with DOOM under VPC 2004 set at 512M, but not under straight FreeDOS with 1.5G free or selected smaller amounts of free memory. Whether it is the same as the problem reported, I can't say yet. This situation may be sufficient for testing since I'm finally getting a duplicatable problem using the nondefault options. If I get Qemu up next and duplicate the problem, I can bring more heavy duty debugging tools to bear and see what's up. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Updated 1.0 Testing CD
At 10:46 PM 8/3/2006 +0200, Japheth wrote: Blair Campbell wrote: I renamed directory FDOS to FDOSALT. About 6,5 MB free space are left on C: - I booted from CD and select Install, FD does not complain! I am so sorry. I forgot to include the updated install.exe ! I have re-uploaded the ISO with the updated install.exe included. The localize problem will be fixed in the next release hopefully. This is no problem, since that's why we're testing. No need for a hurry, btw., the final FD 1.0 should probably wait for upcoming Emm386 v2.22 to be released :). Barring the fileset I requested, or other testable indication that your problem occurs with anyone else, I should not think that would be a problem. In other words, no need to wait for EMM386 3.0 - codenamed The Arkady Factor. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New version 2.21 EMM386 release, inc. Qemu/FDAPM fixes, maybe
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files emmx221.zip, EMM386 version 2.21 memory manager, mostly executable files; and emms221.zip, source code files. This release of EMM386 has a few fixes and changes, mostly directed to Qemu and FDAPM users, although those modifications are untested for that environment. It also fixes a problem with an advanced EMS handle name set function, EMS free page reporting when using the deprecated EMM= option, and internal corrections that may affect a few people. If you are still having problems with EMM386 2.20, version 2.21 is recommended. HIMEM is unchanged. Once more unto the breach... EMS function 53h, subfunction 1, set name, was stuffing garbage in the system handle name instead. Didn't break anything (the SYSTEM handle name is arbitrarily chosen), but it didn't work either. As with the other advanced handle name functions recently fixed, this would probably affect just a few EMS 4.0-based programs, but it should work now. When using EMM=xxx option, the EMS routines were double-counting the previously allocated pages due to the tighter EMS/VCPI coupling change recently made. You could allocate what was reported as remaining, so the first allocation could pull the full amount of actual EMS pages, but any allocation following that double-counted, so it would only take half of what was really available. Anyway, although EMM=xxx is not recommended for general users, it should give a good EMS free page report now. The is-this-cpu-really-a-386-or-better-or-else-forget-it routine might actually work now that I've made Arkady's change. Untested. A couple of internal VCPI allocator routines weren't always getting the proper flag setting. Since the default conditions didn't trigger the error, it usually didn't make a difference, but it under some conditions (typically low memory or smaller than default-sized blocks, near as I can tell), it could fail to properly allocate all free memory available and return an out of memory condition on VCPI memory allocated. If you ran out of memory running a DOS-extended program and you don't think should have, this fix is for you. One of those weird errors, you don't know why it never come up before and if it ever happened in normal conditions. Me, I'm just glad it's gone, even if it never bit anybody. I eliminated some debug code that probably wasn't hurting anybody. It just wanted to live, but I killed it, because my blood runs thin and cold and the goddess of mercy has never walked beside me. And what all the Qemu and FDAPM people have been waiting for, EMM386 now keeps original flag values except carry flag (status code) on INT 13h, INT 40h, and (I added) VDS processing routines, per Japheth remarks on the code earlier. In other words, RETF 2 is dead, long live IRET. Don't know whether this fixes the problems with Qemu et al, but I'm hopeful. Unfortunately, the IRET code changes are completely untested here, other than to say they don't smoke my computer, and VPC 2004 is still happy. If you have had problems with Qemu, FDAPM, or VDS, please give it a try and let me know what happens. Hey, that goes for everybody else too. What? You need motivation and positive feedback? Okay, listen up. Everyone one reading this message is the coolest, smartest, most handsome, nicest, bestest person to ever walk, roll on, or crawl terra firma. And because you are the coolest, smartest, most handsome, nicest, bestest people to ever walk, roll on, or crawl terra firma, you're going to give me good feedback. Yes? Yes. Man, you are great. If someone knows an easy way to get Qemu and FreeDOS IMG files working under XP without having to burn/rip ISO's a bunch, flip floppies, or other major fooling around, let me know and I'll try it out here. I am incredibly lazy and need streamlined setups for testing, i.e. updating the IMG files with each new change shouldn't take more than a minute or two. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20
At 09:18 AM 7/28/2006 +0200, Norbert wrote: Do you have an idea, why the Pentium III machine is o.k. now and the others not? Use X=A000-EFFF NOVDS Remove all device drivers. Then change and add as booting works. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20
At 02:34 AM 7/28/2006 -0500, I wrote: Use X=A000-EFFF NOVDS Remove all device drivers. Then change and add as booting works. Also, pure boot failure almost has to be A20-related. Nothing else is related to vanilla-configured boot. Manager, kernel, hardware, driver, application, something A20-involved. I don't trust A20 control, even as an emulation. It's a truly horrible PC hardware hack that they should have taken behind the barn and shot after 80286 machines were released. It will likely always cause compatibility issues at one level or another, and it may be that EXEPACK without LOADFIX support simply isn't worth the risk. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20
At 10:39 AM 7/28/2006 +0200, Japheth wrote: On my machine A20 is always enabled. BIOS int 15h reports kbd and fast PS/2 methods being available, but none works to disable A20. IMO if A20 cannot be disabled in real-mode, emm386 shouldn't try to emulate A20 disable in v86-mode. I thought about that prior to the change, but I'm not convinced it's true. A20 always on is because hardware vendors finally grew a backbone (much too late) and stopped supporting turning the thing off. It's not a compatibility issue as far as the machine itself, or at least I don't see it being machine-specific. Anyway, leaving A20 always on will always fail EXEPACK and the early PKLITE without LOADFIX on high free DOS memory machines. Who gets blamed and flooded with bug reports by typical endusers who encounter that? Not the hardware people and not Microsoft or any of the major software players active back when. Nope, it's FreeDOS itself and FreeDOS developers who take the hit. We may have too, but I hope to avoid it as much as possible. [Gee, looks like SourceForge has delays in sending out list posts again. What incredibly wonderful timing on its part.] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 new release 2.20, new HIMEM 3.20
At 03:02 PM 7/28/2006 +0200, Eric Auer wrote: Would it be possible to have a test binary where the A20 trick is disabled and another one where the IF trick is disabled? Then those, for whom the update makes things worse, could check which of the changes caused that. A20 might be controlled though a new EMM386 option. That's about as far as I'll commit to anything there. I'd prefer it actually be off by default unless the option turns it on, but I suppose that would lead to many users asking why their old EXEPACKed stuff doesn't work and needing to be told to turn on the EMM386 option. However, dos4gw based things like CTS Toasted 96 demo and Descent still only work with dos32a. With dos4gw, they reboot or hang. You're the only one I know who can't get DOS4GW to work. As you know, it's was the first extender tested and continues to be first in-line when testing new releases. It's also the one most people are most likely to complain about, and there are no angry mobs with torches descending upon my domicile. Are you sure you don't have a bad EXE for it? Do you know if it works anywhere on your machine under any VCPI-based DOS conditions (not Windows box, Windows box takes over most memory management there as DPMI). One interesting problem is that FDAPM FLUSH hangs now! Alright, send me a link to latest FDAPM source. Might be A20 related, but then why does it work if only HIMEM is loaded? Several possibilities. For one, A20 control might not successfully turn off A20 with HIMEM on your machine, but it's always going to happen with EMM386. Or, the mapping 64K emulation has a subtle difference in behavior. Or, it's haunted. This reply also tests whether SourceForge is only delaying freedos-devel, since SourceForge sent my last freedos-user mail right to the list without delay, while an earlier post to freedos-devel is still out there zipping about the ether. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] EMM386 new release 2.20, new HIMEM 3.20
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files emmx220.zip, EMM386 version 2.20 memory manager, mostly executable files; and emms220.zip, source code files. This release of EMM386 and HIMEM has several changes and fixes, two of a low-level nature, but at a guess, relatively few current users will be affected. Two bugfixes in the advanced EMS 4.0 handle name function 54h were made. EMM386 added support for A20 control, allowing old EXEPACKed programs to work without LOADFIX. A minor XMS free block fragmentation issue with EMS and VCPI was corrected. A fix to XMS API function 88h reporting highest memory address off by a teeny. Due to changes in INT processing, QEMU should now work with EMM386 and CTMOUSE (this is untested). Four of these five issues were found by Japheth. In keeping with my past unilateral and officially unsanctioned declarations, I hereby proclaim Japheth to be FreeDOS Contributor Of The Month. All hail Japheth. A glutton for further information? Read on. EMS 4.0 function 54h subfunction 0, get all handle names, didn't place correct information in the returned buffer. Subfunction 1, search for handle name, was naughty and failed to search the right string. However, almost nothing uses the advanced EMS handle name management -- besides the test program used, I think I've seen exactly one EMS-based program which would use the functions, but not critically depend on them -- so the bugfixes are mostly for forms sake. EMM386 now supports the global and local A20 control functions. Previously it would inhibit A20 disable so as not to map itself out during its operation, turning the computer into an inefficient bread toaster. Rather than actually turn off A20, EMM386 simply maps the first 64K address space into the HMA area on an A20 disable call. This approach allows EMM386 to keep working while allowing it to support programs which were compressed with the annoying EXEPACK, since EXEPACK counted on wrapping from high addresses to low addresses and the FreeDOS kernel adjusts for that by turning on and off A20. Eric Auer provided most of this idea, so he is declared runner-up FreeDOS Contributor. I think the prize for that is a pack of stale chewing gum, but I haven't checked the rules recently. Note that A20 control functions do give one an interesting new way to crash the computer should one fool with them indiscriminately, since mapping out the HMA memory when DOS Is loaded leaves a nice 64K hole filled with garbage where most of DOS used to live. Also note that to do this, an unused EMS function (3fh) was co-opted for FreeDOS use. That's the way QEMM does it, and I figured if QEMM can do it, so can we. The EMS/VCPI allocator in EMM386 will now walk XMS blocks after freeing a shared XMS block and trying to merge any adjacent free blocks it finds. Previously, fairly minor fragmentation of the free block area could occur. While this would not cause failure of applications, it could prove annoying to advanced programmers or programs. XMS function 88, highest memory address was still not quite right. It usually reported one byte too high of an address. Actually, the whole lower word was being zeroed, but since most memory comes in 64M increments, that part of the problem was never noticed and only the highest+1 byte bug would be seen. I don't think many, if any, programs use this value, but it was sloppy coding that broke spec and needed fixing. I blame my garbageman. Not that my garbageman wrote or had anything to do with the code whatsoever, but I haven't blamed him for anything yet, and he'll never know. EMM386 properly turns off the real mode INT flag inside it's protected mode processing routines before transferring to the interrupt. Hopefully Qemu now works with CTMOUSE. Feedback on that point is appreciated. That's the only thing reported which is affected by the change, although theoretically other situations may exist. Probably do. Like the song says, it's a big old goofy world. Oh yes, I changed two comments in EMM386C.C from /* to #if 0. Not because I think it really needed to be done, or because I think it's of much use. No, I did it because I am broken and feeble old man who ran out of jokes for why not to do it long before its cheerleader(s) ran out of pixels. Since low-level changes were made to this version of EMM386, please keep an eye out for any problems and report them as soon as you can. While I don't anticipate new problems, I certainly recognize the perversity of the universe to make them happen. It's possible that the expanded A20 function support, the IF status modification, or coding changes will wreak havoc in one fashion or another. I'll post a quickfix release if anything immediately crashes in a semi-spectacular way. Will this version of EMM386+HIMEM be in the initial FreeDO 1.0 release? I dunno, but judging by the announcement, I'd guess
Re: [Freedos-user] HIMEM - EMM386 Bug 1
At 09:31 AM 7/25/2006 +0200, Norbert Remmel wrote: As promised detailled error description... PC description: Intel Pentium III 600 MHz 256K Cache ASUS P2B Motherboard (Intel 440BX Chipset, AWARD ACPI Bios Rev. 1012) 384 MB SDRAM (133 MHz) 3COM 309B 10/100 PCI Ethernet Adapter Config.sys commands for HIMEM/EMM386: DEVICE=\HIMEM.EXE /TESTMEM:ON DEVICE=\EMM386.EXE NOEMS X=D000-D800 Use X=TEST I'm not convinced /TESTMEM does anything terribly useful, although the people who originally wrote the option or who use it may disagree with my personal opinion there. Disk I/O will always run slower under virtual 8086 mode, present and active by definition with EMM386. HIMEM has nothing to do with it, and that entire topic should be removed from the discussion as irrelevant. Memory managers should not enjoy inaccurate benchmarks by piggybacking them off the actual benefits of other utilities -- UMBPCI in this case. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Freedos Future
At 02:20 PM 7/24/2006 +0200, Japeth wrote: I was advised (thanks Eric!) that there exists a SB option for FD-Emm386. Setting this option indeed cures the SB MPU issues for the protected-mode games I tried. The SB option is easily the goofiest option I've added to any program I've worked on in the past (I'll be kind) five years. SB drivers would redirect an INT 3 vector to a 1ah error code GPF exception trigger. The drivers directly detected and twiddled the existing IDT to accomplish the feat. Why, I don't know. Some sort of anti-debugger trap perhaps, or maybe a hook for an SB extension if present? Anyway, when the SB option is active, the EMM386 monitor detects GPF's with a 1ah error code and reconverts them to an INT 3 by placing the INT 3 call on the stack, jumping back into the EMM386 interrupt handler so that the INT 3 is processed properly, then returning to the original program past the INT 3 opcode. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Freedos Future
At 07:56 AM 7/24/2006 +0200, Japheth wrote: But: DOOM does work with the current himem/emm386. As for me this is true for the newest versions of himem/emm386 (July 2006) only. In fact, any DOS4G application didn't work with FD-Emm386 previously because my machine has 768 MB. Generally speaking, for PC environments it was not quite as simple as large free memory. Professional DOS4G-bound applications (the far more common DOS/4GW never exhibited the problem as best as I can determine) did work with high free memory in earlier versions on tested environments. For them, it was a matter of specific VCPI/XMS/EMS/raw memory configuration as to when failure would occur. If large memory amounts were sufficient to trigger problems with DOS4G there, detection of the error almost certainly would happened much earlier. And do work doesn't mean works well. For example, the MIDI music played in Doom sounds strange with FD-EMM386 on my SB-Live card. My guess is that this is due to missing interfaces in Emm386 (apart from the obscure GEMMIS interface), for example the documented I/O trapping interface (int 2Fh, ax=4A15h). Without a true SB card, I can't duplicate the problem, but I would strongly bet against the Windows-introduced and flavored GEMMIS being used in any meaningful (or at least critical) manner by DOS4G -- or any other DOS extender of notable popularity. Function 4a15h is much more likely, although until two weeks ago I had never verified that anyone actually used the function on a live application. It would be pretty easy to test DOS4G, however. Run a DOS4G application under a debugger, trap the int 2fh interface, and breakpoint on condition ax=4a15h. Unfortunately, I believe this approach will not work here in the absence of a SB card, since card detection and branch past unsupported code likely occurs prior to any I/O permission setup via 4a15h. Your comments raise an important point that is often understressed by developers to endusers. FreeDOS's health depends upon the type of feedback as you have recently provided. It is critical for all users to understand that until a problem they are having is reported and duplicated in a testable environment, it effectively cannot and does not exist with respect to correcting the situation. All current memory manager work has been tracking application incompatibilities via Bugzilla, e-mail, and list, then mitigating any which are found by suggesting user corrections to initial setups (common); making the memory managers work around bugs in applications themselves (infrequent); extending API support (occasional); or fixing actual bugs (fairly rare). When there are no pending verified bug reports, no further development gets done. Already, this has happened for multiple-month stretches at a time. There have not been any major feature enhancements for over a year on any memory managers -- probably closer to two years. Major feature work is complete. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Freedos Future
As a matter for record, since it's been incorrectly reported twice now: FreeDOS, HIMEM, and EMM386 work fine with Doom. It was one of the first tests of VCPI support and is often checked against as a baseline. There are no known applications which fail under FreeDOS HIMEM or EMM386 with the FreeDOS kernel and which work with Microsoft or other version memory managers under the FreeDOS kernel. The rest of the original post is even less accurate. Unfortunately , I did expect off-list marshalling of allies for further posts and personal attacks, which has come to pass. It's a sad situation: no winners, we all lose from this behavior. As promised, I won't respond further other than to clear up direct misstatements of fact that confuse FreeDOS users into believing something doesn't work when it does. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] [Freedos-devel] EMM386 2.11 minor update, VDS fix
At 06:20 PM 7/18/2006 +0200, you wrote: There is a bug left in the FD-Himem.exe memory manager. Nope. But see further... When a program that had allocated several XMS blocks doesn't release these blocks in the order FD-Himem likes it, it will report a too small largest free block. Luckily the memory is not permanently lost, FD-Himem is able to regenerate if certain conditions are met. This is a snapshot of the FD-XMS handle table after DOOM was launched and terminated: -- XMS version: 0300h XMS3+ largest free block (kB): 702036 BAD No, GOOD. Or, actually, CORRECT, but not terribly GOOD. Is there a BARELY COMPETENT choice? Again, we have a situation where there is a bug label for what is merely suboptimal behavior. Besides suboptimal, programmers also refer to this type of code as dumb, idiotic, and so bad my 90-year-old blind grandmother could code it better by typing with a pencil clenched between her butt cheeks. (That would be a number 2 pencil, naturally). Wow, two butt reference e-mails in a row. I must be anal. Okay, I'm having way too much fun with that, time to move on. What is happening is that the handles are associated with memory that is fragmented into separate chunks. To the best of my knowledge, under FreeDOS a memory report does not force blocks to coalesce, so FreeDOS is correctly reporting the largest (allocatable) block. In its defense, I believe that contiguous XMS blocks will be merged on allocation if there is insufficient memory contained in a single block, although I might be remembering that wrong. In other words, if my memory is correct, block merges are done on allocation, but not on release or reports. You could argue that FreeDOS HIMEM should be more intelligent about coalescing contiguous blocks on memory reports. And you would be right. It should. That particular code function is hardly the smartest memory management in the DOS world. That title would be reserved for how EMM386 shares XMS memory with EMS and VCPI (well, maybe not, but it IS pretty damn smart there). Suboptimal behavior which acts in a well-defined manner, however rude that manner may be, does not rise to the level of a bug. Should I fix it? Yup. Should I fix it before FreeDOS 1.0 is released? I'm not convinced it's time to go in and start ripping around the code with less than two weeks to go. Particularly since the actual benefits for almost everyone using FreeDOS would be nonexistent. Later tonight as time presents itself, I'll look at the actual offending code and see what would be involved in upgrading HIMEM's IQ points in that area without any possibility of my introducing potential nasty bugs at the last minute. Uhh, not me introducing bugs, I mean that Sith Lord. But to be honest, there's a good chance this one won't make the FreeDOS 1.0 cut. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS under VPC 2004
At 09:21 PM 7/12/2006 -0400, Keith Weisshar wote: Microsoft just released VPC 2004 as freeware today. When I install from the FreeDOS ISO under VPC 2004 I get an CRC error on mode.com with missing required package.us during install and at the end of the install and I reboot I get a missing command interpreter. Woo hoo! After reading your message, I tried out VPC 2004 and I think I've found the VDS bug in EMM386 that's been plaguing me and several users for the past year. Really stupid register-trashing bug; it's hard to believe VDS worked as well as it did most of the time. Applause to Microsoft. Now I'm going to have to kiss you. Or, not. Well, I could send you a few bucks so you can buy a kiss from someone more favorable to the eye and osculatory inclinations -- you know, whatever's the current non-supermodel rate. Plus, there's just enough time to sneak an EMM386 2.11 version in under the wire. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] New Release: EMM386 2.10, HIMEM 3.13
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386/ are the files emmx210.zip, EMM386 version 2.10 and HIMEM version 3.13 memory managers, mostly executables; and emms210.zip, source code files for the new release. The latest revisions (effectively completed in May) contain several compatibility modifications and two bugfixes. The bugfixes apply to DOS-extended programs for certain DOS extenders running under large (256M) free memory conditions. The compatibility modifications remove the need for a few programs to specify options or memory configurations to work correctly, and they stop VDS warning feedback for users of DiamondWare's Sound Toolkit (DWSTK). Almost everyone is welcome and encouraged to give feedback on the revised memory managers, particularly should any problems persist. As regular readers know, gory details follow: First, the bugfixes. Previously, EMS allocations were insufficiently coupled to VCPI allocations, meaning that sometimes the reported and actual EMS available for allocations did not take into account VCPI allocations already made from their pool (EMS and VCPI always share the same memory pool). This was not instantly fatal to DOS extenders which depended on the information, but depending on their allocation strategies could confuse some extenders to the point of serious misbehavior, plus it was generally a bad idea that needed fixing. So it was. Second, the VCPI server, aka EMM386, did not temporarily reset linear memory to its own memory mapping via CR3 reload on direct calls to the server. Since most memory tables lived within the common 4M memory shared with a VCPI client, this typically was not an issue. However, if a target environment had more than around 256M free, and a DOS extender made protected mode calls back into EMM386 to allocate memory blocks (not all do), the memory page table mappings were large enough to extend beyond the shared 4M zone, and EMM386 tried to grab pages from memory that owned solely by the VCPI client. This Is A Bad Thing And Made Bad Things Happen. Since it has been established that I do not ever have any bugs in my code and the bug is indisputably present, the only logical explanation is the covert intervention of a malign deity. Watch yourself while coding; dark forces gather to oppose FreeDOS 1.0. Moving along to compatibility changes, EMM386 VDS function 0ch no longer returns an unsupported code. It is treated as the no-op it effectively is under EMM386 and always returns success without warning feedback. Also, VDS function 0bh silently returns an unsupported code without giving warning feedback. Previously, both would give feedback, which caused great consternation to users of DiamondWare's Sound Toolkit that made the function calls. Riots ensued, dogs howled, and the entire student body of a women's college stripped to nothing and ran down the street...uhh, no, wait, that was last week's late night Cinemax movie that I had far too much self-respect to watch a single minute of. Anyway, the warning message is gone with DWSTK under EMM386 and people should feel less worried about the whole thing. EMM386 has a more efficient memory allocator when a user requests more memory be set-aside on the command line options than is available in the machine. Previously EMM386 would divide by 2 until the request could be met. So, if you requested 64M and 30M was available at startup, you would up with 16M. Now, after failure on initial request, EMM386 tries to allocate all it can that it sees available, so in the example you should wind up with 30M, assuming no memory fragmentation. Also, EMM386 reserves more XMS memory from ever being allocated by EMS/VCPI for those few goofy programs that always want a little bit of free XMS or else throw a tantrum. 386K is now reserved, of which FreeCOM usually chomps off about 100K or so, leaving between 256K and 300K XMS. HIMEM now defaults to using the /X2MAX32 option, because two people have reported (buggy) applications that needed it. Depending on what multiplier you use for reports vs. actual problems, that likely means 20, 200 or 2000 people really need the option turned on. Since it's such a silly thing anyway, I just decided to make it the default and avoid a bit of confusion in the world. Also added was a new /NOX2MAX32 option to inhibit the /X2MAX32 behavior and restore the world to its normal state of affairs. Oh yeah, XMS 3.0 function 88h was modified to have ECX correctly return the highest available memory address per XMS 3.0 specification. Wooo, that might be a big deal and fix some problematic stuff you say? Forget it, Microsoft's own HIMEM from MS-DOS 6.x screws it up and returns a garbage value. Probably nothing uses the value, or should, anyway. Finally, copyright messages were updated. Yup, saved the biggest change for last.
Re: [Freedos-user] [Freedos-devel] New Release: EMM386 2.10, HIMEM 3.13
At 10:18 PM 7/8/2006 -0500, Michael Devore wrote: a bunch of stuff, but forgot to mention something people asked me about earlier I used the newest release UPX 2.01d to compress this version of EMM386 and HIMEM. It saved about 400 bytes for EMM386.EXE and 200 bytes for HIMEM.EXE over the old mutant UPX. Yeaaa, the new UPX works with DOS EXE/SYS files. Yeaaa, the UPX developers mentioned me in the THANKS file. Yeaaa, big party at Jim Hall's house when FreeDOS 1.0 is released, free ice cream and pink lemonade for everyone. Okay, I made that last part up. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS 1.0 in the news...
At 04:39 PM 7/3/2006 -0500, Neal Gompa wrote: Yet, without much modification to the configuration of the system, and grabbing some proprietary utils, it cannot run Windows for Workgroups... It is better, I agree, but to be fully compatible, it should run one of the most complex apps out of the box, which is Windows for Workgroups 3.11. An excellent FreeDOS 2.0 goal, so that no one need feel complacent or that all the good stuff has already been done in 1.0. 1.5 goal, even. Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Updating CauseWay
At 01:19 PM 6/21/2006 +0200, you wrote: Hello! It's me again. I changed my compiler back to Open Watcom 1.1, because 1.2 can't compile the Duke Nukem 3D source code. :) But now, I have a problem: it comes with an old version of CauseWay, and I don't know how can I update to the latest CW. Can somebody help me? I downloaded cw349.zip from Mr. Devore's site. I think it is the latest version. Open Watcom 1.5 has a later 4.x version, but the differences are mostly academic for 99.99% of users. There are also stub or ASM updates around, but nothing major. You can use CWSTUB.EXE (possibly known as CW32.EXE) to run a program stand-alone by overriding a boundiin extender, e.g. CWSTUB APP32.EXE. Or you can update a bound-in extender to current CW version via CW349.EXE, possibly named CW32.EXE, via the /U switch, e.g. CW349 /U APP32.EXE. Really I don't remember the exact executable names, but there simply aren't that many of them to be a big deal and running them separately to see what they do won't bite you. Alternatively, you could split out the original extender stub from your EXE and copy in a CW stub via COPY /B command. Or you could just recompile with a recent OW and have the extender bound-in as part of the linking process. All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Want to read FreeDOS mails in a sensible order
At 08:26 AM 6/15/2006 -0500, jp_freedos wrote: On Thu, Jun 15, 2006 at 07:44:08AM -0500, Jim Hall wrote: I'm sorry my president's an idiot. I didn't vote for him. Clinton is not President anymore. Clinton was, among other things, a Rhodes Scholar, and generally conceded as brilliant by his peers including those who hated him for political or ethical reasons. Not that my remark is on-topic either, but it's nice to occasionally repair a few holes in the historical record wreaked by the radical right. Dragging matters back to FreeDOS, there should a new version HIMEM and EMM386 released by the end of July, although the end of June is an optimistic target if work clears up within the next week. So far no major bugfixes, but two or three compatibility fixes and modifications that may affect some users. Clearing misbehavior with a couple of DOS extenders under large free extended memory (512M-2G) conditions is a focus. I also anticipate smaller executables if the new UPX works as it should -- assuming the official UPX release has better (i.e. not open-source) compression techniques built-in, as it did in past releases. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] OpenGEM 5 freezes/hangs/locks on FreeDOS 0.9 SR2
At 11:38 AM 6/5/2006 -0400, John Hupp wrote: I could also have added that all my DOS games (Doom, Quake, Duke, Spacequest, Beneath A Steel Sky) run fine on this computer and configuration. On the chance that there was a physical memory problem I dropped from 16 to 8 MB (no difference), and then also swapped in the extra 8 MB (no difference). One thing I noticed in further testing was that Draw, Paint and Doodle have the most problems. All freehand programs. And if they load successfully, then they work until you try to close them. Artline is rather stable by comparison, though it does not seem to offer a freehand tool, at least that I could find quickly. If I drop all the way to no HIMEM and no EMM386, there is insufficient memory to run Artline or Paint. Draw, Write, Tetris, Scgem, and Fanwor all seemed to work. But Doodle locks the machine when it closes. If I add back HIMEM but not EMM386, Doodle causes a reboot while it is loading. And Write and Draw lock up the machine while loading. If I add back HIMEM and EMM386, Doodle, Draw and Paint all lock up the machine while closing. I'm in the middle of working full-time on two different projects, but I might be able to take a look at this in a week or two. Probably not sooner and possibly later. I'll need a download link for the problematic GEM, though. If it's kernel, I likely won't be able to help further. You might also try EMM386 NOALTBOOT option. I know GEOS needs that option, not that it has anything to do with GEM. Except for starting with a GE, so maybe that's it. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] re: game crashes
At 12:09 AM 5/6/2006 +0300, dima wrote: This is screenshot with error message: http://www.geocities.com/x696365/stuff/xcomap01.zip Okay, final progress report for a while. I installed new DOS sound drivers on the old machine. After the installation I was able to successfully run the xcom game. Yeaa! One time. Then it failed again under all memory manager versions and no memory manager scenarios. As before, this points to either a failure or incompatibility with FreeDOS itself, or a bug in the game. Because the game did work once after copying a lot of files and running various setup/sound check programs, indications are xcom is referring to a particular memory address being set to a value that it is not normally set to under FreeDOS. Whether that address is valid and should be expected to be that value is difficult to say: if it is, then FreeDOS needs correction, if not, then the game has an error. Unfortunately, xcom will not run under one of my debuggers (TD) and DOS/4GW Pro locks out the second debugger (386SWAT) from the exception, so it is hard to research further detail on where the failure is. I suppose if one were desperate to play under FreeDOS, they could take heart from the fact that the game did run successfully one time out of about a hundred tries. Not heartened by that news? Well, no, me neither. If I figure out a way to figure out a way to find anything more, I'll let you know. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Answers to Eric's repeating and repeating questions
At 04:23 AM 5/6/2006 +0800, someone who refuses to directly face those he accuses wrote: As far as I remember, Jack did not want to tell us about the four (if I remember correctly) critical bugs in himem/emm386, so Michael cannot fix them either. He only told us THAT there are bugs, but did not provide details about the bugs. Don't rewind your tape anymore, very annoying. Mr. Devore refused to believe FD-HIMEM have bugs, so we have no need to report anything. That's an outrageous and stupid lie, since you could not possibly find any reference where I would stated any such foolish thing.I happen to believe that FreeDOS HIMEM probably does still contain an obscure bug or two. Maybe even three. Frankly, after that ridiculous statement, I must believe you are also lying about discovering bugs in FD-HIMEM. Certainly you cannot produce any such bugs under pressure to come clean on the matter. However, if you had, even coming from you, I would have fixed them. And that's the last communication I will have with you directly or through your parrot, Johnson Lam. If you do really have a buglist and your conscience ever tickles you to report them, please find someone reputable to send them on to me. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] HIMEM bug
At 08:11 PM 5/6/2006 -0500, I wrote: I happen to believe that FreeDOS HIMEM probably does still contain an obscure bug or two. Maybe even three. I did fix a fairly obscure HIMEM bug today, as a matter of fact. Haven't found anything which needed the fix, but it was definitely a deviation-from-spec bug. Still trying to track down a HIMEM+EMM386 interaction with a few games using an old DOS/4G Pro DOS extender version where they fail if there is too much extended memory present (i.e. 512M). Regardless, I'll be posting a new HIMEM and EMM386 revision soon, since I have several paying work tasks this week to deal with instead. We should also soon know if the new UPX 2.0 compresses EMM386 better than my unofficial UPX 1.25 mutation hack. I am hopeful. Anyone who wants credit for finding other bugs, now is the time to get them in... --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] re: game crashes
At 12:09 AM 5/6/2006 +0300, dima wrote: Game won't to run without himem and emm386 or fdxxms and umbpic, cause not enough memory. Okay, I stole a 48M Pentium 133Mhz laptop from the clutches of a Cro-Magnon in a passing time-rift and tried the game out on that. Under FreeDOS SETUP.EXE still doesn't work as expected, but the game does start and then give the exception you list after selecting a difficulty level. Unfortunately, it does exactly the same thing with the MS-DOS memory managers. And the two test machines are about as different as can be, with almost nothing loaded other than a mouse driver and DOS=HIGH in common. So whatever is happening, it's happening either with FreeDOS kernel itself or the mouse driver (which is really unlikely). Too much memory is pretty well ruled out if 48M still fails. Excluding all high memory fails with either MS-DOS or FreeDOS HIMEM+EMM386 so a bad UMB is not it either. Have you tested this in a pure MS-DOS environment to see if it works? SETUP.EXE and the game will run here under a Windows 98 DOS box, at least to the game beginning. (While I have this relic to test on, who was the guy who had problems with unsupported VDS and an application? Might be able to duplicate it now.) --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] running descent in dosemu (was: game crashes)
At 11:28 PM 5/5/2006 +0800, Johnson Lam wrote: Mister, I also don't like this sort of extremely early speculation coming on the heels of Mr. Lam's recent spate of ridiculous posts, because it just feeds Thank you for your praise. into him posting more irrelevant advice about trying alternate memory managers when they have nothing to do with the situation. Plus, it confuses and wastes time for general users who don't -- and shouldn't need to -- understand fine details of how memory management affects various low-level behaviors. I don't want more argue with you, if you insist you're correct. But Jack did give his true heart advise to some people, to avoid using FDXMS and HIMEM, not because of the author, just because of they both have programming flaw! You don't know about programming flaws; you only mirror what Mr. Ellis posts to you without a clear understanding of the content or applicability. Basically you are scanning the list and any problem report which mentions a startup CONFIG with memory managers or any HIMEM or EMM386 style memory manager version, you now hop in-topic to try and sell your preferred product. I strongly object to that behavior. The biggest strength of open source projects is collaborative input on problems and development. It is not finding a purported bug or bugs to taunt other developers and announcing one has privately created a much better closed-source solution. Actually, that wouldn't be so bad, as it would be another of the sort of daily open source sideshows -- a few of which are entertaining. What is not acceptable is refusing to post details about the errors one claims to have found so they can be identified and fixed in an open source version. Bugs as private trophies, phooey. Honestly, I don't think everyone involved here can help how they act. But you can. You choose not to, which, frankly, I believe makes you a willful agent of damage to FreeDOS. Incidentally, if you have any remaining links or references to me on your site, I ask you remove them at your earliest convenience. And if you wish to repost abusive e-mails or list messages concerning me, I further ask you limit them to one -- two at most if the concentrated vitriol cannot be safely contained in one -- to conserve the other list members' reading time. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] re: game crashes
At 12:09 AM 5/6/2006 +0300, dima wrote: Game won't to run without himem and emm386 or fdxxms and umbpic, cause not enough memory. I found that it also helped to run the game with DOS32A instead of the built-in DOS4GW. You can get it here: Yes, sometimes it helps. But in this case I have such message: DOS/32A fatal (3003): file xcomapoc.exe does not contain any valid exec format. Do not think that the file is broken! It is run very well under Windows 98. I didn't notice last e-mail was private before sending, so I'll repost my follow-up question to the list in case other people know about the x-com apocalypse game and can tell me how to start it. Is there some trick to making this program run? On my system, running SETUP.EXE just sits there, although it goes back to DOS prompt after pressing Return twice. Running XCOMAPOC.EXE brings up the DOS/4GW Pro copyright message and nothing else displays, although Ctrl-Alt-Del reboot works. Maybe I'm not understanding how to run the program. This is with no memory managers, Microsoft memory managers, and FreeDOS memory managers. So it's not a memory manager issue. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] game crashes
At 12:02 AM 5/5/2006 +0300, dima wrote: Hello. Does anyone there have experience about how to run x-com apocalypse under FreeDOS? Send the game to me or tell me where to grab it; I'll take a look. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Booting FreeDOS from a SCSI Hard Drive
At 04:48 PM 5/3/2006 -0400, Mark Bailey wrote: Thanks very much. I'll have Steve try to trace the problem. I am rather DOS illiterate, I'm afraid. What do you mean by Will the SCSI base address conflict? Do you think the BIOS grabs some high memory that emm386 might affect? The current fdconfig.sys loads emm386 without any options: device=emm386.exe I do not recommend a no-option approach if there are any problems suspected or flagrant. At a minimum the X=TEST option should be present. You can also try NOVDS in case there is a SCSI conflict. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Booting FreeDOS from a SCSI Hard Drive
At 09:04 PM 5/2/2006 -0400, Mark Bailey wrote: Bad or missing Command Interpreter Enter the full shell command line: command.com /P /E:256 The development kernel fixed the Error in the DJ mechanism! but still doesn't find the shell. Any suggestions? Is there a problem with SCSI drives? Does it successfully boot naked without memory managers loaded? --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Not to flame but let others know ...
At 01:43 PM 4/19/2006 +0800, Johnson Lam wrote: Forward an email from Jack, hoping everyone can understand what's going on, I'd like the others to understand the whole thing, not out of context: snipped It is a flame, as you well know, but it seems you have become immune to any sense of hesitation in reposting inflammatory screeds. I could continue with my own rebuttal of your QHIMEM reposts -- avoiding the gratuitous insults and irrelevant digressions -- but what's the point? Early on, the original QHIMEM rationale post makes a point of how great the HIMEM clone product is for reducing handle overhead via the mechanism of breaking the existing MS XMS/HIMEM standard of a miserable ten bytes per XMS handle as publicly documented in Ralf Brown's List. This, as if simple information compression were a programming feat of skill, instead of a minor coding task that was deliberately selected against to ensure MS compatibility. Sorry to say, but a read of the Ellis manifestos makes it quickly clear that no productive communication on memory management is going to come out of an ongoing dialog with that programmer. Ego, indeed. I see no further reason to pay additional attention to Mr. Ellis's extremely silly public posts on the user list. Nor to yours, providing they do not conflict with the real FreeDOS work that I and many others do. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Detail explain of Why QHIMEM
At 01:17 PM 4/17/2006 +0800, Johnson Lam reposted a private e-mail: that should never have been publicly reposted What I suggest you reflect upon, Mr. Lam, are your personal reasons for posting this entire private e-mail to the public list. It serves little purpose here other than to incite more anger and hurtful retaliatory remarks. The action follows on the heels of your sidetracking a technical support request into an exercise in unrelated memory manager advocacy. In short, your recent behavior demonstrates a serious failure of judgement in how to positively contribute to an open-source project. Apparently you feel uniquely justified in your efforts to topple stable and well-tested drivers in favor of the output of a single individual you hold in unimpeachable regard. Directly or by proxy, you denigrate the sum of thousands of hours of testing, development, and support hours contributed by hundreds of FreeDOS users and developers. Project team effort is all to be swept away by the single unsung genius. For you, the presumed raw talent of one person trumps all other aspects of development and the talents contained therein. And finally, although the new driver is at least three years too late to enter the official FreeDOS memory manager race this close to the 1.0 release goal line, it seems it still must be crowned the best mostly by virtue of -- as near as can tell -- abuse towards the unenlightened. Who you like and what you think of their work is strictly your business. The rest is not. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Re: EMM386 causes Ctrl-Alt-Del to fail with some video cards
At 09:29 AM 4/15/2006 -0400, you wrote: So I added back a range exclusion, thus: NOEMS X=A000-EFFF VDS NOALTBOOT. This booted up in unstable condition, locking altogether (or with Ctrl-Alt-Del still not working). I increased the exclusion to the range that one of you had recommended: NOEMS X=A000- VDS NOALTBOOT. This booted into stable, functional condition, and Ctrl-Alt-Del works. No, you're doing something wrong or incompatible unrelated to switches. There is no functional difference between X=A000-EFFF and X=A000-. Also, VDS is a default and need not be present. I suggest you are mixing (older) versions of EMM386 or else you're loading an unstable driver. X=TEST and NOALTBOOT (for your card) would be the recommended options with latest version EMM386, possibly to include NOVDS (probably unnecessary). --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Not loading high: Display, Nlsfunc, Keyb, Lbacache
QHIMEM is a totally new and alternate -- utterly superfluous in my opinion -- memory manager that can have nothing to do with your problem, and I do not recommend it's use for debugging here. There is no correlation between the HIMEM-style memory manager and an application's use of upper memory blocks since it doesn't do the memory mapping and does not load the programs when DOS is in control of UMB's, as you have indicated. I suggest being highly suspicious of people attempting to rewrite your CONFIG.SYS files to serve their own advocacy purposes. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 causes Ctrl-Alt-Del to fail with some video cards
At 06:15 PM 4/14/2006 -0400, you wrote: Hello, all. Here is another issue arising from my check-out of the new Service Release 2. I find that loading EMM386.EXE can cause Ctrl-Alt-Del to fail. I boot fine, then press Ctrl-Alt-Del from the DOS prompt. The screen goes black, but the video and system BIOS boot messages never reappear. Very occasionally the keyboard is locked altogether and does not execute Ctrl-Alt-Del. I trigger the problem even with this minimal DOS configuration: CONFIG.SYS (from either the hard drive or floppy) DOS=UMB DEVICE=C:\FDOS\BIN\HIMEM.EXE DEVICE=C:\FDOS\BIN\EMM386.EXE That's not minimal. Recommended minimal is EMM386 X=TEST. Most minimal would be EMM386 NOEMS NOVDS X=A000-EFFF. You should also try NOALTBOOT option since you're having problems with Ctrl-Alt-Del. ALTBOOT is the default condition. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Installation Problem
At 10:55 PM 3/21/2006 +, FreeDOS Ankreuzen wrote: Yes on some mainbords PC s with PENTIUM II, there is a problem to install FDOS BETA 9SR2 from CD. If it s possibel use a Bootdisk with old FreeDOS Version and pre-install FreeDOS manually. Please tell me if you are using a Pentium II or which Mainboard it is. I ve this problem with a pentium II NMC mainbord you should boot the floppy without EMM386! use fdxms.sys or fdxxms.sys and umbpci. I ll create a bootdisk. As an alternate choice, you might try locating the actual problem, which likely is not within EMM386 itself, rather than telling people to use obsolete versions of software which won't fix the underlying problem and which fail to provide a full range of machine capability and compatibility. Creating additional bootdisks of old version software rather than addressing fundamental problems do not help the situation ,and make the multiple FreeDOS version selection even more confusing. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Installation Problem
At 02:07 PM 3/25/2006 -0600, I wrote: As an alternate choice, you might try locating the actual problem, which likely is not within EMM386 itself, rather than telling people to use obsolete versions of software which won't fix the underlying problem and which fail to provide a full range of machine capability and compatibility. Also, I'm not talking about the UMBPCI software within the context of providing full capability and compatibility, so no flaming e-mail exchanges from anyone this time, please. UMBPCI is fine with me, ok? --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] HIMEM64 3.12 freezes after loading on thinkpads and Dell OptiPlexes
At 07:36 AM 3/17/2006 -0800, Andrew Greenberg wrote: Hi everyone, HIMEM64 3.11 [Apr 09 2004] has worked solidly for us across many machines. We thought we'd try the latest version, HIMEM64 3.12 [09/11/2005] but it consistently is freezing on us, especially on thinkpads. Booting from a CD, with a 2.88MB boot image, we get this: FreeDOS HIMEM 64 3.12 ... Interface : XMS 3.00 80386 4G HIMEM - BIOS A20 method used Kernel: allocated 41 Diskbuffers = 21812 Bytes in HMA Umm, that's past HIMEM, actually. Look at whatever comes next in the CONFIG file. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] HIMEM64 3.12 freezes after loading on thinkpads and Dell OptiPlexes
At 04:50 PM 3/17/2006 -0800, Andrew Greenberg wrote: - DEVICE=A:\DRIVERS\HIMEM.EXE SHELL=A:\COMMAND.COM A:\ /E:1024 /MSG /P=A:\AUTOEXEC.BAT DOSDATA=UMB DOS=HIGH,UMB FILES=20 BUFFERS=20 LASTDRIVE=Z SET BOOTDISK=A: SET DIRCMD=/p /ogn SET LANG=EN Take out the DOS and DOSDATA lines and see what happens. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Instructions for making USB key bootable. . .
At 11:09 AM 3/15/2006 +0300, Arkady V.Belousov wrote: MD If I start up FDISK, it sees a partition on the USB MD stick. If I then use FDISK to remove that partition, afterwards the USB MD stick cannot be accessed by FreeDOS tools (including FORMAT or DEBUG) or MD Windows re-format. Of course - they works only with partitions (which you remove with FDISK). Just recreate partition again. Or I not understand something? Yes. Creating a new partition with FDISK doesn't work. It thinks it works, but the stick remains unusable until the HP tool reformats it. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Instructions for making USB key bootable. . .
At 12:07 PM 3/15/2006 +0300, Arkady V.Belousov wrote: 15-íÁÒ-2006 02:36 [EMAIL PROTECTED] (Michael Devore) wrote to freedos-user@lists.sourceforge.net: MD Yes. Creating a new partition with FDISK doesn't work. It thinks it MD works, but the stick remains unusable until the HP tool reformats it. Why this may happen? I thought I was asking you. Because I sure don't know. If I had to guess, I'd say that USBASPI was getting in the way of the partition creation but not the removal, which still doesn't make a whole lot of sense. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Any volunteers interested in testing USB stick booting?
At 09:27 AM 2/28/2006 -0500, Mark Bailey wrote: Hi Michael: I received a sealed envelope from you yesterday. It contained a card with a note about a white cover but no USB stick! :-( Did the stick fall out or something? Ha, if there's not a hole somebody nabbed it. And it was worth a whole $10, probably $3.00 resale value. Welp, I have another one I can send, although I'm having my own problems with the USB sticks. Seems now I can only make them format as hard drives, rather than the original problem of only floppies. Once changed, format-type is tenacious. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Any volunteers interested in testing USB stick booting?
At 03:46 PM 2/28/2006 -0600, charlie_chan wrote: As a postal worker for 22 years, I will tell you with certainity that if you use an envelope to mail it you made a mistake. Every post office that processes mail and some that don't have a collection items that should never have been mailed in an envelope. Strictly a risk/reward ratio consideration. Pay 60 cents to mail a $10 item I don't need and take a slightly higher chance of its loss, or pay $4 to support a nicer packing solution which would almost certainly get there intact. USPS is, overall, fairly reliable and it was worth the risk. That said, as you may know, within the past decade the USPS Chicago metro area was considered one of the worst in the nation for its speed of delivery and lost piece count. That may have changed for the better after several public expose's on the subject, but perhaps I should have factored that status into the equation, as well. If I did it again, though, I'd turn the card opening towards the bottom of the envelope. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Upper memory
At 09:17 PM 1/18/2006 -0800, Caleb9849 wrote: ARG! Can someone please help me with this? I'm trying to run an old DOS Star Trek Game of mine. By DOS standards, it's pretty resource-heavy and requires upper memory. So I added the lines into my fdconfig.sys to load up emm386.exe (with the noems option) and himem.exe . Then, after I boot up, the mem command outputs only conventional memory and my game does not run. Well, what is the MEM output? You should probably use the X=TEST option along with NOEMS to make sure you're not getting unusable UMB areas, too. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] help - how to make freedos bootable disk
At 12:44 AM 12/25/2005 +1100, John Mills wrote: Thanks for info. I'm out of my depth here. Apologies to anyone misled by my suggestion. My EMM386 is version 1.13. Current EMM386 version is 2.08. You're one major release, many minor revisions, and a number of recommended updates behind. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] help - how to make freedos bootable disk
At 12:53 PM 12/24/2005 +1100, John Mills wrote: alan Don't know if your program uses DPMI, but some out of memory problems can be solved by disabling memory drivers e.g. EMM386/HIMEM, and letting DPMI take over extended memory. Nothing to do with a modern, e.g. FreeDOS version, HIMEM or EMM386. If your program pages out with HIMEM or EMM386, you either aren't using a recent version or you have another problem unrelated to the listed URL. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available
At 11:02 PM 11/28/2005 -0800, Blair Campbell wrote: I would personally really appreciate the ASM in FreeDOS HELP being a test case, as this assembler won't even compile with Arrow Assembler or the Watcom Assembler (which both use older MASM/TASM syntax, afaik). The only ASM file I found in FreeDOS HELP was conio.asm. It substantially converted with Nomyso 2.0 as-is. There remained three problem areas: local labels in macros, improper bracketing in certain circumstances, and DGROUP group listing. I fixed the local label in macro situation, and the DGROUP problem. The bracketing was made a bit more robust. In doing so, I discovered an error in the original Nomyso 2.0 for EMM386 which fortunately was minor: the _pause macro which isn't used in normal build had a memory reference error, and the very seldom used SB option code translated one line improperly. Neither problem should affect people who would develop with a translated EMM386, but they're fixed now for next Nomyso. The bracket problem highlighted one of the fundamental reasons you can never fully automate the translation process for all MASM/TASM source files .With the line: _ScreenArea EQU DWord Ptr _ScreenOffset translated to: %DEFINE _ScreenArea DWord [_ScreenOffset] things will still fail under NASM for lines like: les di, _ScreenArea Why? Because NASM won't take a DWORD attribute for a 'les' argument, even though it IS a DWORD being used. In fact, I tried different combinations of DWORD, WORD, NEAR, and FAR, and NASM won't take any of them. I think that's a bug in NASM, but I can't figure out what it really thinks it should take as an attribute, so who knows. The three people following to this point might wonder why Nomyso doesn't just eliminate the 'DWord' in the $DEFINE statement and eliminate the problem. Well, you can't automatically do that because the DWORD would be necessary in some cases where you might use the %define'd _ScreenArea, such as: mov eax,_ScreenArea However, because I am insane, I added the ability to fully automate the conio.asm conversion by adding a -x option to Nomyso, allowing post-processing lines with s// regular expressions. Consequently, with the current (unreleased) Nomyso: ./nomyso/pl -x'/(%define\s+.*\s)dword\s+(.*)/$1$2/i' conio.asm nconio.asm conio.asm is fully translated and NASM ready following the problematic DWord purge by that demented 'x' option. NASM -O99 -f obj nconio.asm is happy. I can't say whether the translated conio.asm actually works along with all its C source, but it does assemble without errors. If you want the latest Nomyso immediately for converting conio.asm, let me know. Otherwise I'm going to wait and see if the ATAPICD translation needs any non-major changes to Nomyso before releasing a new public version. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available
At 01:27 PM 12/3/2005 -0600, I wrote: The three people following to this point might wonder why Nomyso doesn't just eliminate the 'DWord' in the $DEFINE statement and eliminate the problem. Well, you can't automatically do that because the DWORD would be necessary in some cases where you might use the %define'd _ScreenArea, such as: mov eax,_ScreenArea Correction. The 'mov eax,_ScreenArea' instruction would work without the DWORD attribute because the data size is known through the register size. Other instructions such as 'push _ScreenArea' would not work without the DWORD attribute because NASM doesn't know the size of data to push without it. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available
At 07:15 PM 12/1/2005 +, Gerry Hickman wrote: What we do know is this: 2. EMM386 with SCSI controllers and VDS enabled is completely unusable and should never be tried outside the test lab. What? Completely untrue. More like 2. EMM386 with SCSI and VDS works on all tested systems, but unverified reports are that there are problems with some SCSI setups. 3. EMM386 used with SCSI without VDS appears to work, but no one would trust it in a business production environment, but for testing and home PCs it seems fine. Nonsense. I could make the same claim about trusting DOS itself in a business production environment because of its lack of operating system protection. I realize you personally have had some problems with EMM386 that cannot be duplicated elsewhere, but I would appreciate you not posting things these claims. They are inaccurate and needlessly damaging to proper distribution, use, and testing of EMM386 by endusers. By the way, EMM386 can always give a system more upper memory than UMBPCI. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.08/Nomyso 2.0 Available
At 11:02 PM 11/28/2005 -0800, Blair Campbell wrote: Speaking of bugfixes, a person on FreeDOS IRC has mentioned many times that the latest versions of HIMEM/EMM386 won't work with certain hard drives, but will work with others. AFAIR, he also says that NOVDS does nothing to change this. Possibly one of the SCSI drivers, but without a test machine to see what's in conflict, nothing I can do. All the SCSI drive machines I've been able to test with now work with EMM386. Also, I've found some people allow too many memory areas in upper memory and trash BIOS drivers. Either they I= include too much, or X=TEST can't catch quite everything. Best way to determine if upper memory conflict is present is to temporarily X= the entire upper memory range and see if the problems persist or go away. Then narrow down the range which needs to be excluded. BTW, with NASM, does optimizing EMM386 or HIMEM for newer CPUs result in smaller object files? That would be a coding instruction-based optimization, rather than an assembler style based optimization. I don't think there is all that much above a 386 instruction level which would help HIMEM/EMM386, plus you either ruin 386 compatibility or you get into CPU versioning of the programs, which sounds horribly messy. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] EMM386 2.08/Nomyso 2.0 Available
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files emmx208.zip, EMM386/HIMEM mostly executable package (EXEs compressed via mutant UPX), and emms208.zip, EMM386/HIMEM mostly source package. Nomyso version 2.0 was uploaded to ftp://ftp.devoresoftware.com/downloads/nomyso named nomyso20.zip. nomyso is the newly chosen subdirectory for all Nomyso versions. Version 2.08 of EMM386 is strictly a compatibility release to help ease transition for Microsoft EMM386 setups, increasing the number of identical options allowed in both EMM386 versions. Specifically, EMM386 will now accept NOHI and NOMOVEXBDA without complaint, although these two options are no-op's. That is, the two option do not change behavior on the part of FreeDOS EMM386 because it never performs the actions these options inhibit. In addition, MIN=### is accepted as a synonym for the EMM=### option because, since the EMS/XMS pool-sharing feature was implemented, FreeDOS and Microsoft EMM386 act the same for the two options. Also, a few cosmetic source code cleanups were made to EMM386.ASM for better NASM-conversion via Nomyso. Nomyso has grown considerably from version 1.0 to 2.0 and has moved from semi-toy to useful program status. Nomyso version 2.0 converts EMM386.ASM source to assemble under NASM. Although Nomyso will not automatically convert many MASM/TASM programs, it now stands a decent chance of converting significant parts of a lot of the programs out there, depending on their style and complexity. I anticipate that Version 2.08 of EMM386 is the final non-bugfix release I will create (bugfix versions will continue, as necessary). I've done all the new design and enhancements I want to do, or think are necessary. The ability to assemble and test with NASM may expand the pool of potential developers, although any such changes should still be discussed with -- and need be approved by -- the HIMEM/EMM386 maintainer(s). For my part, on the FreeDOS-related front, I will likely continue work on Nomyso. There is even a faint chance I will someday document advanced HIMEM and EMM386 options and behavior, or heck, maybe clean up that really lame Wikipedia Encyclopedia entry for FreeDOS. The few minor source changes made to EMM386.ASM and NASM-specific notes follow: - EMM386 was sloppy with its case in 6-8 source lines, a fact that was masked by TASM ignoring variable case. NASM is case-sensitive and complained. - NASM does not support PUBLIC/GLOBAL declarations after the variable declaration, so two PUBLIC declarations were moved. - One routine labelled 'pause' was a problem because pause is a recently added CPU opcode (who knew?). Also a macro generated labels of INT1 and INT3, which are consider special CPU opcodes. Changes were made to avoid creating labels which matched valid CPU opcodes. - Although limited macro conversion support is present in Nomyso v2.0, passing a hexadecimal value as a beginning value was causing problems and would have required me to extensively rewrite the macro converter to insert multiple lines and %ifnum's for a mere four source lines in EMM386.ASM. So I got lazy and changed the hexadecimal values to decimal values instead. Note that NASM is slightly less efficient than TASM when generating object code so there will be a slight increase in the EMM386 binary size, although the increase was well under 1%. In fact, NASM is better than TASM at one type of optimization, but not enough to overcome other misses. Also note that it turns out that with the more complex EMM386 source, NASM mirrors the past problems with HIMEM for five, six, and seven passes. Only with eight passes, i.e. NASM -O8 -f OBJ EMM386.ASM, does the OBJ generate properly. To forestall future problems with ever more complex programs, I strongly recommend just using -O99, as is commonly found in NASM builds. 99 passes should be enough, and NASM will stop at the last pass which makes no changes, so it's doubtful anything near that many will actually occur. More information on Nomyso is available at www.devoresoftware.com/nomyso . If any of you have suggestions for an open source application written in MASM or TASM which could use an automatic conversion to NASM, let me know and I'll consider making it the test case for Nomyso version 2.5 or 3.0. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] long live hotmail :(
At 08:38 PM 11/24/2005 +0100, you wrote: Anyone else seeing massive virus outbreaks? I never imagined being able to use 40% of a 250MB hotmail emailbox (add 3% each hour), but MS manages to not filter these (75KB attachment). Even the delete junkmail button times out with 1400 emails. Pretty typical virus outbreak pattern. A lot of people besides you are seeing the outbreak, as mentioned in various world news stories. Here's a decent story on it from the Beeb: http://news.bbc.co.uk/1/hi/technology/4466016.stm --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] SBPCI Sound Driver and EMS Memory
At 08:46 PM 11/23/2005 +0800, Johnson Lam wrote: I have a problem with the SBPCI Sound Driver under FreeDOS, could someone help me ? You got the same problem as me, but I'm using SBLIVE. Try to use: device=c:\fdos\bin\emm386.exe memcheck x=test ems=1200 If you are using the latest EMM386 you should not have this problem. If you are using it and you still have this problem, had you reported it, it would have been fixed. Both MEMCHECK and EMM= options should be unnecessary for almost all users. There is no EMS= option. The original poster indicated a desire for more EMS memory available, not less. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] SBPCI Sound Driver and EMS Memory
At 08:25 PM 11/22/2005 +0100, Almacha wrote: I have a problem with the SBPCI Sound Driver under FreeDOS, could someone help me ? When I use the default configuration for HIMEM and EMM386 : DEVICE=C:\FDOS\BIN\HIMEM.EXE DEVICE=C:\FDOS\BIN\EMM386.EXE I have then 32MB of EMS. and then I try to load SBPCI I got the following error : error: Could not allocate code/patch RAM below 4 Mbyte boudary. Try loading Sounds like you might be using an old version EMM386 that needs updating. EMM386 does not allocate extended memory beyond its own requirements until and unless it is needed. If you are loading a driver or program after EMM386 and before SBPCI which uses extended or EMS memory, then you need to change that load order. --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Booting from USB
At 11:29 AM 11/17/2005 -0800, Quentin Liedtke wrote: I'm having a real tough time trying to get FreeDOS to boot from a USB flash drive and I'm hoping that the fine folks on this list might be able to help me. Hardware I'm using: - I'm using an Intel D865GBF motherboard with BIOS version BF86510A.86A.0075.P24 - I've tried booting from a 256MB SanDisk Cruzer Micro and a 128MB Shikatronics Hopefully someone on the list has a working solution for you. If not, I have an alternate proposal you might consider. Basically, I see more general questions off-list about booting FreeDOS and USB sticks than any other single issue nowadays. It appears to remain quite difficult to get a bootable stick working for many computer setups. And besides me, I've only seen a couple of people around mention that they have a FreeDOS-booting USB stick. So here's my offer to anyone on the list with USB stick problems booting FreeDOS: If you mail me the USB stick -- or an exact model duplicate -- that you are having problems with, I'll try to make it work here. If I can (or even if I can't), I'll mail the USB back with the bootable configuration, or whatever the last attempt configuration wound up being which didn't work. After receipt, the first step here will be to save the original bootloader image. I can compare that to the final working image to see what any magic differences might be. Second step is to try, as best I remember, to go through the process I did creating my FreeDOS-booting 256M JumpDrive. Third step, assuming success, is to see what can be done to make the entire process less painful and more likely to work for other people. Four step is to actually document the damn thing this time instead of trying to remember what bumbling about I did to get the USB stick to boot. Standard warnings apply: 1) Just because I can get it to boot here does not mean it will boot there. 2) The attempt could utterly fail, particularly if the USB stick is old or off-brand. 3) Those taking me up on the offer will have to spring for some stamps to mail the stick and obviously won't have it available to use while I work on it. 4) Umm, four, well I dunno, I suppose the mailman could accidentally run his white van over it, smash it into a million pieces, or I could die of sudden onset triple leprosy and have the stick cremated along with my oozing corpse. (I do see that 256M Cruzer's can now be purchased for a mere 30 bucks, but unfortunately between the new USB floppy drive for testing a laptop with EMM386 VDS changes, the TASM upgrade, and the Red Cross thing, my discretionary fund for FreeDOS is approximately 17 cents, at least through early 2006.) --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] New source converter+EMM386 2.07+compression binary
At 10:29 PM 11/15/2005 -0800, Brolin Empey wrote: Michael Devore wrote: And another warning: NASM done got it some bugs. Even with the relatively modest source of HIMEM, I hit a couple. Have you told the NASM maintainers about these issues? I think they would probably be interested in working with you in order to fix the bugs. NASM is the Netwide assembler after all. It is developed by many individuals--many of them volunteers--working together over the internet, not by a large company like Microsoft or Borland. These companies can afford to hire people for quality assurance and testing. After all, their customers expect the product they purchase to work correctly. Customers can report bugs, which can be fixed by the developer's employees. NASM, on the other hand, is a volunteer project. The users must contribute to the product if they are unsatisfied with it. I don't want this to sound like a rant. I just found your message to sound like one from someone who is willing to complain about something but unwilling to do something to solve the problem. Hopefully this is not the case. As I indicated in another message, perhaps in freedos-devel, at least one of the issues had already been posted to a NASM-related forum. Plus, there were questions raised there about whether the developers are processing reports and making fixes. That could be simply be the result of users not getting highest priority attention to their personal bug-fix favorites, or perhaps there is more to it. I did spend a bit of time before I left, prior to posting the latest HIMEM/EMM386 release, digging around the [N]ASM newsgroups/forums/lists to see what was going on with the bugs and whether NASM is actively maintained. I still don't have a firm answer. I know the basics of how open source development works. Or how it frequently doesn't work. I am not lacking in suggestions on how to apportion my time for open source issues and I have invested many days dedicated to open source support -- not just for FreeDOS. Frankly, I've paid the dues. Are you a regular user and supporter of NASM? I am not, nor do I plan to be for the foreseeable future. If you are a NASM user and supporter, you are certainly welcome to visit the appropriate venue and post the issues if they are not repeats. Feel free to query me on further details. Otherwise, I am not overly interested in public opinion pieces on my deficits for not spending another hour or five I did not have making sure NASM developers, who may or may not interested, receive another handful of possibly duplicate bug reports for one of their (apparently) less-popular target platforms. Lastly, I offer this nugget of pure opinion. We can, with clear conscience, gripe about things which irritate us as long as we don't overdo the bitching and moaning bit. Complaining about things which do not work as expected is a fundamental human experience.Humans cannot and should not be expected to fix everything we complain about, even could we sacrifice all our free time to do it. If open source is really a viable replacement for closed source, then it should be able to abide a few random gripes about how it works, just the same as proprietary software does. Perhaps you have seen a few complaints about Microsoft software? --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628alloc_id=16845op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re: New source converter+EMM386 2.07+compression binary
Message Clarification #3. It's the HX DOS Extender, nor HRX. Such are the fruits of staying up all night to get the thing out the door. To make this slightly more useful, here are links to items mentioned in the original message: HX Extender: http://www.japheth.de/HX.html Cygwin site (you can get the CYGWIN1.DLL here to use with HX, as part of the Cygwin package: http://www.cygwin.com/ Perl for DOS binaries (I use the Cygwin or Windows versions, also here): http://www.cpan.org/ports/ If you want to try extending Nomyso for your own source translations, there many Perl resource links here: http://www.perl.org/ --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] Re: New source converter+EMM386 2.07+compression binary
Message clarification #1: The converter file is named nomyso10.zip, not nomyso.zip Message clarification #2: NASM may generate harmless warnings if you recompile other MASM/TASM source code, making complaints about redefinition of segment attributes. Test files show these warnings are triggered by declaring structures inside of segments when the segments have particular attributes. They also appear to be a bug in NASM. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] UPX compression, was FreeDOS Post-1.0 todo list
At 02:27 PM 10/11/2005 -0700, Blair Campbell wrote: bypassed. After three days of on-and-off hacking on it, I built a mutant UPX 1.25 to compress EMM386.EXE and HIMEM.EXE to work both as a device driver and as a stand-alone EXE file. As almost always is the case, the actual changes were small, figuring them out was the hard part. Where is/will this version of UPX be available? Perhaps it could be in the UPX package as a seperate binary exclusively for packing things like HIMEM/EMM386 and TDSK. I could have sworn I answered a post from you on this topic previously. Hmm, yup, I did. Since you are eager for the mutation, I have uploaded a file called mods-upx125-dos.zip in directory ftp.devoresoftware.com/downloads/emm386 which contains the two modified files, p_exe.cpp and l_exe.asm. These changes were used to compress HIMEM and EMM386 with revised UPX 1.25. They have been working properly so far under the new compression scheme. p_exe.cpp was slightly cleaned up and restored original EXE stack settings so as not to upset more delicate constitutions. Only other change was to the UPX makefiles for my own directory setup and tool versions, which obviously would be of no use to anyone else. Naturally, users are solely responsible for the rest of build, including the UCL library. If for some bizarre reason someone wants the UPX mutated binary build I used under Cygwin, I can put that up, but it seems superfluous. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] UPX compression, was FreeDOS Post-1.0 todo list
At 11:25 PM 10/11/2005 +0200, Bernd Blaauw wrote: Markus Oberhumer seems to have his own website and seems quite active. Maybe he's interested in your patch. It's not in a good patch form consistently matching the rest of the source, but rather a basic hack to make things work. Also, it forces the default stack for EXE's, although that could be fixed in a couple of minutes. Doubtful they'd be interested in a patch that wasn't good to insert as-is at the time of submission. Perhaps SY3PACK stub (as your UPX counts as competition) will now become 8086 compatible, or EMM386/HIMEM back to GPL as there are no more issues with the GPL conflicting with a stub from a non-GPL compressor. Tom's explicit choice though, as your significant contributions are mentioned as public domain. GPL is a blight upon the land. Tom's choice of Artistic License 2.0 was an excellent decision, assuming one chooses to open rather than PD source. I like Artistic License sufficiently well that any future open source project I develop which isn't released as public domain will use it. That is, I will unless OSI approves an enticing license which FSF doesn't agree is GPL-compliant, which I will thereby embrace as a raspberry at the FSF . Currently the only OSI-approved licenses FSF says aren't GPL-compliant aren't very attractive to me for development. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] UPX compression, was FreeDOS Post-1.0 todo list
At 12:39 AM 10/11/2005 +0200, Bernd Blaauw wrote: Again a nice theoretic discussion :) Anyway, are FreeDOS related programs and drivers also ment to be used on MSDOS or not as partial replacement? The drivers could be used on MS-DOS freely, it is only the control programs which would extend FreeDOS. So nothing would break MS-DOS, MS-DOS just couldn't do everything FreeDOS does. A happy state of affairs for FreeDOS, actually. However, a lot of the associated 386-level griping may now be bypassed. After three days of on-and-off hacking on it, I built a mutant UPX 1.25 to compress EMM386.EXE and HIMEM.EXE to work both as a device driver and as a stand-alone EXE file. As almost always is the case, the actual changes were small, figuring them out was the hard part. Using the custom mutated UPX will eliminate SY3PACK closed-source issues, including the 80186-level requirements for the [de]compressor (I think that's the SY3PACK minimum CPU opcode req). What will make you sad is that SY3PACK compression actually beats UPX by a few hundred bytes on each of HIMEM and EMM386 files, but file growth is what you'll have to live with to keep the masses happy. SY3PACK winning may be due to the UPX rebuildable open source using the less efficient UCL compression library than the optimal UPX build which uses the closed-source NRV big-brother version. I can't do anything about that, either. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
At 02:36 PM 10/9/2005 +0400, Arkady V.Belousov wrote: And how this should be look? Drivers doesn't return errorlevels, whereas INSTALL= executed after DEVICE=. MD Perhaps you could have it conditional on a register return value from an MD application, Even if I introduce new interface, then it will be useful only for new drivers. It will be useless for all existing drivers. Wrong. It will be useful for _everything_: CONFIG.SYS: ; CHECK386 program returns AL nonzero if 386+ level chip found %IF CHECK386 DEVICE=C:\WHATEVER\PATH\HIMEM.EXE %IF CHECK386 DEVICE=EMM386 ; CHECK286 program returns nonzero if 286-level chip found %IF CHECK286 DEVICE=FDXMS286 ; ISFLASH program detects USB flash driver presence with nonzero return %IF ISFLASH DEVICE=USBASPI.SYS %IF ISFLASH DEVICE=DI1DI.SYS ; ISVIDECD program detects whether CD needs VIDE driver %IF ISVIDECD DEVICE=VIDE-CDD.SYS ; otherwise try another generic driver %IFNOT ISVIDECD DEVICE=OAKCDROM.SYS ; if known broken BIOS fails critical operations, load workaround driver %IF DETFAIL DEVICE=FIXBIOS.SYS The actual %IF and %IFNOT were arbitrarily chosen as the conditional commands, of course. If you want to get fancy, you allow stacking multiple conditionals per line, e.g. %IFNOT CHECK386 %IFNOT CHECK286 DEVICE=lame 8086 memory manager. As long as you're not spreading out conditionals along multiple lines with IF/ELSE/ENDIF -- a behavior which seems much more complicated and nasty to implement -- it could be a simple parse loop added to the original conditional. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
At 11:28 PM 10/10/2005 +0400, Arkady V.Belousov wrote: MD %IF CHECK386 DEVICE=EMM386 Why to duplicate checks, which already present in himem and emm386? Why depend on on drivers to unload cleanly if they fail, which they already do not always do in closed-source drivers, despite protestations to the contrary. Why not allow external load control based on any of a thousand conditions the driver was never and could never have been written to consider? Someday I may also show you a device driver which uses UMBs, disproving the claim that none do. MD ; CHECK286 program returns nonzero if 286-level chip found MD %IF CHECK286 DEVICE=FDXMS286 Isn't fdxms286 checks for 286? It isn't relevant, as it is overly specific for the example and ignores the real issue of conditional processing the example is used for. But if you want an overly specific reply, it won't help that fdxms286 checks for a 286+-level if a 386-level driver is already loaded. MD ; ISFLASH program detects USB flash driver presence with nonzero return MD %IF ISFLASH DEVICE=USBASPI.SYS Who will write isflash.sys driver? Well, let's see, it would be open-source or close-sourced as the author(s) choose. Who will write FreeDOS? Who will write EMM386? Who will write Linux? Nor need ISFLASH be a SYS driver; a COM or EXE would be fine. COM obviously would be easiest to support. Both vide-cdd and oakcdrom are generic IDE drivers and there not need other drivers, if you already use one of them. If they all worked I wouldn't need to use one instead of the other for reliable CD access. Which I do. In mathematical logic terms, that demonstrates a counterexample which falsifies the original statement. PS: No, I not see there useful examples. It is almost impossible that you would fail to see the power of open-source load control of closed-source drivers at boot time, however it is implemented, yet you act deliberately obtuse on the matter. Why, I don't know and don't care, the capability remains a powerful, flexible, and realistic goal. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] re: re: FreeDOS Post-1.0 todo list
At 11:30 PM 10/8/2005 +0400, Arkady V.Belousov wrote: MD We've discussed loading HIMEM at the DOS prompt after CONFIG.SYS processing MD before, too. It's a bad idea that could easily open the floodgates of bug MD reports for people wondering why their drivers aren't loading or working MD properly, and why XMS/EMS memory or HMA/UMBs are missing or MD misbehaving. If himem/emm386 will complain something like 80386 required to run (both at command line and, especially, in config.sys) instead hanging/aborting/misbehaving (as now), this will be much better and prevents floodgates. As the front line guy taking most of the tech support on EMM386 (and HIMEM), I herewith state that you are incorrect. HIMEM delayed loading (not EMM386) might have limited utility for a narrow set of circumstances, but not as a general feature. But until someone else takes over and makes the mistake of thinking that normal delayed loading of low-level memory managers post-DOS shell is a good thing -- and subsequently pays the price for their misunderstanding -- it's not going to happen. If and when it does, I hope I'm not around to see that particular train wreck. MD As far as EMM386, I am not sure one could ever reliably load EMM386 at the MD command prompt post CONFIG.SYS drivers and COMMAND shell, plus a scattering MD of AUTOEXEC TSRs. I am sure I don't want to try. Why not? This will be same, as loading in config.sys without dos=umb. Dynamically under a DOS session forcing a machine from real to V86 mode, directly accessing extended memory handles and configuring memory maps, plus remapping blocks of memory after a bunch of drivers and the kernel has loaded, and probably other issues I forgot, is the same as loading CONFIG.SYS with no dos=umb? A number of device drivers and TSR's might not agree with this assertion, even assuming COMMAND.COM does. And that's not counting the significant number of code rewrites need to make the delayed load process as stable as possible. Did you think that perhaps it's not so simple since nothing at all in the DOS world normally manages memory this way? Alternatively, you, Arkady V.Belousov, could add basic configurability to the kernel code for conditional parsing of CONFIG.SYS. It is an idea which passes the test of rational behavior with an overall increase in OS power for everyone. Plus, it shouldn't be a terribly difficult feature to implement, if kept to reasonable minimum. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
At 03:01 AM 10/9/2005 +0400, Arkady V.Belousov wrote: MD As the front line guy taking most of the tech support on EMM386 (and MD HIMEM), I herewith state that you are incorrect. HIMEM delayed loading I _not_ say about loading HIMEM from command line, I say about CPU detection and preventing load on too old CPUs. Your last message said that aborting EMM386 and HIMEM 80386-check would be much better and prevent a floodgate of errors. It wouldn't; it has nothing to do with delayed loading of the memory managers.. May you explain, where you see there wreck? Difference between loading of XMM (not neccessarilly HIMEM) at config.sys and at command line is that at config.sys, _when DOS=HIGH_ present, DOS reuses HMA after loading We were talking about EMM386. There is an explicit reference to EMM386 in Bernd's message, my reply, your reply, and my reply again. Which difference in forcing protected mode at config.sys stage of _DOS session_ and command line stage of DOS session? It's the difference between forcing virtual 8086 mode on all programs running under DOS, including already loaded device drivers/TSRs, and switching into protected mode for a single program to execute. Plus the rest of the differences I posted. MD directly accessing extended memory handles and configuring memory maps, DOS doesn't access extended memory. HIMEM and EMM386 set up on a clean memory map. It certainly isn't clean after loading device drivers of varying allocations, the DOS shell, and various AUTOEXEC TSRs. MD plus remapping blocks of memory after a bunch of drivers Isn't memory remapped only in UMA, which not used before EMM386? And what prevents to load drivers in config.sys before emm386? Device drivers don't use UMBs? They don't allocate memory outside of the DOS memory map? TSRs neither? Sure, if they were all written for 8086 only. Otherwise, you damn betcha they do. Yes. If dos=umb is missing, then DOS doesn't checks (includes into MCB chain) UMBs, if they appear after loading some driver (emm386, umbpci, etc). Other differences between DOS stages (config.sys or command line) doesn't exist. What do you think just loaded all over real and extended memory with CONFIG.SYS and COMMAND.COM[.EXE] and AUTOEXEC.BAT? Don't understand this sentence, but if you mean why ms-himem and ms-emm386 are .sys, not .exe. then answer is simple - because loading himem and emm386 at command line is less useful (DOS process dos=high and dos=umb only at config.sys). There are no other reasons - and xmsmgr.exe, which loads XMM at command line, proves this. Nonsense. You say XMSMMGR proves that HIMEM and EMM386 are only loaded first for DOS=HIGH and DOS=UMB purposes? There is no logical rigor to that assertion whatsoever. What it proves is that, under some circumstances where you don't have conflicting drivers and applications, you can load a stripped-down extended memory manager at the DOS prompt. That's not a terribly useful capability for most people. And how this should be look? Drivers doesn't return errorlevels, whereas INSTALL= executed after DEVICE=. Perhaps you could have it conditional on a register return value from an application, or on device driver name existence. Why does conditional processing have to depend on errorlevels from existing device drivers which are written to MS-DOS-only level of awareness? For my part, I am done arguing whether HIMEM and EMM386 only are needed in CONFIG.SYS instead of DOS prompt to facilitate DOS=HIGH,UMB handling. I consider the presence of other major differences self-evident given any serious attention to the details. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] emm386 on 286 (was: FreeDOS Post-1.0 todo list)
At 04:46 AM 10/7/2005 +0200, Eric Auer wrote: The test already is performed inside the driver, and cannot be performed in an errorlevel-generating tool. Because errorlevels are not used in context of DEVICE=... loading. The autoconfigure would look like this: DEVICE=HIMEM... DEVICE=FDXMS286... DEVICE=EMM386... Seriously, you think that stacking up duplicate drivers and expecting them to all fail gracefully in line with the current CPU is a good way to handle the default boot process? You want to depend on a solid but harmless fail condition to make things work every time? I'm not much of one to volunteer people into more kernel work, but for cripes sake, if you're doing to do any conditional configurations at boot-time on the CONFIG.SYS, _that_ is where it belongs. IF application/driver and IFNOT application/driver conditionals would do the trick. It's not like CONFIG.SYS processing hasn't already been extended for FreeDOS a lot more than that already. Or possibly easier...have the boot loader/new installation optionally able to launch an appropriate CONFIG conditionally based on the detected CPU. Start with a CONFIG.386 -- and for the benighted few a CONFIG.86 and CONFIG.286 -- whichever one is correct gets brought in during installation and renamed to everybody's favorite CONFIG.SYS at the end of install. Just think, with conditional CONFIG.SYS processing, you could even expand flexibility to dynamically bypass known problem -- or include required -- driver configurations with SCSI drives, flash drives, goofball BIOSs, etc. Consequently you might become a world-wide marvel, millions possibly singing hosannas to your name, and you could be more popular than Linus (not Torvalds or Pauling, of course, I mean Linus Scudwomper who inflates balloons and female dolls for a living in Trenton, New Jersey, but still...). --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] re: re: FreeDOS Post-1.0 todo list
At 11:13 PM 10/4/2005 +0200, Eric Auer wrote: various statements which would be unproductive to rehash my disagreements with and The errorlevel thing would also have the problem that EMM386 and HIMEM are device drivers. You cannot do if errorlevel ... in config sys, so the suggested solution is ruled out. Let us avoid the sillier debates. You cannot simultaneously argue that EMM386 may use a 386-level test to help configure loading at boot time, yet a separate program cannot legitimately perform the same test. The nature of EMM386 and HIMEM precludes loading them at a subsequent DOS prompt. Either you can auto-configure at boot based on a 386-level test or you cannot. Whether the tests are performed inside or outside a particular device driver is irrelevant. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] FreeDOS Post-1.0 todo list
At 11:19 PM 10/3/2005 -0700, Blair Campbell wrote: Hi. Just wanted to let everyone know that I've copied the Post-1.0 todo list to the FreeDOS wiki so that everyone can view and edit the list of items. It is available at: http://wiki.fdos.org/Main/Post_1_0_Todo No way I can see to discuss a page so that I can record a comment, for example, that notes most of the remaining EMM386 option to-do list is unnecessary, superseded, or no longer applicable. Not appropriate to just yank them out of there unilaterally. And pretty much the same with HIMEM. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] re: FreeDOS Post-1.0 todo list
At 01:11 PM 10/4/2005 +0200, Eric Auer wrote: soon please - would be nice to have that soon after FreeDOS 1.0, e.g. before 2.0, for example: several EMM386 / HIMEM features aka, none. EMM386 is quite deliberately versioned at 2.x because it's moved beyond what is needed and necessary for a FreeDOS 1.0+ release. Only thing EMM386 needs is better compatibility with SCSI, but I can't help there since it works on all the machines I've been able to test. Most people with SCSI-compatibility problems either do not report it or cannot not work on debugging it, so the issue isn't moving forward. That is the one thing which really needs a soon flag. In a small fraction of the time that has been spent complaining in various venues about 286-level failure (an extremely minor problem if you agree it is one at all and I don't) , it would probably take about 20 minutes for you to write a (very) small program which notified the type of CPU as an return code or error-level, e.g. 0 for 8086, 1 for 80186, 2 for 80286, 3 for 80386, et cetera as necessary. Far more useful and flexible for everyone without the need to bulk up the size of individual utilities. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.05 update, recommended for all
At 04:42 PM 9/21/2005 -0700, Brolin Empey wrote: FastTracker 2.08 runs fine for me under latest HIMEM and EMM386. PKUNZIP failing unless the NOEMS option is specified, now that's a problem I'm working on. EMM386 v2.05 breaks my FDCONFIG.SYS! When booting, I get the following output: FreeDOS HIMEM64 3.11... HIMEM - KBC A20 method used EMM386 2.05... CONFIG.SYS* error in line 26** 12?DEVICEhigh=C:\FDOS\bin\vide-cdd.sys /D:vide EMM386 isn't involved in parsing CONFIG.SYS at all, but you can try the emmflesh.zip update if you want to see about the latest. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.05 update, recommended for all
At 05:48 PM 9/21/2005 -0700, Blair Campbell wrote: it sounds like VDS again to me. That has the effect that no I think that it'd be really nice to have a utility to detect the instances where VDS would fail because then distros like mine can add the NOVDS option in the installed config.sys and a user could save much trouble by not having to boot without EMM386 and edit config.sys. If I could detect when VDS would fail, I could make it not do so, with a high likelihood of success, depending on severity of the conflict. HOW to detect when VDS is in conflict is the $64,000 question. Without MS-style resources to acquire 100's of different test machines, we're kind of stuck. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.05 update, recommended for all
At 11:21 PM 9/19/2005 +0100, you wrote: A better option would be to get to the bottom of why SCSI and VDS do not like each other. SCSI is a drive interface - I don't see how it can be affected by VDS unless there's something bigger going on. It may he SCSI is merely showing up the problem, as opposed to BEING the problem? Nope, there are documented instances of SCSI drivers being incompatible with VDS. In those cases, they share the same interrupt and potentially the same register values which VDS uses to determine its functions and what to do. Obviously if SCSI wants to read a disk sector and VDS thinks you want to check for contiguous memory amounts, something is going to wind up very unhappy. Is that what the problem is with your SCSI setup(s)? Can't say, good chance it's a failure elsewhere, or it could be the fundamental failure described above. If you want me to get to the bottom of your particular VDS failure, then you or someone else will need to send me a machine that demonstrates the problem, same as Mark Bailey did with his laptop. Otherwise, it's all conjecture here. the amount up to $60.00 and made the contribution on August 9, specified for where it was most needed with the title 'FreeDOS'. Confirmation e-mail available on request. Very nice, but I don't get it? You are spending hours developing this excellent Free software, and then paying out to charities based on it's popularity?? I was interested in knowing how many people overall, more or less, downloaded from my site for FreeDOS. The contribution served three purposes: 1) it motivated interested people to download the latest rather than wait for release+n like people tend to do; 2) it gave me a better baseline against people who solely hit the site to download files simply because they are there (BBS'ers used to call them file-rapers); and 3) it made a little money for a universally helpful charity that could use it. Oh, 3.5) I was bored and it was a mild diversion. And, 3.75) It gave me an excuse to start working with Perl and Cygwin-based utils a bit more to process the results, instead of coding something up in C/C++ overkill as I typically have done. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 2.05 update, recommended for all
At 05:05 PM 9/19/2005 -0700, Brolin wrote: Firstly, I have not tested this new release. That said, what is the status with regards to having FastTracker II working on FreeDOS? My FreeDOS installation consists mainly of what was distributed with the Beta9 SR1 CD, so some of the components may be fairly old. If you're asking me personally, I don't have a clue. If you're asking the list, hopefully someone will have the answer. Should FastTracker work without EMM386 loaded and NOT work with EMM386 loaded as the ONLY difference, it may be a compatibility problem with EMM386, otherwise not very likely to be related to it. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] EMM386 2.05 update, recommended for all
Uploaded to ftp://ftp.devoresoftware.com/downloads/emm386 are the files emmx205.zip, EMM386/HIMEM mostly executable package, and emms205.zip, EMM386/HIMEM mostly source package. This version of EMM386 has a number of compatibility changes to enhance operability with a variety of DOS applications and environments without the need for advanced option tweaking. As a result of the seven changes to EMM386 and two changes to HIMEM, this is a recommended released. Briefly, besides various fixes and compatibility modifications, the VDS option now defaults to on, with a new NOVDS option to turn it off (NOVDS possibly required for some SCSI disk drivers); the XMS memory manager supports growing memory blocks on resize for the Graphics Vision text editor; and a limited MEMCHECK default of 3-4G is present for MMIO-based devices such as USBASPI.SYS, with the ability to turn it all off by use of the new NOCHECK option. Particulars ponderously proceed post-paragraph: The HMAMIN setting of HIMEM never up-converted its K setting to actual bytes as required internally, plus it allowed 64K instead of a maximum of 63K. Bad HMAMIN, bad boy. Fixed. The NOVCPI option was blocking allocation of UMBs. This was overly aggressive, even for a severe option like NOVCPI, and it was chastised back to proper behavior. Regardless of that whoopsie, friends don't let friends use NOVCPI, as it is almost never a good idea. Unless you know exactly why you are using NOVCPI, don't. There was an error when parsing EMS, such that an EMS page frame was marked present even if there was insufficient upper memory (i.e. no 64K contiguous block) to place it properly. The problem would not be present if you specified NOEMS and even without NOEMS it would not cause misbehavior unless you used an application which depended on EMS and a page frame. Admittedly, it was an error with a nasty bite, but one had to wander far into the hinterlands of nontypical environments to get bitten. Such is how developers rationalize away crippling guilt. And minor bugs. The EMM386 driver saves the full 32-bit part of all general registers it uses, as well as segment registers. This may or may not clear up problems with 386-optimized kernels. I can't test. It consumes an additional 22 bytes of stack, which I'm thinking probably shouldn't be a problem. Of course, I used to think an incompetent buffoon probably wouldn't make a second term as President, and now look what the USA is stuck with, so counting on me to tell you whether a particular kernel version is safe seems chancy. HIMEM's XMS API supports growing a block on resize; previously only shrinking was supported. Sufficient contiguous memory must be available to simultaneously hold the old block and the new block or else it will fail. This feature was added because the Graphics Vision text editor did not gracefully handle a failed XMS growing resize, although resizing is never guaranteed. I don't know whether it's a bound-in extender fault or an application fault, but something is acting goofy in there and we're stuck writing the work-around for it. Not that I feel crabby about it. EMM386's VDS option had a bug in the scatter/gather function and made various setups, such as Bernd's VMWare and Mark Bailey's laptop, cry in grief and frustration at the unfairness of it all. The evil error was corrected to help better balance Universal Justice towards the Good Guys. While on the topics of VDS, the VDS option is now on by default. Too many environments require this to leave it as optional, plus a default on condition matches Microsoft EMM386. There exist SCSI setups which will REQUIRE you to turn off VDS support via the new NOVDS option. Unfortunately for those SCSI-ites, the people who need VDS outnumber the people who need to not have VDS, so they lost out. Or maybe the people who need VDS just yell louder. Ahh well, same difference to me. I like quiet. EMM386 internally defaults its MAX setting to 256M, so that unless you explicitly specify a MAX= setting more than 256M, available VCPI will not exceed this amount. This change was made solely to accommodate the DOS/32A extender complaining when large amounts of free VCPI memory are available. Applications which used the extender would fail with a fatal error in such cases, including MPXPLAY -- an otherwise extremely impressive DOS program that deserves major kudos. It appears that DOS/32A is dumb as a leaf of lettuce about the whole lots of VCPI available thing, which kind of sours me on those rabid endorsements of it. The final change is to ensure better compatibility with device drivers that use MMIO (memory-mapped I/O) to high addresses outside of normal RAM, such as USBASPI.SYS. Previously, the MEMCHECK option was required. EMM386 now defaults to operating as if MEMCHECK was present IF the source or destination address range starts (not ends) within the
Re[2]: [Freedos-user] Where is my 1mb of xms memory?
At 04:38 PM 8/10/2005 +0200, up wrote: Looks like you're not using the latest HIMEM and EMM386, which might make a difference. Without the EMS report on MEM, I can't tell what the EMS allocation is, either. I don't need EMS at all. Only good thing from emm386 is ability to load some tsr's into upper memory. Doesn't matter. VCPI is reported through EMS. After himem/emm386 update to this version http://freedos.sourceforge.net/cgi-bin/freedos-lsm.cgi?q=fa=base/emm386.lsm xms consumption by emm386 dropped to 330kb. But ufo2 crashes like before (with NOVCPI flag). Don't use NOVCPI; it's incompatible with any application using a DOS extender and is only for very specific circumstances. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] EMM386 VDS test fix, works with HP Pavilion
At 01:46 PM 8/7/2005 +0100, Gerry Hickman wrote: I then rebooted without VDS and everything worked correctly. I then rebooted with VDS again, and everything was messed up. Thing is, I have no idea what VDS is for, and don't know if I'd ever need it! When VDS becomes a default option, either the SCSI incompatibility needs to be worked around (possibly by a special SCSI detection sequence), or else you will need to turn off VDS through a NOVDS option. Theoretically, a SCSI drive could need VDS support to run drivers in which are loaded in upper memory, although I'm not sure SCSI can always peacefully co-exist with EMM386. It's famously incompatible with MS EMM386 in certain situations. Consequently, it would be nice to get your SCSI-based machines -- and any others with problems -- working with VDS option present, if possible. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
[Freedos-user] EMM386 VDS test fix, works with HP Pavilion
Okay, if you've been following the VDS bouncing ball, be aware there is now a new EMM386 test release, called emmchimp.zip at ftp.devoresoftware.com/downloads/emm386 which does fix the problem using the VDS option of EMM386 on the original problematic HP Pavilion laptop. How do I know? Because Mark Bailey sent the unhappy machine for testing here, which arrived today. I subsequently found a bug in the VDS scatter/gather lock function (8105h) which causes failure if the passed address to be processed is not aligned on a 4K boundary. I would like anyone who has had a problem with VDS -- judging by feedback that being Gerry Hickman, Bernd, and untold legions of lurkers -- to try this version of EMM386 and see if VDS works for them. If we're all astoundingly lucky, this test release fixes everything. If not, you need to tell me. In fact, you really need to tell me either way. I unilaterally crown Mark Bailey as FreeDOS User Of The Month for shipping a nice laptop to some crusty bastard he doesn't even know and trusting me to actually send it back. In fact, I feel so big-hearted and benevolent about the whole thing I won't be invoicing FreeDOS International Incorporated for the $40 USB floppy drive I purchased since the damn laptop BIOS didn't have an option to boot from my FreeDOS flash stick. Oh yeah, like last three times, as an unofficial release this means no visible version changes, no EXE compression, no redistribution as an official-type release, no fooling. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS
At 01:08 AM 7/31/2005 +0100, Gerry Hickman wrote: Oh good grief. EMM386 doesn't have the code or capability to mess with disk partitions. Period. But if drive geometry is being misreported or misunderstood under EMM386 with VDS (which appears to be the case), then my guess is that it would be dangerous to run any kind of disk tool while the system is in that state? Even writing a file to a disk could cause corruption. In the same way that a keyboard driver could be dangerous to run with a disk tool if there were a bug in it, or if it caused a normally hidden bug in the disk tool to activate. DOS system code is wide open to corruption from any driver or application, a situation generally regarded as one of its biggest faults. Without a system which displays the symptoms -- which I don't have -- it's almost impossible for me to say what's going on. Likeliest candidate for causing the problem is that there is still a conflict with some SCSI interfaces and an active VDS (4bh) interrupt. We know that at least one SCSI spec directly conflicted with VDS. However, other candidates cannot be ruled out, or even marginalized. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
At 03:38 AM 7/30/2005 +, Mark Bailey wrote: I see no difference at all with that version, either with the development kernel/command.com or the stable kernel/ command.com. Specifically, with device=a:\himem.exe device=a:\emm386.exe x=test memcheck vds vol c: hangs. Remove vds, it works normally. (development) Alright, one more time. I rewrote the VDS routines such that any reserved function which was unused (0, 1, 0dh-0ffh) no longer returns an error code, but simply sets carry flag and chains to old INT 4bh handler. That may get around a SCSI conflict. Or not. In addition, I cleaned up slightly naughty code which re-enabled interrupts when returning from the VDS call. Theoretically, the VDS interrupt might have been called with hardware interrupts disabled for good reason. Will these revisions change anything? Don't know, but it's the best I can do without a misbehaving machine here to test. Hopefully no new error was introduced. Those with VDS-unhappy machines will need to try it out and report back results. To test this version of EMM386, amble over to ftp.devoresoftware.com\downloads\emm386 and download emmhorse.zip. As before, unofficial release, no exterior version change, no EXE compression. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
At 04:05 AM 7/30/2005 +, Mark wrote: Hi Michael: Well, the E000 message is repeatable on this box... Found that problem. A matter of the EMS routines not properly reporting failure to locate a suitable page frame. Instead they fell through and reported the default page frame. I suppose that would have caused program failure if you didn't specify NOEMS option, didn't have enough room for the EMS page frame, AND the program actually tried using EMS. Anyway, it's fixed now, with better feedback on failure to locate a page frame when NOEMS and FRAME=NONE options are not specified. If you want to try this test version of EMM386, Go to ftp.devoresoftware.com\downloads\emm386 and download emmcow.zip. It should fix your page frame feedback problem. Very much doubt it affects your VDS situation, but you can give it a shot. Interesting thing, though. I could only get the message here if I first booted into Win XP, then rebooted into my FreeDOS flash stick through Windows restart. Apparently, the X=TEST option found garbage bytes at segments E000 - EF00 in those circumstances, so it excluded that entire range. Wouldn't happen on subsequent reboots direct with the FreeDOS flash stick OR powering down and up into the flash stick. Only rebooting from within XP. And that's a good reason why X=TEST probably shouldn't be a default option. Under reproducible conditions on my computer, it can exclude an entire 64K range of upper memory that is available. There is no way to automatically detect that the range shouldn't be excluded, because the bytes are nonrepeated and look like they actually have a purpose. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
At 04:05 AM 7/30/2005 +, Mark wrote: Well, the E000 message is repeatable on this box... Thanks again for all of your help! Well, we can check if your VDS vector is okay pretty easily. Try this with the test EMM386 using VDS option. Don't type VOL first to crash things or load UDMA. After bootup, type debug to run DEBUG.EXE. At debug prompt, type d 0:12c and press enter. There will be a display of 2-digit hex numbers, the first line lists four of them. Probably the first two will be 45 01. Whatever they are, type them in as U 43:21. So if the four numbers are 45 01 21 03, type U 0321:0145 and press enter. You should see a assembly language listing starting with CMP AH,81 followed by JZ 0181. Take the 0181, or whatever it is, and type U 0321:0181 (replacing 0321 with the number you typed for first U and 0181 with the number after JZ), then press enter. You should see OR AL,AL, then JZ 014A. If you don't see that let me know. If you do see that, then your basic VDS re-vectoring is fine. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
At 09:32 PM 7/30/2005 +0200, Bernd Blaauw wrote: 1) harddisk present, but unpartitioned and not formatted d 0:12C U 0307:0145 U 0307:0180 output: MOV BYTE PTR CS:[0084],00 CMP AL,02 JZ 01E1 You're not using test EMM386 is what that indicates. No test for AL equal to zero, as was added. The rest is correct for last 2.04 EMM386 release. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] BIOS, SCSI, 8Gb and TUNS
At 08:23 PM 7/30/2005 +0100, Gerry Hickman wrote: Ah, yes, ... :-) Try emm386 without the VDS argument and under no circumstances run FreeDOS FDISK unless you want to risk an erased partition table. Can you clarify; when your partition table became damaged, were you running EMM386 at the time, and have you tried it without? Maybe you already answered this. Oh good grief. EMM386 doesn't have the code or capability to mess with disk partitions. Period. FDISK was broken in its default behaviors, which allowed a simple problem to escalate to meltdown. This was documented and verified, and is being fixed by another FreeDOS developer. Enough of this sort of thing. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
At 10:13 AM 7/29/2005 +, Mark Bailey wrote: This appears to be the same bug that caused FDISK to wipe out the MBR, so it at least appears that just initializing the VDS functions is trashing something in memory. No such thing. VDS functions just are, they don't initialize. Only thing that VDS actively changes is that INT 4Bh is revectored and a bit is set at 40:7bh. Ha! That's it. Some SCSI BIOS uses INT 4BH. It must be passing the register value that VDS interprets as a VDS function, which means AH = 81h. Hmm, let me look things over to see if there's a way to resolve the conflict by further determining the difference or if it's inherently incompatible. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
At 12:42 PM 7/29/2005 -0500, I wrote: Ha! That's it. Some SCSI BIOS uses INT 4BH. It must be passing the register value that VDS interprets as a VDS function, which means AH = 81h. Hmm, let me look things over to see if there's a way to resolve the conflict by further determining the difference or if it's inherently incompatible. Okay, this looks like the smoking gun. Now to figure out a workaround: INT 4B - Common Access Method SCSI interface (draft revision 1.9) ES:DI - CAM Control Block (see #03229 at INT 4F/AX=8100h) InstallCheck: test for the string SCSI_CAM eight bytes past the INT 4Bh handler Notes: the CAM committee moved the interface to INT 4F after revision 1.9 to avoid conflicting with the IBM SCSI interface and the Virtual DMA specification the only driver to date reported to use the CAM interface on INT 4B instead of INT 4F is from Future Domain (which has drivers for CAM on either interrupt) INT 4F - Common Access Method SCSI interface rev 2.3 - SEND CCB TO XPT/SIM AX = 8100h ES:BX - CAM Control Block (CCB) (see #03229) Return: AH = status 00h successful 01h invalid CCB address (h:h) Note: the SCSI Interface Module (SIM) may complete the requested function --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
At 02:58 PM 7/29/2005 -0400, Mark wrote: Does this provide a means of easily identifying the affected machines? How do I check the Haunted HP Pavilion? :-) Here's what to do: Go to ftp.devoresoftware.com/downloads/emm386 and download EMMBLORT.ZIP. Try that version of EMM386.EXE with your machine using VDS. I changed EMM386 to not report an error with function 0 on a VDS call. It's normally reserved and gives a VDS error condition, now it just chains it through with the carry flag set. Hopefully that won't upset things. Let me know if that fixes or modifies the current behavior with VDS parameter. (Oh yeah, lest it not be obvious, EMMBLORT is not an official release of EMM386. It is for testing purposes only.) --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
At 10:05 PM 7/29/2005 +0200, Bernd Blaauw wrote: Michael Devore schreef: Go to ftp.devoresoftware.com/downloads/emm386 and download Let me know if that fixes or modifies the current behavior with VDS parameter. no change in VMware Workstation 4.5.2 (PC emulator, Intel P4 processor) booting from BIOS directly to harddisk. Different issue entirely. Don't know what's going on in VMware, it may just not like VDS. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
At 03:07 AM 7/30/2005 +, Mark Bailey wrote: VOL C: works normally. Without device=a:\udma2.sys, vol c: hangs and forces a reboot. (That's the old behavior which I checked to make sure of the test case). This does not appear to be a seperate issue. Actually it muddies the waters by introducing another low-level driver into the test mix. I really need feedback on the test EMM386 without UDMA2 or something else in there. Basic clean room testing approach before expanding the universe. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] VOL Command hangs HP Pavilion with EMM386
At 11:53 PM 7/28/2005 +, Mark wrote: Do I need VDS? :-) What does it do? How can I help identify the problem? I do have the Haunted HP Pavilion (TM)! Turn it off if everything works without it. It's just for upper memory reporting of true physical address instead of logical address for DMA purposes. Maybe something is trying to use a function that isn't supported or ignoring a return code that a sub-function is not supported. You don't see any feedback messages when it's present do you? VDS will write to display a line about unsupported functions, but can't help if a program tries to use a subfunction that returns an unsupported code. Without the machine that croaks, though, not much chance I can tell you what's going on with the VDS problem. Could be the fault of either VDS support, or what's trying to use VDS. And no way of knowing here what or how to fix/work around it. I was going to make VDS a default, maybe I shouldn't. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
