At 09:02 PM 7/26/2006 +0200, tom ehlert wrote: > > Well, heck, if I already to have to change some A20 behavior to get a few > > ancient programs to work with that idiotic EXEPACK 0FFFFh address-wrapping > > (assuming EXEPACK makes A20 calls), >*VERY* early PKLITE (~1992) versions had the same bug > >AFAIK, it doesn't - it's older then the invention of HMA > >but it's decompression code is based on the assumption that > > [cs:100] >is equivalent to > [cs-f00:100+f000] > >(don't ask why, I didn't write it) > >this is true if > the code is loaded above 1000:0 (that's what LOADFIX > does) > A20 is disabled > >in fact, this shouldn't happen in freedos; exactly for this reason >the kernel disables A20 before beginning execution of any program, so >that the (potential) startup code gets executed with A20 disabled, and >gets only enabled with the first Int 21 > >of course this might have been 'optimized' in newer kernels ;)
You are right again. Eric indicated I need to allow local A20 control, but as it turns out, that won't help. EXEPACK code simply doesn't call A20 routines, so EMM386 cannot fix this problem. It never "sees" the wrap occurring. The situation has to be corrected within the kernel. So how do we agitate to restore the kernel to its original behavior? I've got a couple test program here someone provided me which consistently failed due to EXEPACK. At a guess, there are plenty more. I suppose we could tell users to run the program from DEBUG which eats up just enough memory that the programs work, but doesn't seem like an elegant solution. (Anybody with the 'packed file corrupt' problem, type 'debug full_program_name', then press 'G' and hit return). ------------------------------------------------------------------------- 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.php&p=sourceforge&CID=DEVDEV _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
