Closed ghost closed 5 years ago
I continued with the next step, configuing with ACU. It added $386.SYS to config.sys. Then I rebooted, and it crashed. VMWARE 9 can't handle $386.sys.
I have real hardware to try it on, but the floppy install erases all hard disk partitions before it does anything else. At the moment I don't feel like opening a computer to swap hard drives, so that waits for later.
What I wanted to learn most is, what happens with $$shell.sys and command.com?
$$shell.sys keeps its pre install size of 33794 bytes, and command.com is only 524 bytes, with a small blurb of code at the beginning. Wild guess, somehow invokes $$shell.sys.
But that begs the question, why is it backwards on PCMOS386-9-user.img in IMAGES?
the sealed envelope contains a code that activates it to unlimited. There is code that generates the code for you here as well.
Regarding command.com -- it does indeed pass on the stuff to $$shell.sys and command.com is backward-compatibility and required.
vmware 9? what is that?
the sealed envelope contains a code that activates it to unlimited.
How? Does it patch files? Is that all it does?
There is code that generates the code for you here as well.
Where? How to use it?
Regarding command.com -- it does indeed pass on the stuff to $$shell.sys and command.com is backward-compatibility and required.
The IMAGES command.com looks different. Very mysterious.
vmware 9? what is that?
Virtualization environment software. vmware.com I have an old one, version 9.
Regarding command.com -- it does indeed pass on the stuff to $$shell.sys and command.com is backward-compatibility and required.
I've not yet seen in a makefile where it's created. Does anyone know?
The code related to the serial number "stuff" is in the sn directory. There is a file called MAKUSER.DOC that is missing, so I haven't gotten that to work.
I think one of the first improvements to this codebase when we squash the 2012 bug and plan a first open release would be to remove the serial number code.
Based on the pictures of the ebay stuff I purchased, the envelope is there. Of course, this is for version 4, but it might give some pointers on how to reverse engineer it if anyone wants to give it a try.
Now I see SOURCES/src/sn/ OK. Thanks.
Good idea about removing the serial number code.
I still want to know where/how command.com is generated.
It's not obvious to me how the files in SN can activate an eval. So I tried something else.
I copied $$mos.sys from the 9-user IMAGES floppy over the $$mos.sys in my 5-user SHIPMOS install. After rebooting, now I have an active 9-user license. Seems to work.
When you don't know what you're doing, try anything, to see what happens. It's only software, you can't injure yourself.
Good find! Leave it running for over an hour just to see if it times out on you.
I don't see the 60 minute demo notice when it boots, so it's probably fine. But I'll let it run more than 1 hour, and advise.
In the SN directory, some ASM files talk about patching $$mos.sys, so diffing the two $$mos.sys files to see what changes may provide some insights. I won't do that now, just noting it for future reference.
I agree we should get rid of the serial number altogether, but it would be nice to have a working activator, so that when we remove the serial code, we know what we're doing, and don't miss anything. I like to have something to compare against.
Or maybe that is all moot, if we build the R&D kernel instead of the eval. But is it safe to assume the R&D kernel is functionally identical to an activated eval? That is not clear to me at this point.
Yes it passed the 1 hour test
when home I'll check the tree and memory hopefully comes back on how to fix the eval stuff.
the sn directory is indeed the place to be. I do not have a working eval vmware image right now on this laptop to test but I do recall that the activation was a piece of cake.
I'll see if I can get stuff working in my eat-at-work-time ;-)
Ok, I am a heathen and unceremoniously opened the sealed envelope and it took me down the old "I wonder" path and sure enough I figured out the licensing tool and how to use it.
Basically, you'll need the MAKEUSER.EXE tool located in the sn directory. You can follow along with this example if you have installed from the disks in the SHIPMOS directory.
On the boot screen, upper right area you'll see the serial number, probably 05-30041410.
Navigate to wherever you have the SOURCES\src\sn directory in your git repo or zip file you downloaded and extracted.
Type "makeuser /I 0530041410" (That is capital eye) followed by the serial number without the -.
What you are looking for is output similar to the following:
0530041410,75NC
Which will be the first line following the banner and then it runs off a list of other serial,key combos.
Then, in your MOS install, go to the root directory and type "init 75NC":
And reboot. You now have a licensed MOS system:
I had been messing with the MAKEUSER program a bit and the source code to try to figure it out and the missing piece was in the sheet of paper in the envelope, which showed the 4 digit code. I remember having run the makeuser command with the /I and my serial number but the 4 digit codes and how to get them in the system eluded me.
I believe makeuser might have been a key generator program for TSL to create their serial number/key combinations for runs of disks.
Anyway, give it a try and see how it goes!
To me, solving this mystery is bigger than the date bug. The date bug is just a question of source code, debugging, and time. Let's hear it for the sealed envelope!
About the 386.SYS issue. Did you set the appropriate switch? I set the MEMDEV option to /P to get it working. It doesn't appear to have issues and I have upped my memory settings as far as 512M. Also, you will probably want to disable hardware virtualization. In VirtualBox, it is under System | Acceleration | Enable VT-x/AMD-V. This is a requirement for a lot of older operating systems when they try to exit real mode and go into protected mode. Not sure where that would be in VMWare, as I haven't used it in years.
Thanks for those tips. I will look into it. If I supported 75 year copyrights, I wouldn't use VMWARE either.
MEMDEV /P does work with VMWARE. Much better. The CPU vitrualization does not exist in hardware compatibilty 4.x. Later versions have it, but I assume in 4.x they default it to off, since the setting is not exposed. Thanks for the /P tip, I had no idea.
You're welcome. If you hover over the MEMDEV setting in the ACU and press F2 (options) it shows you the possible settings. I found /P to work for me, but there are other settings.
I was able to copy the 5.25 disks for version 4.0, but ran into 2 issues.
Having 4.1, the manual, and the sealed envelope helps a lot. But if 4.0 is a problem, I would not spend more time on it.
I will have the v5.0x manuals and probably disks today as a loaner from my long time Arjen Schouten.
That's great news! I am about half way through scanning the v4 documentation, then I need to convert it to searchable. Takes a bit of time with a single side scanner.
I can upload the v4.1 disks as well.
OK, closing.
Has anyone completed a simple install? The PCMOS386-9-user.img in IMAGES is much different from the files in SHIPMOS. You can boot the 9 user IMAGES floppy, but I don't see how it's useful after that. The system and auxiliary disks in SHIPMOS (once you create them from the files) let you do a floppy install from scratch.
So I did that, it worked, and now I got this:
I want the sealed envelope! Or at least knowledge of its contents.