At 03:50 PM 8/8/2006 +0200, Japheth wrote: >And I disabled this feature temporarily not because of speed reasons, but >because there are situations thinkable where this "feature" may cause a crash. > >Such situations may be rare and almost impossible if DOS is loaded in the >HMA, >but they exist. So if one prefers to use LOADFIX to load any of these old >programs and OTOH wants to avoid event the slightest danger caused by A20 >issues, it would be good to make this feature "optional".
If you mean "optional" in that there should an option added (post-1.0) to control A20 for potentially complex machinations (e.g. directly accessing DOS structures at a time where HMA is mapped out), then most should agree that an A20 handler inhibit option should be on the to-do list. If you mean "optional" in that A20 control should not be default behavior, I think the evidence is strong the other way. EXEPACK and PKLITE issues aren't too uncommon, so a number of new FreeDOS users will have failures in applications with those compression techniques -- reports are already present with the relatively small beta version FreeDOS user base. That does and will place a load on the minimal FreeDOS support system to have the users properly report a problem (most won't) and either use LOADFIX or modify the CONFIG to turn on an option (few will). The "try once and bail if fail" approach is something I've already seen in some user comments across the web and Usenet. We don't have to like it, but we do have to accept it as human nature. Unfortunately, introducing a DOS in 2006, far different from DOS's heyday, means FreeDOS should address common problems automatically, even should that behavior deviate from the exact original behavior of DOS or its support files. Naturally, less common problems should still be fixed by use of nondefault options, when possible. On a related philosophical note, it appears that an optimization in your posted code can perhaps cause fatal errors in VCPI clients using a 16-bit stack on calls to the host. If true, this reinforces the idea that, while optimizations are great for personal code, they probably aren't a good idea for full distributions without a chance for extended user base testing as a "burn-in" period. Deadlines are too tight right now to accept optimizations with potential side-effects, even if they appear harmless. And sadly, it appears that while DOOM works in VPC and Qemu, Stargunner remains problematic in virtual environments, though works here in real DOS. Given that the best protected mode debugger, 386SWAT, is fatally incompatible with my FreeDOS development machine, I'm afraid that leaves me learning GDB usage under Qemu. And I almost certainly won't become sufficiently proficient with it in the short amount of time left to figure out what's going behind the scenes of Stargunner code to correct or work around the issue. Time shall soon tell. ------------------------------------------------------------------------- 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=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
