OFS in NT 3.50.854: further research

[The Distractor]

So, back in 2011 I decided to play around with the implementation of OFS in NT 3.50.854: you can find that topic here; that topic has instructions on how to install it yourself, and it'll even work in NT 3.51 RTM.

I remembered this today and set out to do more.

[tjn]

The Distractor, Your post is very interesting, and I have never knew that OFS file system even exists in Windows NT 3.5, thank you for making this post.

[WinPC]

From what I had seen and heard at the time that this was released, this build was actually a build of Windows NT 4.0 (which also explains why the user interface update was also included), but the version number was temporarily shifted downward to 3.5 as a result of being forked from a post-RTM build of Windows NT 3.5.

Normal copies of Windows NT 3.5 and NT 3.51 don't have OFS.SYS at all - apparently, this was something that was originally planned for Windows NT 4.0 and later dropped, if the other members said was true.

[z180]

I think it was developed for Cairo the never released successor of NT 3.x.
You can finds small OFS code remnants in NT4 on FTP.

[The Distractor]

From what I had seen and heard at the time that this was released, this build was actually a build of Windows NT 4.0 (which also explains why the user interface update was also included), but the version number was temporarily shifted downward to 3.5 as a result of being forked from a post-RTM build of Windows NT 3.5.

Normal copies of Windows NT 3.5 and NT 3.51 don't have OFS.SYS at all - apparently, this was something that was originally planned for Windows NT 4.0 and later dropped, if the other members said was true.

This isn't NT 4.0 at all. This is a post-RTM build of NT 3.5, that just happens to have OFS, and a Chicago 2xx-era newshell for some reason.

The leaked NT 4 src shows that cairo builds will have ACCOUNTS.INF and CAIRO.INF in the i386 dir at least.

[WinPC]

From what I had seen and heard at the time that this was released, this build was actually a build of Windows NT 4.0 (which also explains why the user interface update was also included), but the version number was temporarily shifted downward to 3.5 as a result of being forked from a post-RTM build of Windows NT 3.5.

Normal copies of Windows NT 3.5 and NT 3.51 don't have OFS.SYS at all - apparently, this was something that was originally planned for Windows NT 4.0 and later dropped, if the other members said was true.

This isn't NT 4.0 at all. This is a post-RTM build of NT 3.5, that just happens to have OFS, and a Chicago 2xx-era newshell for some reason.

The leaked NT 4 src shows that cairo builds will have ACCOUNTS.INF and CAIRO.INF in the i386 dir at least.

Are you sure that ACCOUNTS.INF and CAIRO.INF even existed this early, and that they just weren't added in until later, or possibly added in earlier but later removed by this point?

Also, if you did a comparison even with Build 1130, you will see that it is almost entirely the same in terms of functionality, just that OFS.SYS was later dropped.

And even furthermore, it wasn't even that much longer that the Shell Technology Update even identified itself very clearly as being version 4.0, and even then, if you examined any copy of if, you will see that it updates the system files, basically converting any Windows NT 3.5x installation (NT 3.5 for Build 854 and NT 3.51 for later versions) into a pre-release version of Windows NT 4.0, especially considering that the kernel was still virtually the same even as recently as Build 1130 (with exception to a few updated files in Build 1130).

So really, I would say that this is definitely what later became Windows NT 4.0.

[DeFacto]

Still, it is part of 3.50 post-RTM. They probably indeed intended to make Cairo out of this, but technically it's not Cairo yet. Just like Neptune isn't XP, even though many elements were later transfered into the new project.

[hounsell]

It's a Post-RTM build doing what Post-RTM builds do. Serving as a test bed for some of the more crazy ideas thrown about.

Has anyone looked at this in say, IDA? It's got craploads of debugging strings all the way through it. It's hard to know where to start.

Did notice it's a classic B-Tree FS though.

[The Distractor]

Has anyone looked at this in say, IDA? It's got craploads of debugging strings all the way through it. It's hard to know where to start.

I haven't disasm'd it yet, but I did notice the debugging strings, and I also noticed a dll that seemed specifically for OFS-related stuff in kd.

Still, it is part of 3.50 post-RTM. They probably indeed intended to make Cairo out of this, but technically it's not Cairo yet. Just like Neptune isn't XP, even though many elements were later transfered into the new project.

Actually, I think Cairo was in development earlier than this; after all, judging by the screenshot of the OFS version, earlier versions of OFS have to exist.

The NT 4 src leak shows us that Cairo and Daytona were compiled from the same codebase, and cairo-specific stuff being inside #ifdef/#endif blocks.

It also shows us some other interesting stuff about Cairo.

For example, Cairo's setupdd, on finding an installed NT to upgrade, checked for the reg_dword value HKLM\SYSTEM\Setup\CairoSystem -- if this existed and was set to 1, setup assumed this was cairo and set the version number (internally to setup ofcoz) to NT 5.0 -- and comments show us this was in the time of NT 3.51.

[WinPC]

To DeFacto:
I agree that this build is obviously based on the same post-RTM build of Windows NT 3.5, that's why I said that it was forked from it. What I think is that the version number was originally intended to be version 4.0, and that the kernel version number was later shifted down temporarily to 3.5 upon being forked from Windows NT 3.5 post-RTM (later Windows NT 3.51 obviously), before being shifted back up to 4.0.

To The Distractor:
It's also quite possible that what you mentioned applied to certain builds of Cairo/Windows NT 4.0 but not this one. You also mentioned that it was from the same time period as Windows NT 3.51, so unless the post-RTM builds of Windows NT 3.5 count, I don't think that this applies to this particular build.

But I agree, overall, that Windows NT 3.5 (including later Windows NT 3.51) and Windows NT 4.0 were compiled from the same codebase during this stage of development, and as far as I'm concerned, this particular build proves it. It would also explain why the Shell Update Release converts any Windows NT 3.51 installation into a pre-release version of Windows NT 4.0 (and clearly identifies itself as such).

Especially once I open up my "Chronological Beta Testing Project" to the public (some of you who are officially part of the program itself have already received early versions of the topic itself), then I will try to provide all of the evidence in the world for each and every fact regarding these unusual versions of Windows.

[The Distractor]

It would also explain why the Shell Update Release converts any Windows NT 3.51 installation into a pre-release version of Windows NT 4.0 (and clearly identifies itself as such).

...except cairo existed for longer than you think. Evidence exists (antitrust docs, etc) that shows that cab32 was ported from cairo/NT to chicago...

And NT 3.50.854 itself proves newshell has existed since as early as chicago 2xx timeframe.

[WinPC]

It would also explain why the Shell Update Release converts any Windows NT 3.51 installation into a pre-release version of Windows NT 4.0 (and clearly identifies itself as such).

...except cairo existed for longer than you think. Evidence exists (antitrust docs, etc) that shows that cab32 was ported from cairo/NT to chicago...

And NT 3.50.854 itself proves newshell has existed since as early as chicago 2xx timeframe.

I'm not denying that it existed earlier, I'm just saying that the Shell Update Release for Windows NT 3.5 and later Windows NT 3.51 converted each installation to a pre-release version of Windows NT 4.0 (in Build 854, it resulted in a fully-functional 8xx series build, whereas with the versions released for Windows NT 3.51, it converted each installation to being a 10xx series build).

It's interesting that you mention CAB32.EXE being present in Windows NT 4.0 earlier than Chicago itself. When I was trying to rebuild Chicago Build 34 from the remaining files that we have available from it (as well as the partial leak of Build 40 files), I managed to get it working to the point where the rest of the operating system would load, but not the Win32 subsystem for some strange reason. Yet the File Cabinet shell and all of the applications (other than for Clock32 and Note32) worked just fine, proving that they were still 16-bit in the 3x, 4x, and 5x series builds.

Probably, the shell was originally 16-bit, being developed alongside the 32-bit version in Windows NT 4.0. What probably happened was that the 16-bit CABINET.EXE counterpart was more stable, and that they waited until the 32-bit CAB32.EXE version was stable enough to be usable on a daily basis before actually including it in Chicago itself.

[z180]

OFS is included in NT 4.00.1141 if someone is interested.

[Battler]

It's interesting that you mention CAB32.EXE being present in Windows NT 4.0 earlier than Chicago itself.

Noone talked about CAB32.EXE itself being present in NT 4.0 before Chicago. What The Distractor talked about is the UI itself being ported from Cairo to Chicago. Also Cairo, while being version 4.0, is not the NT 4.0 we got in the end, but a separate project that shared code with the rest of NT.

When I was trying to rebuild Chicago Build 34 from the remaining files that we have available from it (as well as the partial leak of Build 40 files),

Partial leak of Build 40 files? I suppose you mean the files that originated from Abandonet in mid-2010 or when that was, and which I'd been warning all the time back then on my IRC network that they might as well be fake. I think those files are not real and therefore you should just ignore them. The only real Chicago 40 files we have are those present in 58s.

I managed to get it working to the point where the rest of the operating system would load, but not the Win32 subsystem for some strange reason. Yet the File Cabinet shell and all of the applications (other than for Clock32 and Note32) worked just fine, proving that they were still 16-bit in the 3x, 4x, and 5x series builds.

CABINET.EXE in 58s is 16-bit.

[WinPC]

Noone talked about CAB32.EXE itself being present in NT 4.0 before Chicago. What The Distractor talked about is the UI itself being ported from Cairo to Chicago. Also Cairo, while being version 4.0, is not the NT 4.0 we got in the end, but a separate project that shared code with the rest of NT.

Actually, in case you missed it, The Distractor said this:

...except cairo existed for longer than you think. Evidence exists (antitrust docs, etc) that shows that cab32 was ported from cairo/NT to chicago...

I think that when he mentioned "cab32", he was most likely referring to the CAB32.EXE incarnation of the Cabinet shell. If he was just mentioning the user interface alone, then in my opinion, he would have been more likely to reference it as being "Cabinet shell" or "File Cabinet" rather than by the "cab32" executable name.

Still, we would need to see the documents themselves to really be sure.

CABINET.EXE in 58s is 16-bit.

Yes, that was exactly my point. Even when I had somehow broken the Win32c subsystem, the File Cabinet shell still worked without any issues. And you have to remember that Win32 was still in a relatively early stage at this point, especially when you consider that it was still very much in the process of being ported over to the Windows 3.x/Chicago line at the time.

[Patrick]

Regarding the Chicago 40 files, has there ever been an investigation into their legitimacy or are we just making assumptions that they may be fake?

[WinPC]

Regarding the Chicago 40 files, has there ever been an investigation into their legitimacy or are we just making assumptions that they may be fake?

Not to backseat moderate or anything, but isn't it against the rules to debate the legitimacy of Chicago builds?

Also, I thought that this topic was about the development of earlier Windows NT versions, not about Chicago.

[James]

Regarding the Chicago 40 files, has there ever been an investigation into their legitimacy or are we just making assumptions that they may be fake?

Not to backseat moderate or anything, but isn't it against the rules to debate the legitimacy of Chicago builds?

Also, I thought that this topic was about the development of earlier Windows NT versions, not about Chicago.

Yes, it is against the rules, but you're not the one who decides whether or not what Patrick says is violating said rule about "no discussing legitimacy of Chicago, etc. builds"

Besides, it's already certain that the 40 files are fake, OBattler said as much as he's the one who released them to start with.

Now, enough discussion about things that are not related to the original post of this topic, which is "OFS in NT 3.50.854."

[Terra854]

What is the full name of the OFS?

[TheWindowsXPGuy]

What is the full name of the OFS?

Object File System