Turns out that BRUN45 expects int 21h, function 4Ah, to return the resized segment (the entry ES value) in AX on successful return. FreeDOS, naturally, leaves AX values to their entry value upon success.
This behavior is not documented in RBIL or MS-DOS Encyclopedia. However, I ran a simple test program under the Win2K DOS box and AX does change to the ES/resize segment after the INT 21h function 4Ah call. Then I forced the AX value to ES/segment value under the debugger and Solitaire Suite started up.
The consequence of BRUN45 depending on AX holding a resized segment can cause it to load programs at invalid segment addresses with the expected poor results. Occasionally it even works.
This may affect a fairly large number of programs. It certainly affects Solitaire Suite.
I suppose this post should go to kernel list, as well, but I did that recently for the 32RTM bug and don't want to annoy the thrifty bandwidth-savers by overdoing it. Besides, is there anybody who reads kernel who doesn't read devel?
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
