SCO Merge Notes
2013/07/17
SCO Merge notes
Merge was DOS emulation for SCO. I leave this stuff here just for historical purposes, though I did find a customer still using this as recently as 2009! They had old Lotus spreadsheets..
By a long and torturous path, Merge eventually ended up becoming "Win4lin", an early (and now defunct) virtualization product.
Should you find this still running on some SCO box that you need to keep running or are replacing, some of this may help.
As of July 2013, there was still this SCO Merge 5.1 for OpenServer available from SCO. There is also this Administering SCO Merge.
Merge Floppy access
Message-ID: comp.unix.sco.misc 3/15/99 David Peet
From: David Peet <no-spam@earthlink.net>
Subject: Re: Merge 4.11e and OS 5.04
Date: Mon, 15 Mar 1999 10:11:25 -0800
...
New to Merge 4.1.1 for OpenServer, the floppy is
now accessed in the same way as it is on Merge for
Unixware (via the UNIX floppy driver) instead of
"direct attached" as it had been done. This change
is because on faster machines the direct attach
of the floppy often has problems because of timing.
(Note: The released version of Merge 4.1.1
is cycle e. If you have cycle d, then you
have a beta and you should really be using
the final released version. See my page
http://www.lainet.com/~peet/Merge/ for links to
where you can download it from SCO.)
For a Win95 that was installed when direct attach
floppy was being used, the registry needs to be
updated so that Windows can use the new accesss
method.
The problem is that Merge is supposed to update
your existing Windows registry when you upgrade to
4.1.1, and this update must have failed insome way.
(Any new installation of Windows after the upgrade
will not have the problem. It is only an issue
of changing the hardware setup for an existing
Windows installation.)
What is supposed to happen is that the
program /usr/lib/merge/bin/upgrade_flop.sh is
supposed to be run the first time you use Merge
after upgrading. This is supposed to update
the registry. Either this did not get run
automatically or it failed someway. You can
retry this by running it. Just running it
(with no parameters) will upgrade your regular
Windows installation as specified by your "win"
personal configuration. If you have other personal
windows95 configurations, you need to run this
script for each one, using as a parameter the name
of the configuration.
If this does not work you have two choices:
1: Reinstall Windows so the new installation will
work with the new floppy access method.
2: Change Merge to use direct attach floppy access so
old installations of Windows will work as is.
o Change the MERGE_DIRECT_FLOPPY_ENABLE
switch in /etc/default/merge from off to on.
o Edit /etc/conf/pack.d/merge/space.c and
change the value of _M_direct_attach_floppy
from 0 to 1 and rebuild a kernel
(/etc/conf/cf.d/link_unix -y) and then
reboot.
SCO_OSR5 Merge 5.3 and MS-DOS 6.22 WARNING Merge _M_vmonitor unknown opcode 00000039
From: Bela Lubkin <belal@sco.com> Subject: Re: Merge 5.3 and older DOS Date: Wed, 2 Jul 2003 03:19:49 GMT References: <bdn191$pka$1@ngspool-d02.news.aol.com> Bob Bailin wrote: > > After (finally) upgrading our system from 5.0.5 to 5.0.7 and installing > > Merge 5.3 in the process, I found that I could no longer run MS-DOS 6.22 > > under Merge 5.3 as I could under Merge 4.1.1. > > > > (Dual P III system w/512MB memory.) > > > > Understand, I could *install* DOS 6.22 just fine using dosinstall, and the > > images created in the process with mkimg were built without a problem, but > > trying to run 'dos' afterwards from the console results in a screen blanking > > and a brief display of the mouse driver message, followed by another > > blanking and a return to the unix prompt. The merge error log shows that the > > VM86 process has died, as expected. Interestingly, if I run dos in an > > X-Windows, or if I have an X-Window running on another multiscreen, I get an > > additional error window with the message: "Unknown command opcode 89", (I'll > > have to check on that exact number), and the separate dos window which > > Jun 26 16:57:58 pilgrim WARNING: Merge: _M_vmonitor: unknown opcode 00000039 > Jun 26 17:02:08 pilgrim WARNING: Merge: _M_vmonitor: unknown opcode 00000083 > > > doesn't blank out shows that the process died just after initializing the > > mouse driver but before the CD-ROM driver. If I disable the mouse driver and > > clear out the config.sys files, the process still dies but obviously without > > any reference points to gauge where it died during the DOS boot process. I asked about this and was given the following workaround, which I have not tested myself and probably cannot answer questions about. The problem was apparently an unintentional side-effect of changes to support WinME; a fix is being put into ongoing source so that future releases of Merge will support DOS 6.22 by default. The workaround I was given: " As super user: " " cd /usr/merge/image " " Add the line " " install = mrgtsr.exe " " to the END of the file config.mki " " Then run the following commands: " " dos2unix config.mki > /tmp/config.mki " unix2dos /tmp/config.mki > config.mki " mkimg " " Whenever you start DOS, on the DOS screen, you may see a message " "Merge TSR / Windows DRV is already installed." following the " "Virtual Bus Mouse Driver installed" message. This extra message " is purely informational and can be safely ignored. Please post a followup after you've tried this... >Bela<
Bob did reply, adding:
It works perfectly!! Yes, there is the "...is already installed" message upon each boot, but I think I can live with it. Windows 3.1 started up without a hitch, surprisingly, because the default DOS configuration allocates 2MB of memory to the session instead just 640K. (Note: Win 3.1 does not work with later versions of dos, and you can't use 'win' to start up Win 3.1 directly from unix, although you can create an alias that will start it up like any other dos program in /usr/ldbin .) You can save a little typing by entering the ^M directly using: ^V^M instead of the dos2unix, unix2dos gyrations. You can make the change permanent for future (re-)installations of DOS 6 by editing /usr/lib/merge/for_image/config6.mki (a read-only file) instead.
Why SCO Unix Merge requires Windows boot disk
From: Bela Lubkin <belal@sco.com> Subject: Re: Merge Installation/Configuration Problem on OpenServer 5.0.7 Date: Mon, 4 Aug 2003 06:45:09 GMT References: <20030803230650.GC1332@jpradley.jpr.com> Merge requires a boot disk because Windows installation requires a boot disk. If you had a completely blank PC you would not be able to install Windows from unbootable media, you would need a boot disk. Merge _could_, technically, provide internal boot media. But this would violate Microsoft's copyrights, and the authors of Merge would have been put out of business more than 10 years ago. I suspect that with current Windows media kits, they might even technically be able to install without a boot disk; however, the software scrupulously follows the original requirement so that there is no question at all of Merge promoting piracy of Windows. You could of course use your own pirated media, but you would be doing that under your own power, neither encouraged nor abetted by Merge. In fact, it sounds like this is pretty much what you _are_ doing, trying to use Windows upgrade media whose salient differences from full product media are (1) they aren't bootable, (2) they're cheaper. And hey, you're paying the price in frustration and confusion. The system works. >Bel<
More on Merge Windows installation (SCO Unix)
From: "Bob Bailin" <72027.3605@compuserve.com> References: <20030804064509.GC24551@sco.com> Subject: Re: Merge Installation/Configuration Problem on OpenServer 5.0.7 Date: Mon, 04 Aug 2003 18:40:06 GMT "Transpower" <transpower@aol.com> wrote in message news:20030804101144.13162.00001244@mb-m10.aol.com... > Bela: > > RE: Merge Installation/Configuration on 5.0.7 > > Here's the context--I've tried both Windows 98 and Windows ME with > the respective Start Disks and got the same error messages. I have > the latest version of Merge, 5.3.23. For some unknown reason, > Merge seems to think there is still a pre-existing version of DOS > (from the previous 3.22t version of Merge) installed on the system > which prevents the installation of DOS 8 and a Personal copy of > Windows ME or 98. I have filed a Bug Report with SCO. I'm going to give this one last try: In the course of installing/upgrading/re-installing Merge, you've clobbered something, somewhere. The easiest solution is to start from square 1. Using custom, remove SCO Merge. Reboot. Go to /usr/lib/merge and run the script final_remove.sh which will clean up the remaining merge stuff not removed by custom. Also remove all personal merge data using: rm -r /usr/*/.merge and rm -r /usr/*/win Reinstall SCO Merge 5.7.23 and reboot. Using X-Windows and logged in as root, install DOS from your favorite version of Windows (98 or ME). Be absolutely sure you're using a full retail or OEM version on CD. Upgrade versions are simply not supported. If you're unsure of whether you have an upgrade version, try to boot from the CD on another machine. Upgrade versions of Win9x don't boot from CD. Also as root, install an image of the same Windows CD to make user installation simpler. Then, as an ordinary user, install Windows from that CD image. If for some reason this step fails, install Windows directly from the Windows CD instead. Document every step. You should get no errors at any step above. Bob
Is SCO Merge interfering with the serial port? (SCO Unix)
From: Bela Lubkin <belal@sco.com> Subject: Re: Merge Installation/Configuration Problem on OpenServer 5.0.7 Date: Sat, 9 Aug 2003 00:58:39 GMT References: <20030808013912.GQ24551@sco.com> Transpower wrote: > >Another way you can disable USB is this. Boot with: > > > > Boot > > : defbootstr disable=usb_uhci,usb_ohci,usb_ehci > > > >Then try to access the serial port. If the problem was due to an > >interaction with USB, the serial port should now work. If it panics the > >same as before, it probably isn't USB. > > Unfortunately it panics the same as before, with USB disabled (but it was nice > not seeing the USB error messages). We'll debug the USB stuff later when the > new computer gets here. (Actually one of my reasons for upgrading to 5.0.7 was > to be able to access my USB devices.) Ok. Start by seeing whether they're problematic on the new system. > ># crash # not -d /dev/swap > > > ts f008cf75 > > > quit > > > >What's the symbol+offset? > > The symbol + offset: _M_mdhi_com_for_mrg + 0x9 Now we're getting somewhere. That symbol is part of NeTraverse Merge. Now I'd like you to remove Merge (again), boot up, and see if you can successfully access the serial ports. By "remove Merge" I mean "boot from a kernel in which no Merge device driver code is linked" -- if you have one of those laying around you don't need to actually go through the gyrations of removing Merge. > > One: > > > > # scodb -d /dev/swap > > scodb> stack > > > >Two: > > > > # sysdump -i /dev/swap -a > > These didn't come back with anything intelligible. We will have to keep > working on this until the matter is fixed. I have clients on 5.0.2, 5.0.4, > 5.0.5, 5.0.6--I cannot "upgrade" them until my own 5.0.7 system is working > properly, including the Calendar. I don't expect to have anything to do with fixing the calendar problem. The advice to try it on a not-upgraded system sounds very good to me. Suppose it works: then you have a baseline for comparison. You can compare the calendar-related files in the doesn't-work-upgraded system and the works-new-install system, mimic permissions, copy file contents, whatever it takes, until both work. >Bela<
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
Inexpensive and informative Apple related e-books:
Take Control of OS X Server
Yosemite Crash Course
Take Control of Upgrading to El Capitan
Take Control of Numbers
El Capitan: A Take Control Crash Course
More Articles by Anthony Lawrence
Find me on Google+
© 2013-07-17 Anthony Lawrence
Printer Friendly Version
SCO Merge Notes Copyright © July 2013 Tony Lawrence
Have you tried Searching this site?
Support RatesThis is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.
Contact us
Printer Friendly Version