In 1990 I joined the WIndows NT OS/2 team after working on Lan Manager for several years. I was one of about 4-5 developers who moved from the Lan Manager team to join the much storied NT OS/2 developers. I still have my copy of the NT OS/2 workbook in my office – it’s a collection of the specs that make up Windows NT (astonishingly many of the aspects of the workbook are still valid even after almost 20 years). In my office, I have a copy of the “NT Plan” which was the original schedule for NT. Some of the entries on the “NT OS/2 Issues” page were:
- “Install operating system – who will write?” [Back then, setup was an afterthought]
- Programming editor – what editor will we have? Need better than a simple system editor (Better than VI!) [They ended up with “M”, the “Microsoft Editor” which was a derivative of the “Z” editor].
- 1024 byte sectors for system files. Needed? Needed for Japanese floppies? How needed [floppy support was critical back in the 1990s]
- LAN: Who owns the redirector. Need two developers [they got one: me :)]
The original schedule for NT OS/2 was that it would be demoed at Comdex in November showing off 4 “exciting 32 bit OS/2 applications” with no network filesystem support. The plan was for an SDK release in the 4th quarter of 1990. I also have the initial NT schedule for 1991-1993 which indicates that the plan was for 5 separate releases staged from 1991 to 1993, it ended up that none of the individual releases were made but the 5th release pretty closely aligns with the final Windows NT 3.1 project (which is pretty cool given how much changed in the NT project over that time).
In all honesty, I was in over my head on the NT project – I was trying to build a component that was intended for use in a multithreaded/multiprocessing environment having never previously written code for such an environment – before that all my programming had been in assembly on MS-DOS. I learned a staggering amount during my 4 years on the NT team and while it was extraordinarily painful, I came out of the experience a far better developer.