Interesting. Just looked at that notebook disc. I see that the notebook files were in the ECCBAM (Extended ? ? Binary Access Method). That was widely used on the Alliance 250 product, a complete streamlining of the OIS software (using the same disc format) but with the ability to automate (Glossary) almost all applications. One of these was NOTEBOOK and it was great. From the Catalog alone it looks like it was re-compiled to run on with OIS-100 level slave (workstation/printer) software. Weird to suddenly see Wang software after such a long gap of seeing almost nothing.
| VCF Latam | Apr 24 - 26, 2026, | Bahía Blanca, Argentina |
| VCF Pac. NW | May 02 - 03, 2026, | Tukwila, WA |
| VCF Southwest | May 29 - 31, 2026, | Westin Dallas Fort Worth Airport |
| VCF Southeast | Aug 01 - 02, 2026, | Atlanta, GA |
| VCF West | Aug 01 - 02, 2026, | Mountain View, CA |
| VCF Midwest | Sep 12 - 13, 2026, | Schaumburg Convention Center, IL |
| VCF Montreal V2.0 | Nov 07 - 08, 2026, | Saint-Lambert, Montreal, Canada |
| VCF SoCal | See you in 2027, | Southern CA |
| VCF East | Apr TBD, 2027, | InfoAge, Wall, NJ |
-
Please review our updated Terms and Rules here
Anyone familiar with Wang OIS internals?
- Thread starter Chuck(G)
- Start date
Chuck(G)
Gone, but never forgotten.
I did contact Jim via LinkedIn (he's still there), but although he said he had some notes, he didn't say anything about an emulator.
I'm using standard tools--hex dumps and my wetware. I very often have to process incomplete data sets (e.g. backup sets that are missing volumes), so bit-twiddling is my trade. Just finished a large job of nearly 100 floppies from Ken Olsen's office (DEC). RSX BRU sets missing first volumes was an interesting exercise. In spite of that, we got data off of everything. Most were WPS8 floppies, but not all.
Here's another one for you; the 'Misty Marsh" game:
Looks like the old "Adventure" game that I ported (to CDC 6000 SCOPE) in the early 70s from a DEC PDP-10 tape that a friend smuggled to me. Just some changes in descriptions and items.
I've got a couple of commodity glossary utilities disks, but all the rest contain proprietary information, so I can't share any of that. The corporate structure around Dr. Wang was interesting.
I met Dr Wang once at an exhibition in Boston - '88 or '89. Great times.
Pity the business went they way it did. - Fred's cancelling the VS's unix port etc was just crazy. - They also had the 42X - a 680[23]0 ??? based workstation, Unix, graphics and the ability to talk to VS & OIS - four sessions using VS multi-station. All killed off. - Had at one time been told that a 42X was on its way to us.
Pity the business went they way it did. - Fred's cancelling the VS's unix port etc was just crazy. - They also had the 42X - a 680[23]0 ??? based workstation, Unix, graphics and the ability to talk to VS & OIS - four sessions using VS multi-station. All killed off. - Had at one time been told that a 42X was on its way to us.
Chuck(G)
Gone, but never forgotten.
Well, Fred wasn't his dad. From my reading, the culture seemed to be about guarding Dr. Wang from getting involved in distractions. Out of the correspondence that I've read, a relatively small number were penned by Wang; most were by members of his staff.
Of course, this is the impression that I get from what I read and may not be true to tlife.
Of course, this is the impression that I get from what I read and may not be true to tlife.
For the other side of the coin, read "Lessons" Dr Wang's autobiography. It ends at about the time when he passed control to Fred. His 'distractions' were how Wang Labs grew. Once his success attracted control by shareholders and spreadsheet-jockeys, then the rot started, but wasn't initially apparent until the big slide started. Milking OIS and WPS as they were in the mid-late 80s and delaying WP-Plus, as well as things like VS-Unix allowed the competition to gain traction. Their attempt at putting Wang style WP on Windows was a serious case of 'too little, too late' - it was a nice product, and FreeStyle was nothing short of revolutionary (integrated Apps. - Distributed office etc). Actually I think the Wang sued MS successfully over what MS called DDE or OLE (not certain). On top of that another 'distraction' was the idea of putting memory on a plug-in board - SIMM or DIMM anyone?
Chuck(G)
Gone, but never forgotten.
Is it safe to assume that the "Catalog" area always describes all files on the disk? That is, unlike FAT or any of the Unix filesystems, there are no subdirectories. So one can simply scan the Catalog area and extract all files without regard to which node they're associated with? Understand that my work involves extraction of data, not necessarily running programs. Further, does the OIS scheme permit duplicate file names, provided that they're associated with different parent nodes?
I assume that the emulator is a pile of C code, right?
I assume that the emulator is a pile of C code, right?
Last edited:
Chuck(G)
Gone, but never forgotten.
Shouldn't be too difficult to bring it up to C90 standards.
Chuck(G)
Gone, but never forgotten.
Can't say anything about that. Although I wonder--is a graphical interface strictly necessary? After all the OIS terminals were text-based, as far as I know.
Given that there was all of the important information in the Catalog and the VAUmap, if you lost the content or it became corrupted, you pretty much lost everything? That's a pretty daring design when it comes to floppy storage. At least with the WP disks, you can recover all of the sectors belonging to a file. Microsoft didn't stick two copies of the FAT on their disks for jollies.
Given that there was all of the important information in the Catalog and the VAUmap, if you lost the content or it became corrupted, you pretty much lost everything? That's a pretty daring design when it comes to floppy storage. At least with the WP disks, you can recover all of the sectors belonging to a file. Microsoft didn't stick two copies of the FAT on their disks for jollies.
Last edited:
The screen can be memory-mapped. The top 16K of the Z80 space can be enabled to 'see' the video ram. Later workstations also had software-defined fonts, which were leveraged to provide a graphics display facility. Normally the Z80 ram with all-data, with the screen driver code in the lower 48K simply switching in the CRT area, updating and switching back.
Having found the emulator, we are in a position to actually build a running OIS, with original software from original floppies. - I think that I have the discettes to build a classic OIS system, rather than Jim's R&D based system.
I'll be trying to build a system to-morrow.
Having found the emulator, we are in a position to actually build a running OIS, with original software from original floppies. - I think that I have the discettes to build a classic OIS system, rather than Jim's R&D based system.
I'll be trying to build a system to-morrow.
Chuck(G)
Gone, but never forgotten.
I can understand that, but it makes no sense at first blush. Is there ever a case where the VAU map doesn't start on a VAU boundary? Just trying to figure out why 2 bytes for the catalog location (VAU number) and 3 for the VAU map (sector number)
The catalog name always seems to start with 0x0b. i.e.
Code:
0b 43 61 74 61 6c 6f 67Also, passwords: It seems that the password isn't used to encrypt anything, so a program could open the volume in direct mode and obtain whatever it wanted, no?
Last edited:
When a disc is formatted it is given a VAU size - the number of sectors per VAU, always a power of two, so 1,2,4,8 yada 128 - Value fits in a byte.
For large discs the minimum VAU size must be large enough that all sectors can be addresses by a VAU# (16 bits). Floppies and HAWK (5MB) disc drives are OK, as maybe the 13MB removables. The 39 and 65 MB drives likely have minimum VAU sizes of maybe 4 or 8. - That's something for me to re-document.
The catalog node was given 0x0B (There are no indications that there were any other such 'funny values' in node names) in order to prevent it being opened by 'user programs'. I modded a version of the MASTER code to omit that check and it was then possible to open the catalog as a file. - The problem was that doing so prevent all other catalog operations that required updating, that caused MASTER to crash.
The label holds a catalog version number (2), from which I'm guessing that there might have been a version 1, where to obtain a catalog listing, it was possible to open the catalog file directly. All versions of OIS MASTER that I saw from maybe 5.x to 11.z had a request code 'OpenCat' which returned a pre-parsed version of the catalog as a temporary file for Catalog display to use.
No, there is no case for a VAU map, Catalog or user file ever to start on a VAU boundary. The catalog addresses the file's data by VAU# and the VAU map links the file's data areas by VAU#.
3-byte values are sector addresses. 2-byte values are VAU addresses. - All that is required is a multiply or divide by the VAU size to convert them. - MASTER uses the relevant shift right/left as VAU sizes are powers of two and Z80 has no mul or div orders.
The passwords are just passwords, like early Unix etc/passwd where the passwords were not even hashed. A write password was a string of 1 to 8 characters. If a write password was specified and no read password, then the password was just stored in the next 8 bytes. If a read password was given, then it had to be a string composed of the write passwords characters. eg Billybob as a write password allowed read passwords such as Bill, Billy, Bbb or Bilbo. The chars unique to a write password simply had the top bit set. e.g. if a write password was 'Fred' and the read password 're' the the hex would have been C6 72 65 E4.
No encryptions etc. For crypto work work, it would have to have been implemented in the OIS MASTER code (Z80) and would have seriously slowed operations and even then likely not to have been very strong. Wang exported OIS quite widely and in the 70s to the 90s even DES, never mind 3DES was classed as a munition in the eyes of the US (and likely a good few others).
Yes, the ability open OpenDC a disc exposed everything. (try /dev/discxxxx or whatever on Unix). For OpenDC to succeed you either had a disc with no 'volume password' in the label or you gave that password in the OpenDC request.
For users, there was no way to determine the volume password. - except for sites with access to a VS or 2200 system, reading sector 0 was not a problem for any competent coder. As the floppy door was locked on mount, you could not switch the disc after OpenDC. - 5.25" sites excepted possibly, but the 'drive ready' line would have dropped, possibly causing the OIS50-series master to fail all ops until a later successful mount. - Wang's coders were diligent.
Chuck(G)
Gone, but never forgotten.
The not-necessarily-on-a-VAU boundary is where I mentally stumble. If the VAU map isn't on a VAU boundary, of what possible use can the "filler" sectors be? Never used for anything?
If a file is deleted, is its catalog entry entirely zeroed, or just the first byte or so? What I'm getting at, is if a file name search is conducted, is it necessary to search the entire catalog, or can a search stop at an all-zeroed entry?
If a file is deleted, is its catalog entry entirely zeroed, or just the first byte or so? What I'm getting at, is if a file name search is conducted, is it necessary to search the entire catalog, or can a search stop at an all-zeroed entry?
Last edited:
Oh, sorry, deletion: When a file is deleted its entries in the VAU map are all set to 0xffff. - That frees the space.
Then the same-level pointers in the catalog that pointed to the deleted file are made to point to where the same-level pointer in the deleted file's node pointed. (Taking a link out of a chain.)
The 48 bytes of the file's catalog node are zeroed. These actions could, in the case of say a file call A.B.C, where C is the only file in node B, leave B empty, in these cases B is deleted, this process recurring back up the file's catalog tree either to the root or to a point where the node has other next-level node attached.
Think of a Unix directory system where empty directories cannot exist. if /u/mydir/myfile exists and is the only file in mydir, then deletion of myfile would automatically rmdir mydir.
There is no such thing as a 'current directory' in OIS OS.
Then the same-level pointers in the catalog that pointed to the deleted file are made to point to where the same-level pointer in the deleted file's node pointed. (Taking a link out of a chain.)
The 48 bytes of the file's catalog node are zeroed. These actions could, in the case of say a file call A.B.C, where C is the only file in node B, leave B empty, in these cases B is deleted, this process recurring back up the file's catalog tree either to the root or to a point where the node has other next-level node attached.
Think of a Unix directory system where empty directories cannot exist. if /u/mydir/myfile exists and is the only file in mydir, then deletion of myfile would automatically rmdir mydir.
There is no such thing as a 'current directory' in OIS OS.
Chuck(G)
Gone, but never forgotten.
If the catalog is given a location that's on a VAU boundary in the volume label (2 byte word), why not the VAU map itself? Why a three-byte sector address? I'm looking for consistency here or at least a reason.
Can one have two files named the same but belonging to different nodes? i.e. A.B.C and E.F.C. Can a file belonging to a given node occur in the catalog before the entries for the node itself? I suspect the answer to the first question is "yes", but not sure about the second.
Last edited:
To cater for large discs (op to 600MB were available) a 3-byte sector number was required. - Allowed 4GB of space, they were well ahead, when you think about the mess that was MSDOS and how many variations of FAT there were. Some VAX systems had limitations of disc size.
Using VAUs gave, on large discs, decent runs of consecutive sectors, reducing the impact of fragmentation. Also, with a VAU# being 2 bytes they could be manipulated by Z80 easily.
The VAU map is always on a VAU boundary.
Using VAUs gave, on large discs, decent runs of consecutive sectors, reducing the impact of fragmentation. Also, with a VAU# being 2 bytes they could be manipulated by Z80 easily.
The VAU map is always on a VAU boundary.