files created after 20120731 seem to fail acc. wiki

[roelandjansen]

according to https://en.wikipedia.org/wiki/PC-MOS/386

"t appears there is a year 2000 like issue in this product, only happening on 31 July 2012 rather than the year 2000. Files created on the system after this time will no longer work."

This may need some testing and checks. Maybe issue #1 is also related.

[andrewbird]

Installation from 1_MOS5userSystemSN0530041410.zip fails if the system date is current. It seems that hdsetup can't read a file it created earlier. Deleting the file it complains about, setting the clock back (I used 1993), and restarting install allows installation to proceed.

[the-grue]

I have been looking into this particular bug and have made some interesting (though not necessarily related to the problem) observations:

1. 2099 - 1980 = 119 years
2. 1/1/1980 - 7/31/2012 = 11900 days or 1700 weeks
3. 2012 - 1980 = 32 years (rollover to bit position 6)
4. August = 8th month (rollover to bit position 4)

Item 1 is standard DOS, so I don't see that as particularly problematic, though the coincidence of item 2 being 100 x item 1 is interesting. I just put in the 1700 weeks because the date converter offered that up along with 285600 hours.

I don't think 3 alone causes any problems, or it would have started having issues on 1/1/2012. Item 4 may or may not be of interest, but I am not ruling it out.

Of course, I expect it is something different completely, or I would have come across the smoking gun already.

I wrote some simple MOS programs and using a FAT reader I wrote years ago on Linux I can see that starting on 8/1/2012 writes to the directories seems to mess up the directory entries and FAT cluster pointers. You can see the files in a directory listing, you can delete the file, but if you try to open the file it returns "file not found".

@andrewbird to get around the date issue in the installation, I just added "date 08-24-1995" as the first line of autoexec.bat. (Date chosen as a bit of a joke.)

[andrewbird]

@the-grue I see you are working on the date problem. I fixed a (maybe) similar thing in dosemu's fat image creation dosemu2/dosemu2#759 where the dates after 2012 rolled over to 1980 because the 7 bit year field was assumed to be 5 bits wide. I started looking at PC-MOS for something similar, but I'm having trouble creating a bootable $$mos.sys, have you managed to boot a PC or Dosemu with a newly built $$mos.sys?

The PCMOS386-9-user.img in IMAGES boots from floppy. Then I built the kernel $$MOS.SYS from source, copied it to floppy, and now it's only the 60 minute demo version. Still boots though.

I floppy booted into MOS with a 1980 date, created a short file "echo abc>z.txt", booted back into DOS 6.22, read the file, all good. Repeated the procedure with a 2019 date, DOS 6..22 can read it, but the contents are garbage. SCANDISK does not complain though, so there is no FAT corruption that SCANDISK understands. There may be some, but SCANDISK knows nothing about it.

I'll have to try looking at the raw bytes with a disk editor.

[andrewbird]

@src153 Thanks for the confirmation that build works. I realised I'd forgotten to fix the timestamp on it before testing.
Incidentally the problem is in the readpath too. I copied a file on disk outside of MOS, touched it to get the current date, and it's unreadable by MOS.

[C:\]dir old*.*
 
FILENAME.EXT       SIZE  ----UPDATED---- ATTRB CLS USER  ----CREATED----
 
OLDCMD  .BAT        180   4-07-95   9:13
OLDCMD  .NEW        180   1-16-19  19:19
 
DISKID  DXXXXS MOS          360 BYTES     2 FILES     8,843,264 BYTES REMAINING
 
[C:\]type oldcmd.bat
COPY C:\PCMOS\$$SHELL.OLD C:\$$SHELL.SYS
COPY C:\PCMOS\COMMAND.OLD C:\COMMAND.COM
COPY C:\PCMOS\$$SHELL.OLD C:\PCMOS\$$SHELL.SYS
COPY C:\PCMOS\COMMAND.OLD C:\PCMOS\COMMAND.COM
 
[C:\]type oldcmd.new
Cannot find file

[the-grue]

Yeah, I have been down that path already and I am currently looking into the int 38h/int d4h and how MOS stores the user and class information on disk. Based on what I see of the data structures, they may have used a formerly reserved section of the directory entry to store this information (10 bytes between attribute and update time). Later versions of DOS use this area for creation time/date, last access date, etc.

I believe the file unreadability may have something to do with the class entry and the security features, but I haven't gotten a good enough understanding yet of how all that works. Or why it would suddenly start on 8/1/2012.

You'll notice the problem when you see garbage under the CLS and USER fields in a directory listing under MOS for files created after 8/1/2012 OR files created under newer DOS/Windows/Linux/etc.

As for the 5 bit vs 7 bit year, I thought of this and put it aside figuring it would have manifested on 1/1/2012. Unless it is a combination of year and month somehow clobbering something.

Which gives me an idea!!!

Back in a bit.

[the-grue]

Well, my hunch didn't pan out. Looks like MSDOS formatted filesystems and MOS formatted filesystems don't behave any different.

Here's an example of a dump of two different files and their contents. TEST.TXT is dated 08/01/2012 and TEST2.TXT is dated 01/17/2002. Both have the same contents, notice the first block for TEST.TXT is garbage and the second one is fine.

0023000 T E S T T X T \0 \0 \0 \0
0023020 \0 \0 227 b 1 N 227 b 1 N 002 \0 023 \0 \0 \0
0023040 T E S T 2 T X T \0 \0 \0 \0
0023060 \0 \0 274 b 1 , 274 b 1 , 003 \0 023 \0 \0 \0
0023100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0041000 020 303 310 312 345 023 315 350 026 330 030 355 337 356 360 037
0041020 036 374 372 366 366 366 366 366 366 366 366 366 366 366 366 366
0041040 366 366 366 366 366 366 366 366 366 366 366 366 366 366 366 366
*
0042000 " T h i s i s a t e s t "
0042020 \r \n 366 366 366 366 366 366 366 366 366 366 366 366 366
0042040 366 366 366 366 366 366 366 366 366 366 366 366 366 366 366 366

Working backwards from the error message, I've folllowed the trail to mosfun3d in mosfun39.asm. I see it makes a call to hl_open. I've not looked at that yet, but I'm guessing there's no obvious problem, or you would have already found it.

Single step debugging starting with the call to hl_open would be nice. I wonder if there is a way to serial port debug it with vmware. What have you tried? Any suggestions?

[roelandjansen]

to be honest, I never ever tried that nor thought about it.

It seems that workstation can do at least with version 5.5 and now that we're at 15.xx I blindly assume it still works this way.

I only googled, not read much since I'm at a short break before I continue working:

https://www.vmware.com/support/ws55/doc/ws_devices_serial_advanced_example_debugging.html
https://briolidz.wordpress.com/2012/03/28/windows-driver-debugging-with-windbg-and-vmware/

[roelandjansen]

good work so far by the way!

VMWARE debugging sounds like it uses the tools included with the guest, like the Windows kernel debugger or GDB for linux. DOS has no such debugger that I know of. Does PC-MOS? In one of the ASM source files I saw some mention of debugging, but not sure what that's about. Maybe you know more. And there is Softice for DOS but I don't know if it works with a kernel or not.

The PC-MOS kernel makefile builds each ASM like so:

public $<
masm $*
del $*.pub

I suspect public was a periscope debugger utility. But I don't know what the purpose was, because removing it makes no difference in the object produced by masm.

Meanwhile, I found the Bochs project. It has its own internal debugger, with a GUI interface on a Windows host. I think I will try that first.

[roelandjansen]

if mem serves right, it indeed was a hw periscope debugger.

Before learning Bochs debugger, which is a sub project in itself, I need to read more code to have a better idea where to focus.

hl_open is not very big, I don't suspect the problem is there. But it calls pathfind in mosfutil.asm, which is not so simple. There is also pathcomp, findnm, and nextnm. A lot of code where things could go wrong.

If you could just compile it like a user app and throw it in Turbo Debugger, it would be much easier. With the Bochs debugger, you have no symbolic names for variables. You have to step line by line and look at the reverse assembled instructions to match them up with where you are in the source code.

The plan of attack is to step through the code with an old date where it succeeds, and then repeat with a current date where it fails. Where they diverge, that's where things go wrong, and then you try to understand why, by looking at registers and variables.

This could take some time.