Commodore and old system LHA archive format...

[Spork Schivago]

Re: Commodore and old system LHA archive format...

If I got the endianness stuff right, I think I know why you thought I didn't know it. My comment about the seconds being more than 78 years. It's because I had some news today that really shook me up. I'm not allowed to tell anyone I know personally yet, but my wife told me she's pregnant! I'm going to be a dad!!!!

I am sooooo freaking nervous and excited. She said I could tell you guys. She's sleeping and has been shortly after she told me. I came in here to work on this to try to take my mind off of it. I'm so nervous that I won't be a good dad or something. Besides me and my wife, you guys are the only ones who know.

[rhomanski]

Re: Commodore and old system LHA archive format...

Congratulations! Don't worry, you'll get the hang of it. Unless you have a girl and then you ain't seen worrying yet. Wait till she starts dating and brings home a long haired drug addict. Lol.

[stj]

Re: Commodore and old system LHA archive format...

or a zombie on prescription crap!

[Spork Schivago]

Re: Commodore and old system LHA archive format...

Congratulations! Don't worry, you'll get the hang of it. Unless you have a girl and then you ain't seen worrying yet. Wait till she starts dating and brings home a long haired drug addict. Lol.

LOL! Thanks! I'm just hoping for a healthy baby. Can't see why it won't be healthy though. Is it normal for pregnant women to sleep a lot? My wife's been asleep more than she's been awake lately.

[diif]

Re: Commodore and old system LHA archive format...

Congratulations.

Oh yes the worry !!!! and the things we've been through.....dealing with a some scrote is easy lol

[Spork Schivago]

Re: Commodore and old system LHA archive format...

So, I discovered something with the JetBBS.dat format. In the hex editor, if I input these values, I get these results for the time stamp...

0xA016CF12 - 01-01-80 12:00am
0x1F16CF12 - 12-31-07 11:58pm

Does anyone know what's going on there? As to why A016CF12 might make it 01-01-80 12:00am but 0x1F16CF12 would make it 12-31-07 11:58PM?

[stj]

Re: Commodore and old system LHA archive format...

LOL! Thanks! I'm just hoping for a healthy baby.

then stay away from satanists bearing vaccines.

[fzabkar]

Re: Commodore and old system LHA archive format...

Sorry for my outburst. My frustration got to me.

I thought we had established that the byte order was little-endian, and we did this by analysing your own examples as well as mine. Yet you insisted on interpreting the date/time stamp as big-endian. It seemed we were back at square one.

As for the discrepancies in your data, I don't have an answer. In your earliest examples the date/time stamp was in Unix format. The 32-bit little-endian dword counted the number of seconds since 1/1/1970 0:00. In your later examples the same data seemed to be counting the number of seconds since 4:00PM on Dec 31, 1997. This makes no sense to me.

[Spork Schivago]

Re: Commodore and old system LHA archive format...

We gotta pick out some cool names too. Man, I feel like I'm in shock. I can't believe I'm actually gonna be a father.

[fzabkar]

Re: Commodore and old system LHA archive format...

0x12CF161F seconds = 3652 days + 7 hours + 58 minutes

http://www.timeanddate.com/date/date...=&ad=3652&rec=

So this is counting the time since 4PM Dec 31, 1997.

0x12CF161F seconds = 3652 days + 8 hours

No idea.

[stj]

Re: Commodore and old system LHA archive format...

We gotta pick out some cool names too. Man, I feel like I'm in shock. I can't believe I'm actually gonna be a father.

Freya or Athena would be cool - look up norse mythology.

[Spork Schivago]

Re: Commodore and old system LHA archive format...

Sorry for my outburst. My frustration got to me.

I thought we had established that the byte order was little-endian, and we did this by analysing your own examples as well as mine. Yet you insisted on interpreting the date/time stamp as big-endian. It seemed we were back at square one.

As for the discrepancies in your data, I don't have an answer. In your earliest examples the date/time stamp was in Unix format. The 32-bit little-endian dword counted the number of seconds since 1/1/1970 0:00. In your later examples the same data seemed to be counting the number of seconds since 4:00PM on Dec 31, 1997. This makes no sense to me.

It's my fault. I was just really excited and really worried about being a new dad. My wife didn't want me to tell anyone yet but later in the day, she said I could tell you guys. I knew it was little endian, but when she fell asleep, I didn't know what to do with myself, so I just went in the work room and started working. I had so much going through my mind at the time, I was just trying to stay busy, I didn't even notice I was posting them as big endian.

It is weird. The headers I found show LHA uses the Unix format. I think this is where the confusion might of came from. This custom .dat doesn't follow the actual LHA format. It's close, but it's not the same. The only thing I found that produced identical files (minus the time stamp and crc (because of the missing time stamp)) was this program:
https://oku.edu.mie-u.ac.jp/~okumura/compression/ar002/

It seems JetSetup.exe is packed with something called EXEPACK. I unpack it and I see it's been compiled with Microsoft Quick C 2.x [1990]. Is it possible that Quick C uses a funky date / time format? All 00's = roughly 1997....but the bytes I showed takes it back to 01-01-1980 12:00am.

I was thinking, could maybe the variable used to store the timestamp in the original program used to create JetSetup.exe be using unsigned long and the data we see in JetBBS.dat be looking weird because we're viewing it as signed?

I know what signed and unsigned mean, but I don't know how the data for signed and unsigned is stored in memory. If I have an unsigned int variable called x, and I store 1 in the file, but then later on, I read it into a signed int variable, wouldn't 1 be a negative value?

[mariushm]

Re: Commodore and old system LHA archive format...

Signed/Unsigned : it depends on the architecture of the hardware.

On x86 x64 and others, two's complement is used : https://en.wikipedia.org/wiki/Signed...27s_complement

A more detailed article : https://en.wikipedia.org/wiki/Two's_complement

PS. Since the software is so old, don't make assumptions that variables or data is 32 bit (4 bytes). The software may have stored the information in two signed 16 bit variables, or maybe it did some bit optimizations (like dos did with storing dates)

[Spork Schivago]

Re: Commodore and old system LHA archive format...

Signed/Unsigned : it depends on the architecture of the hardware.

On x86 x64 and others, two's complement is used : https://en.wikipedia.org/wiki/Signed...27s_complement

A more detailed article : https://en.wikipedia.org/wiki/Two's_complement

PS. Since the software is so old, don't make assumptions that variables or data is 32 bit (4 bytes). The software may have stored the information in two signed 16 bit variables, or maybe it did some bit optimizations (like dos did with storing dates)

I couldn't find any information on Microsoft's Quick C data types or date / timestamp. I have to admit, I didn't really look too hard last night. I'll spend some more time looking into it. I decompressed the JetSetup.exe so I could use a debugger on it. It's just that I don't know much about using debuggers. I can use OllyDbg, but that's for PE Applications. It seems DOS apps are a hole nother ball game.

Thanks for the suggestions. If I remember correctly, Two's Complement means a 1 in the MSB means negative....but you also have to add one to the binary digit, right? I'll check out the articles you linked too. Been a long time since I played with two's complement.

[Spork Schivago]

Re: Commodore and old system LHA archive format...

0x12CF161F seconds = 3652 days + 7 hours + 58 minutes

http://www.timeanddate.com/date/date...=&ad=3652&rec=

So this is counting the time since 4PM Dec 31, 1997.

Yeah, that's the easy part. I wrote a small program that converts the hex into years, month, day, hour, min, seconds, in big and little endian. It doesn't take into account leap years. I want to take into account how many days are in a month and leap years. Then when I enter the current 4 bytes in the archive file, it'll show me the same timestamp that DOS shows me. Once I do this, I'll implement it into ar.c.

0x12CF161F seconds = 3652 days + 8 hours

No idea.

This is what was confusing me. 0x12CF16A0 starts the counter at 01-01-1980 12:00AM. I would think 0x00000000 would start the counter at 01-01-1980. I've tried looking at it in binary but I didn't really notice anything. I still gotta play with it a little bit. Figure out what ranges go from 01-01-1980 12:00AM to 12-31-97 4:00PM. Then I can work on implementing the time stamp.

[Spork Schivago]

Re: Commodore and old system LHA archive format...

0x12CF161F seconds = 3652 days + 7 hours + 58 minutes

http://www.timeanddate.com/date/date...=&ad=3652&rec=

So this is counting the time since 4PM Dec 31, 1997.

0x12CF161F seconds = 3652 days + 8 hours

No idea.

Also, I just wanted to make sure my program is handling the little endian timestamp conversions properly. I pop in 0x12CF161F, I get:
3652 days (which you've already confirmed)

10 years, 0 months, 2 days, 7 hours, 58 minutes, 23 seconds. That sounds about right, doesn't it? It doesn't take leap years into account...just 365 days a year.

[fzabkar]

Re: Commodore and old system LHA archive format...

I was going to suggest a test procedure, but your latest "1/1/80 0:00" result has upset my line of thought. I have no idea what is going on here.

Prior to your latest test, my guess was that low numbers for the date/time stamp were being treated as counts of seconds since 4PM Dec 31, 1997. If the stamp were a sufficiently large number (eg 28 years), then this would decode to 2026 which exceeds the system time. In such cases the stamp would be reinterpreted as a count of seconds since 1/1/70 0:00.

To test this idea, I was going to propose that you alter the system date to 2037 (Unix has a 2038 "millenium" bug). Then see whether large numbers for the stamp resolve to 1997 based counts rather than 1970.

[Spork Schivago]

Re: Commodore and old system LHA archive format...

I was going to suggest a test procedure, but your latest "1/1/80 0:00" result has upset my line of thought. I have no idea what is going on here.

Prior to your latest test, my guess was that low numbers for the date/time stamp were being treated as counts of seconds since 4PM Dec 31, 1997. If the stamp were a sufficiently large number (eg 28 years), then this would decode to 2026 which exceeds the system time. In such cases the stamp would be reinterpreted as a count of seconds since 1/1/70 0:00.

To test this idea, I was going to propose that you alter the system date to 2037 (Unix has a 2038 "millenium" bug). Then see whether large numbers for the stamp resolve to 1997 based counts rather than 1970.

That's a good suggestion. However, I don't think time is supposed to start at Dec 31, 1997. I don't think it's because of a bug that we get dates before than. The reason I say this, JetBBS 5.0 was released in 1996. The time stamps seem to match up like they're supposed to.

I used some programs to figure some stuff out about JetSetup.exe. I can send you a zip file for the original program if you'd like to play around more.

It shows JetSetup.exe is compressed with EXEPACK. Once I unpacked it, it shows it was compiled with Microsoft Quick C 2.x [1990]. I almost want to say I remember something about Quick C being able to use EXEPACK. I thought maybe someone used something like a time structure to save the date / timestamps, instead of implementing a function to handle the raw bytes. Then they just wrote the structure to the file. Maybe Quick C does some funky stuff for timestamps.

I contacted the original creator of ar (the LHA one, not the ar Unix utility). He said he never implemented timestamps but said LHA was being written off his ar program, around that time. Maybe an early version of LHA handled timestamps differently than it does today.

I think we almost have this completely figured out though. I just gotta map out how it counts. I believe it is seconds. Just if the hex value is in a certain range, it's seconds from 1980. If it's in a different range, it's seconds since 1997.