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.
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 https://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.
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.
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<