more

NOTES/GWBASIC/You cannot SHELL to basic.txt

@@ -24,3 +24,37 @@ SM 0:50F 0
 and hit enter. Resume emulation and BASIC/GWBASIC should then
 run without complaint.
 
+-------------------------------------------------------------------
+
+Update:
+
+The reason that GWBASIC has this problem appears to center around
+some boot-time code in MS-DOS. At some point, the first sector of
+the root directory is loaded to 0000:0500. MS-DOS leaves it there
+after booting, where it is visible to any DOS program after boot.
+
+GWBASIC uses byte value at 0000:050F to determine running.
+
+So how is it able to run? Well, if 0000:0500 is a copy of the root
+directory, then 050F is the 15th byte of the first directory entry.
+
+In the original FAT filesystem design, bytes 14 and 15 were not used.
+When MS-DOS prior to version 7 creates a directory entry, those
+bytes are zero. On a bootable MS-DOS system, 0000:050F points to the
+first directory entry byte offset 15 which is normally IO.SYS and
+those bytes are zero.
+
+Starting with MS-DOS 7.0 (Windows 95), Microsoft defined bytes 14
+and 15 to carry the file creation time stamp. If IO.SYS has those
+bytes set, and Windows 95 does not clear that area, then GWBASIC
+will fail the same way.
+
+The HDD images generated by my script were made using the Linux
+mtools, which support long filenames and will set the file creation
+timestamp as well. Therefore, files added by mtools (including the
+IO.SYS file) will have nonzero bytes 14 and 15 and GWBASIC will
+refuse to run.
+
+The solution is for the script to zero those bytes after using
+mtools to add IO.SYS, and GWBASIC will run.
+