IBM DOS and Windows research thread

[os2fan2]

IBM 5.00

Currently I hold five different versions of this DOS, as well as a 'files by date' sort. Although it's the same code base as Microsoft's version, it made it to market in a number of seperate ways, hence the multiple versions. The list is of the fixes listed in UR37837, for which files are held.

Code: Select all

910509  IBM 5.00 PS/2 and ROMBASIC  qb v0
910718  UR35033 IFD xcopy replaced later.
910816  UR35423 CSD (fixdos5.zip)  qb v1
911025  UR35748 CSD (OS/2 Level)
911129  UR35834 CSD (DOS5EIU.EXE)
920228  UR36603 CSD (PCDOS 5.00.1)  qb v2
920529  UR37250 IFD PS/1 fixes  qb v3
920911  UR37387 CSD (final = 5.00.3)

920911 csd applies to 5.00 and 5.00.1, is the filal update to any of the DOS versions in this list. It has a date later than those on 5.02 release 920901, the final CSD is mostly made of earlier files. This is listed as 5.00.3 in my catalogue.

920529 is an IFD (which soulds like an internal fix diskette), a DOS that exactly matches this version appeared on a PS/1. I can't determine the date on this, but the yoursoftware program is vers 1.0, so we will call this PS/1v500 (The other english recovery diskettes I have for a PS/1 is PS/1v621, with MSDOS 6.21.

920228 is concurrent with the release of DOS 5.00.1, but the main differences is that this CSD retains the earlier copyrights and dates (1991-1991), rather than 1991-1992.

911129 is the date of DOS5EIU, but the EIU does not contain all of these files. We suspect that a CSD came out at the same time. The EIU is an 'enhanced install utility', which means that it's a 'disk 0' for any previous DOS 5 release. This disk has qbasic.exe, autoconf.exe, meutoini.exe, and setup. In essence, it copies these files in place of those on later diskettes. The DOS installed with this works on an ordinary VPC system.

The earlier directories only replace four files (sys, qbasic, and xcopy, with ega850.cpi evidently correcting the code page in that DOS. This is the version that OS/2 DOS is based on.

MARKER FILES

These are files that can persist from version to version, the various replacements being to whether chanels have reacted to particular bug fixes. Things like whether the € sign appears in a Windows font, or whether calc.exe gives 3.11-3.10 = 0.00, are tests for this. The same file can thus persist in multiple versions of the OS, or other distributions.

BASICA.

The 8-bit machines of the 1980s were driven in the most part by some form of ROMBASIC, Magazines published basic code, and you would expect your fancy 16-bit computer to emulate the same code as the 8-bit stuff, rather like the current 32-bit stock runs 16-bit DOS and Windows, and the 64-bit stuff runs 32-bit code.

IBM had BASIC in ROM, which means that its basic interprer could be smaller than the Microsoft one. But the decision was made in OS/2 days to move rombasic from rom into basic.

IBM compiled its own source for basic up to version 3.00. The marker for this is to start basic, and ask PRINY RND . IBM code prints 0.7151, whereas MSFT prints 0.12135. DOS 3.0 was the last version to come with the sample files that started with DOS 1.

IBM basic 3.31 appeared in OS/2 1.0 to 1.2, replaced by version 3.4 for the 1.3 release. This is dated 910215, is identical to the releases in 500, 500.1, OS/2. The version in 5.02 is different remix. The rom-only version differs by the version-numbers from 3.40 to 4.00. BASIC made its way from OS/2 to DOS.

GWBASIC last appearences are 3.20, 3.22 and 3.23. these also appeared in Microsoft OS/2 v 1.x releases.

QBASIC.EXE v 1.0

IBM released four versions of this which met different fates.

v0 is 252317 bytes, attached to rombasic
v1 is 252283 bytes, survives in OS/2 dos.
v2 is 252235 bytes, survives in DOS 5.00.1 and DOS 5.02
v3 is 252219 bytes, survives in PS/1v500 and the final CSD.

[os2fan2]

IBM Windows 3.10 does not differ too much from Microsoft's version. A few readme files, the vgalogo splash screen, and the mouse driver (the DOS 5.02 version). The PS/1 that I extracted the DOS of the previous post uses this version, but I have not put it on the rollers to see what it's made of.

The customisation of Windows by OEM, is done by super-imposition, or 'copy-over'. So their own logos and wallpapers etc, are copied over a functional windows. Since the mouse-driver is 8.20, I decided to see if this can be installed by copyover. On the diskette, run the Win311 expand -r option to expand the files, and then simply copy mouse.drv into the system directory, and the four POINT*.* files into the windows directory. Installed.

For one or two applications, it's not much sense installing it like this. But a batched install can install nearly sixty programs and settings by simply copying the files. The copyover works for things like wallpaper, screen savers, control applets and dependent exe files, copyover drivers (eg mouse.drv of the previous para). and various upgrades (winos2 fileman to wfw fileman).

Even the likes of programs needing registration through .reg keys works a treat. One can install things like vbrunX00.dll, the various ctl3d*.dll, and bwcc.dll, at the same time.

Even if applications are not stored in the Windows directory, we can still copy INI files to it.

A reduced Windows

Reducing the Windows set can be done through setup. In essence, we delete all of the driver files, as indicated in the IBM PS/1 layout. The 'delsame' utility works here, since it will not delete files that have a different crc, even if the size is the same.

Even so, it is still quite noticable going through an install set, when the letter is late in the alphabet, and there are lots of folders. The Windows setup directory is about as big as it comes.

One idea is to create directories disk1 to disk?, and edit the setup folder by replacing the dot ., with ..\disk1 through to ..\disk?, and copy the diskettes into separate directories. The installation moves along quite a hoot.

You then install Windows. As files are asked for, you copy these onto the install directory, and tell windows to try again.

It's better to split the printer drivers to a separate folder. These make up more than half of the driver directory.

Installing other vxd files

The prototypes for win.ini, system.ini and control.ini are named as *.sr_ files, expand to *.src files. If you plan to integrate the likes of vshare.386 wps.386, or wqghlt.386, add extra colour-schemes, or the like, these are the files to edit. You can overcome annoyances with little effort here.

You can customise the default options of setup to match your preferences. For example, you can insert the UK keyboard rather than the US or us international. You can include international english rather than US english. (You could be evil and edit the strings to say 'traditional english' and 'simplified english'.)

[os2fan2]

I installed the Windows 3.11 addon from an old connectix setup (available on the net as Win3.1 Addons).

These addons are a replacement mouse and timer. They actually work under vpc2007, lest you don't mind the cursor as a garbage icon. The installation suggests it ought be an extension of the existing windows mouse, and this is shown in that the mouse-dialog still shows the original mouse pointer dialogs.

Outside that the cursor is garbled in windows, you can move the mouse on and off the vm.

The other two things I've tried are syshook.drv (a replacement system.drv that divvies up low memory like 1Mfort), and an vesa power screensaver, which puts the machine into power-sleep mode when activated. You select it as a screensaver, and the machine goes numb in power-save mode. A click or key wakes it.

The continuing story of maintini is that i found a whole directory of newer versions on my l: drive, including ones that can edit groups. However, the group icon is a matter of turning the group into an ini file, and editing that. We ought use dde script to do this. This automates the creation of groups in a way that you can dismantle and alter the groups into your own need.

[os2fan2]

I updated DOS 5 to DOS 6.30, this runs faster from a directory on the local vm. For this experiment, we used a vm with OS/2 boot manager installed. It passed that test.

For the exercise, I used the preload version, with the compressed updates applied, and setup1.ovl copied from a upgrade install.

The Windows project continues.

The idea is to simply install windows with just the screen-savers, sound files, and readmes, and run a form of Norton's "Instdos.exe". This is what Norton utilities uses to create the icon-files for their DOS utilities. INSTDOS can be fetched from the likes of norton utilities. Get the .EXE and .INF file.

The group-adding consists of running a number of external utilities, and fixing up the win.ini and system.ini files to match. The utility here is maintini, but we shall start with the groups.

The command layout is fairly intuitive.
item =
name (one place),
cmdline = pathto, exefile, params,
icon = iconfile, pos,
workdir = path,
mini = [0|1], run minimised?

A lot of stuff defaults. exefile defults to name.exe, or if exefile is just an extension, name.[ext]. See for example, welcome in the windoze group.

The idea is to bunt as many exe files into the \win\sh directory, and not install them in the windows setup.

The REXX i used for this is the PC-DOS 7 rexx.exe. You could use rexx from regina, or quercus rexx. In that case, you would just run a batch file in take command for both the batch-build and for the dde session.

Code: Select all

/* New groups for Win31 */
/* Wendy Krieger - an OS/2 fan 2 */
/* Part 1  Setup and define Groups */

base = 'c:\win'
infdir = 'c:\use'
utils = base'\utils'
icon31= base'\icon31'
inidir= base'\ini'
ifc = 'winicons.dll'

/* item  name,  cmddir,cmdname,cmdargs,  iconfile,pos, workdir, startmin */
/* rexx variables: quote or defined. */
call title 'Creating New Groups'
call group 'Main'
call item 'File Manager',,'winfile.exe'
call item 'Control Panel',,'control.exe'
call item 'Print Manager',,'printman.exe'
call item 'Dos Prompt',,'dosprmpt.pif',,ifc,9
call item 'Dos Window',,'dosw.pif',,ifc,10
call item 'Regedit',,,'/v'
call item 'Clip Viewer',,'clipbrd.exe'
call item 'Inst Icons',inidir,'instdos.exe'
call item 'Your Software', utils, 'yoursoft.exe'

call group 'Win-OS/2'
call item 'Calculator',,'calc.exe'
call item 'Calendar'
call item 'Character Map',,'charmap.exe'
call item 'Clock'
call item 'Media Player',,'mplayer.exe'
call item 'Music Box',,'musicbox.exe'
call item 'MSDOS'
call item 'Notepad'
call item 'Object Packager',,'packager.exe'
call item 'Paintbrush',,'Pbrush.exe'
call item 'Recorder'
call item 'Sound Recorder',,'soundrec.exe'
call item 'Terminal'
call item 'Write'

call group 'Games'
call item 'Solitaire',,'sol.exe'
call item 'Minesweep',,'winmine'
call item 'Reversi'

call group 'StartUp'

call group 'Windoze'
call item 'fileman',,'winfile.exe'
call item 'welcome',,'.hlp',,ifc,14
call item 'ComRef',,'xview.exe','doscmd+dosaddin',ifc,1,infdir
call item 'Instdos',base
call item 'MsInfo',utils
call item 'TakeCmd',,'tcmd'
call item 'WinCmd',base'\cmdr','tcmd16.exe'
call item 'Saw', utils
call item 'IconMan',icon31
call item 'IconStudio', icon31, 'icstud16.exe'
call item 'WPS',utils
call item 'Undelete',,'wnundel.exe'

call isdone
exit


/*  This is the magic defaults here.  You don't need to understand this */
/*  Here be dragons */
/* Part 2  Routines to build Setup Strings */
item: ; parse arg n1, c1,c2,c3, i1,i2, w1, m1
s2 = n1; call ddeline '[ReplaceItem('s2')]'
if c2 == '' then c2 = n1'.exe'
if left(c2,1)=='.' then c2 = n1 || c2   ; /* s2 = iconname */
if pos('.',c2)== 0 then c2 = c2'.exe'
if c1 == '' then c4 = c2; else c4 = c1'\'c2
if c3 == '' then s1 = c4; else s1 = c4 c3; /* s1 = cmdline */
if i1 == '' then s3 = c4; else s3 = i1   ; /* s3 = iconfile */
if i2 == '' then s4 = 0; else s4 = i2    ; /* s4 = iconpos */
if w1 == '' then s7 = c1; else s7 = w1   ; /* s7 = workdir */
if m1 == '' then s9 = '' ; else s9 = ',,1' ; /* s9 = startmin */
/* unused: s5=xPos, s6=yPos, s8=HotKey */
call ddeline '[AddItem('s1','s2','s3','s4',,,'s7||s9')]'
return

group: ; parse arg group
if oldgroup \= '' then call ddeline '[ShowGroup('q(oldgroup)',7)]'
oldgroup = group; call blankline
call ddeline '[CreateGroup('q(group)')]'
call ddeline '[ShowGroup('q(group)',1]' ; return

q: ; parse arg u1; return '"'u1'"'

/* Part 3  Routines to make outfile */
title:
parse arg t0
parse source . . instrexx
instrexx = reverse(instrexx)
parse var instrexx . '\' instdir
thisdir = reverse(instdir)
instdosf = thisdir'\instdos.inf'
parse var instdir . '\' instdir
thisdir = reverse(instdir)
oldgroup='' ;
'del' instdosf
call stream instdosf,'c', 'open'
call lineout instdosf, "TITLE:" || t0
call lineout instdosf, "INITIATE:Progman,Progman"
call lineout instdosf, "REM: Created in REXX"
ddecmd = 'EXECUTE:'
return

ddeline: /* print outcard */ ; parse arg outcard
call lineout instdosf, ddecmd || outcard ;return
blankline: /* print empty line */
call lineout instdof, '' ; return

isdone:
call ddeline '[ShowGroup("'oldgroup'",7)]'
call ddeline "[ExitProgman(1)]"
call lineout instdosf,"TERMINATE:"
call stream instdosf,'c', 'close'
say Instdosf 'recreated!'
return

[os2fan2]

I bought a set of five diskettes marked 'IBM Windows 3.1', these have the same layout as the one circulating on the net, but proper MS-DOS 4.00 boot sectors, rather than winimage boot sectors.

Diskette 4 has something like 133 bad sectors on it, but I was able to recover enough information to fab one from a Microsoft set. (It amounts to deleting 'mouse.co_' and putting a new one on.). The wreckage of diskette 4 will also be included. Although four files were completely destroyed, there were 27 further files that had wrong sectors added in. I used winimage to select the files for extraction, and delsame for comparison.

For example, the mouse.co_ file has a later date than windows, and expand -r mouse.co_ gives mouse.co as in DOS, rather than "mouse.com". IBM used variously their own 8.20, or briefly in DOS 6.3, 9.01 for the mouse driver. The mouse driver was recompiled 8.20 for version 7.0, 2000.

Against the other diskettes, they all equal out running delsame (size, crc), against the diskettes 1-3, 5 and the files extracted from the earlier copy.

The plan is to eventually upload these, in something that resembles the beta-archive format.

So the four good diskettes give rise to files exactly matching previous examples of IBM Windows, and the fourth disk is constructed from MS-Win31 masters, to exactly match the wreckage of the fourth diskette.

[os2fan2]

IBM DOS 7.1

This is a more recent compile of PC-DOS 2000, and because it supports fat32, and has something like ten different versions, it was interesting to see if there is any particular marker. A lot of utilities have the mouse, and it serves to distinguish IBM from other dos versions using ibmbio and ibmdos.

At the moment, from DOS 5.02 onwards, except some 6.30 versions, PC-DOS has come with one of the two IBM mouse builds. They are both the same size: 37681 bytes. This file exists in two versions, the second version appears in DOS 7.00, and DOS 7.10.

The drivers like mouse, himem, etc, all seem to work quite well under even PC-DOS 5.00 (fully updated). These are relatively easy to slipstream into DOS and Windows. You compress the file by compress v2 or v1, and add the files to the distribution.

[os2fan2]

PC-DOS 7.1

It turns out that build 1.16 is a marker release for DOS 7.1. It's not an easy find, but it turned up after I released the first compilation of PCDOS 7.1 files. A number of sites quote the readme file as to where the sources were.

ICONS in the Betas.

Both PC-DOS 6 and 7 betas have different icons to the releases. DOS 6 has DOS in a circle on a black background, like the logo on DOS 5 boxes. It's in the bitmap collection as IBMDOS5.ICO.

PC-DOS 7 beta (both versions), have the PC-DOS 6 icon IBMDOS6.ICO, (the one much used in Warp3 for DOS sessions), as well as a goldy coloured book.ico.

SLIPSTREAMING DOS 7

A plan exists to build a slipstream file to add files to PC-DOS 2000 or PC-DOS 7. These are the updated leftovers from PC-DOS 6.3 and 5.00.3 (final update level code for 5.00). The final version of qbasic.exe runs a lot nicer in both vista 6.1 and OS/2 acros 5.0x.

[os2fan2]

More news.

Much of the stuff has been gathered into an OpenOffice document, centred on PC-DOS, but rambling into OS/2, MS-DOS and Windows as the need arises. Experiments have been running since I got my hands on this stuff, so some of my old thinking can nicely be contrasted with things IBM did.

MSDOS 5.00a is 1/3 new.

As part of comparing PC-DOS 5.0, I loaded MS-DOS into the roller to see what can be seen. From looking at the official updates, you would suspect one or two files were updated. In fact, 33 were changed from DOS 5.00 to DOS 5.00a. I compared the list to the table from PC-DOS, and there are a lot of similar names there.

ET came home.

I added a section on the E editor, and rustled up all of the copies from different versions. It turns out that the mystery files in the E 3.05 version from Winworld, is nothing less than an archive of the source for E, complete with unpacker and with the tokeniser. In short, you run these two commands:

1: loadram e3.fls r:
2: et e

The first command should point to an empty disk. r: is my ramdrive. This unpacks 'two files', ie a directory and a file.

Changing to r: reveals a directory \temp, full of .e files and a program et.exe. Running et e gives a new file e.ex, which is identical to the E 3.05 release.

The hint here is that E3.FLS looks like an archive tape: a directory, followed by uncompressed files.

[os2fan2]

More news.

Much of this comes from an informed play-around with various IBM stuff. Been a big fan since DOS 5 days. This is research for the forthcoming PCDOS.PDF.

Y2KFIX

I've dismantled the Y2K fix for PC-DOS 7.0. It contains 30 files that are exactly equal to the 2000 release, along with a number of setup utilities. If you are using 2000, you already have the files. POWER is reappearing here as a new fix, but all of the rest of the files in the PCDOS7 fixes have to be applied to 7.00.

XDF disks

The http://16bitos.com site lists the disk listing of the XDF floppies on DOS 7 as if they did not load xdf.com, which allows DOS to read these disks. The following are the actual files on these diskettes.

Note we use v 2.00 rather than 2.10, since 2.00 behaves correctly under OS/2 and DOS, where 2.10 is a bound DOS/Win32 program, which OS/2 tries to load under Win-OS/2.

Code: Select all

Extract NT - Extract file in wImage - V 2.00 (c) 1991-94 Gilles Vollant

image file : dos70_2.xdf  label : DISK      2
DOS1                       522033  94.11.17  13:00 
DOS2                       479333  94.11.17  13:00 
SHELL2                     190695  94.11.17  13:00 
PEN1                        84299  94.11.17  13:00 
WUNDEL                      99615  94.11.17  13:00 
BACKUP1                    409193  94.11.17  13:00 
1785168 bytes in 6 files, 75776 bytes free

image file : dos70_3.xdf  label : DISK      3
SHELL1                      48117  94.11.17  13:00 
AV2                        183919  94.11.17  13:00 
WBACKUP1                   460201  94.11.17  13:00 
BACKUP2                    399521  94.11.17  13:00 
STAC2                      690149  94.11.17  13:00 
1781907 bytes in 5 files, 79872 bytes free

image file : dos70_4.xdf  label : DISK      4
DOS3                       406155  94.11.17  13:00 
PEN2                        18878  94.11.17  13:00 
PCM2                       184320  94.11.17  13:00 
WBACKUP2                   464006  94.11.17  13:00 
STAC3                      685829  94.11.17  13:00 
1759188 bytes in 5 files, 102400 bytes free

image file : dos70_5.xdf  label : DISK      5
REXX                        91718  94.11.17  13:00 
AV1                        252095  94.11.17  13:00 
WBACKUP3                   464538  94.11.17  13:00 
STAC1                      526718  94.11.17  13:00 
DOS4                       410191  94.11.17  13:00 
WGRP                         8777  94.11.17  13:00 
1754037 bytes in 6 files, 106496 bytes free

[os2fan2]

Windoze
----------

As Windows 3.x goes, it's a relatively easy exercise to modify the setup. It is controlled by a number of text files, and these can be uncompressed on the setup. The process of adding bits and pieces is well documented in the Win31 resource kit, along with what is safe to delete. If you routinely rebuild the system, a modified setup will get all of your settings back without having to re-enter them, and assorted OEM drivers etc can be installed at install.

Lessons learnt from this project can be applied to modern operating systems. The bulk of my apps sit in a different directory, the various settings are handled by a couple of batch files, and some unusual utilities. This is because the setup extras are kept completely up to date.

v1.

The initial setups were simply modifying the defaults, such as the install directory of c:\winos2. It eventually grew into a project where the current drivers for the machine were in the setup. At this stage, we're just feeding disks one after the other into the slot, and getting a custom Windows 3.1, in glorious 256-colour etc.

Of course, you do the fancy things, like change names. "Installing Win-OS/2 v 3.11" OS/2 for Windows actually reads this, and decides what your windows version is known or not. This one is not a known version. Then there are the wonderful string-hacks, where one fiddles around with preserving period memes. I have a 'winver', that calls itself "Windoze", and "Windows for Warehouses", and "Win-OS/2", all derived from various versions of Windows.

The trick is also to see how much win-os2 stuff can actually be squeezed into Windows. It started with the apps and their dlls. Shell.dll and the two ole dlls complete the picture. This is the source of the Help-About dialog, although its populated from Windows itself. progman comes from OS/2, but printman and winfile are the Wfw versions. msdos is put in there, for a lark. In essence, it's the program you go hunting the instdos or whatever down with.

Installing by disks did not last a great deal. The first cdrom was cut in 95, the cdburner was added two years later. Installing stuff from the cdrom became the norm, the computer was reformatted on return from the first burn, and up and running in 30 minutes.

Windows 3.1 will run quite easily if you do an admin install. The files are expanded, and become the system directory. The windir can be placed on a floppy disk, involves about 14 K rar and copied from the install disk. So a lot of the early cdroms have a directory S:\WINDOZE with the latest build of directory.

v2.

To install the apps, this was done by having the applications pre-installed, and running a few batch files. Basically, the apps went into a subtree \win, there is a directory \win\win\system, you just copy this into the freshly minted windows, a directory \win\sh which is pathed, and other directories for non-pathed stuff. The directory \win\ini contains the various customising utilities. A copy of the norton utilities INSTDOS.EXE, and a rexx script to make the matching .INF, completes the picture.

The whole thing can be made much faster if one installs nothing extra except the sound files. All of the various exe files are moved to \win\sh, and are unchanged from install to install.

v3.

The latest undertaking is to speed the installs without bambi's (smartdrv) help. The trick is to make the directory as small as possible. And to this end, IBM have done the necessary work to show how it is done.

[DOS]

To install the apps, this was done by having the applications pre-installed, and running a few batch files. Basically, the apps went into a subtree \win, there is a directory \win\win\system, you just copy this into the freshly minted windows, a directory \win\sh which is pathed, and other directories for non-pathed stuff. The directory \win\ini contains the various customising utilities. A copy of the norton utilities INSTDOS.EXE, and a rexx script to make the matching .INF, completes the picture.

I'm sure this method is faster than actually running the installers for software, but am I correct in thinking that in general it requires you to figure out what the software does at install time somehow, e.g. working out what .INI files got created? It seems like software that wants to update CONFIG.SYS and AUTOEXEC.BAT would be quite a pain too?

I've had a play with "just" automating installers so that I can potentially repeat the same procedure with a different version of the installer (assuming they have the same prompts). That way they can do whatever they want to the machine. Admittedly I sometimes like to know exactly what they're doing but for now this is for somewhat throwaway virtual machines. Of course that kind of automation isn't necessarily trivial, but it's not too hard.

[os2fan2]

The individual apps are analysed as they are installed new. The various modifications are then included into the master copy of global setup.

Some programs do ask to be installed into the windows directory, when all that is needed is that they be in path. If a program requires to be in path, then the files are stored in a single directory and copied to path, dpath, libpath, etc. The copy is then run. Programs are allowed to save to autoexec.bat and config.sys, but syscopy.bat backs up and restores these files, optionally touching them. (If you don't do that, than programs like QEMM will 'update' these to the latest.

The master files are updated programically with REXX etc. In practice, these are kept in a single script file, the varous output files are governed by a central .ini file. This can create the files in situ.

Of course, playing around with installs like this is what got me a job in Defence.

[alecu]

Also, i am curious of the difference between Windows ME's MINI.CAB DOSX.EXE and Windows 98 MINI.CAB DOSX.EXE? WHy they are different? Some new code? I want to know.

[os2fan2]

The REXX script in post 3, is being revived to create a new folder in the 'Start Menu' of Windows 7.

The variables are the same, and the first part of the code simply fills in the missing defaults. We plan to reorder the options, because 'default dir' is more common than 'icon-file/pos'. So the new order becomes n1, c1, c2, c3, d1, i1, i2, m1. The shortcut name is n1. The command line is "c1\c2 c3" run in d1. i1 can variously be a file in c1\i1 or in some iconfile or icondir. i2 is the position. We swap d1 with i1,i2 because it's more common now. The default start point for command-line processors is given as the location of where the shortcut is. $p$g is nearly as long as the screen.

The order can remain consistant, because we create a second run of variables s1-s9, which are the options of the command we plan to run. So the comments will give, for instance, how we derive s3 from the imput variables.

A novel feature is we can use REXX to test if constructed c1\c2 exists, either by way if fileexists or findfile. Also, we can pull things out of registry to create greater portibility.

The thing is continiously kept up-to-date, because we use a part of registry in a day-to-day tool.

Code: Select all

@echo off
:: cd shell folder.
if /i "%1"=="/?" goto :ttyhelp
if /i "%1"=="" goto :ttyhelp
set zdir=
set zshf=Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
set zapp=Software\Microsoft\Windows\CurrentVersion\App Paths
if /i "%1"=="/m" goto :hklm
if /i "%1"=="/u" goto :hkcu
if /i "%1"=="/w" goto :hkwe
if /i "%1"=="/i" goto :image
if /i "%1"=="/a" goto :happ
set zcmd=chdir
set zhere=%*
if "%1"=="/o" set zcmd=open
if "%1"=="/o" set zhere=%zhere:~3%
conset /q /k zdir=HKLM\%zshf%\%zhere%
if not "%zdir%"=="" goto :doit
conset /q /k zdir=HKCU\%zshf%\%zhere%
if not "%zdir%"=="" goto :doit
conset /q /k zdir=HKLM\Software\Wendy\Folders\%zhere%
if not "%zdir%"=="" goto :doit
goto :end

:hklm
shelexec reg:hklm\%zshf%
goto :end
:hkcu
shelexec reg:hkcu\%zshf%
goto :end
:hkwe
shelexec reg:hklm\software\wendy\folders
goto :end
:happ
shelexec reg:hklm\%zapp%
goto :end
:image
set zdir=Microsoft\Windows NT\CurrentVersion\Image File Execution Options
shelexec reg:hklm\software\%zdir%
goto :end

:ttyhelp
echo CDF changes to a directory stored in registry, or shell folder.
echo.
echo   /o  Open the named folder in explorer.
echo   /m  Display the shell folders in the machine tree
echo   /u  Display the shell folders in the user tree
echo   /w  Display the folders in HKLM\Software\Wendy\Folders
echo   /i  Display the image settings tree for hacks etc.
echo.
echo  name  Changes to first instance of name in the above order.
goto :end

:dexe
goto :end

:doit
set zcxm=
if %zcmd%==chdir cd /d %zdir%
if %zcmd%==open shelexec %zdir%
:end
set zdir=

We use two programs here, shelexec.exe (from Microsoft cdroms), and Frank Westlake's conset.exe. Note the directories are not here but in registry. So if we add a directory, it is first added to registry from 0config.cmd, and then you can type things like 'cdf /o email', would open the directory that email downloads are placed, if one has set that up.

The options /m, /u, /w simply show the default machine, user and private special folders.

The directories created in the special folders is stored in a batch 0config.cmd, which is in the directory that "cdf setup" swaps to.

cdf /i simply opens registry up at a folder "Image File Execution Options", which is where programs that want to replace programs get installed. Sysinternal's "Procexp" installs itself there if you let it be taskmanager.

[os2fan2]

Not sure what MiniME's dosx.exe differs from the rest. Maybe a new bash at the code.

[os2fan2]

The fastest way to install a system is to use a recovery based on a previous build. This is what you do with Ghost, or a zip backup. Microsoft's WIM format used in Windows Vista is based on this method. It does not allow any flexibility to change things later on.

Windows 9x and OS/2 use file packs, but there are a lot of options for installing things and variations. On the other hand, setup builds the registry, the ini files, and the boot text files to match options you have pre-selected.

The method that I am playing around with is that you can move the programs and data around the system, and run a multi-application setup. So the idea is to capture what an application does in setup, and store that information in various files that can relink it to a new install. I still have saved print-jobs (from fineprint) from three installs and two computers past. The WinEdt spell-check is saved from version to version, load to load. It is also migrated to the Office 12 setup.

As shell scripts go, REXX is the magic. It is very small. Most installs fit on a floppy disk. Yet it has wonderful string handling (including binaries), and bignum calculations, so you can feed programs like 'factor' values derived from polynomials. Being a mainframe origin, it's not really good at globbing, though, though maybe i have not looked into this.

Currently the programs are written in Win32 CMD language and a handful of unique utilities. But the plan is to migrate this to ReginaREXX.

[os2fan2]

http://www.os2fan2.com/pcdos.pdf is the sort of way I am thinking of preserving this info.

It covers in essence when computers went from megabytes of diskspace to a gigabyte or so. 1992-1998, more or less.

Some of the information comes from documents that I was using at the time, such as the system readme files that I collected all sorts of things to. I mainly avoided MS-DOS, the hundred dollars went better to 4dos than dos6. And then some more on Quercus rexx. a kind of dead end, because rexx veered slightly from this.

Still, trivia like Smartdrv 4.20 (which has a section to itself), makes more sense if one places it in the context of eyes-off-my-source.

Enjoy

[os2fan2]

At the moment, effort is given to trying to integrate Win-OS/2 files into windows, and produce a set of diskettes. Part of the plan is to simplify the install of video drivers, which mostly are distributed with Windows font files, into the build.

So, eg 'disk1' = driver, disk2 = files refered to in driver section, disk3 = b,e,f fonts.

Much of the work is being done by 'delsame', that is, we subtract files in A from set B. Since i use a UK keyboard, and use the 'traditional english' language file, the necessary customisations for NLS will also be shown.

[os2fan2]

Part of the research here is the structured rewrite of the MS-DOS help file. This gives an chance to look at various things more exactly.

Currently, there are seven english versions of QBASIC 1.0, and one of 1.1. The Windows NT version is neither the one in 5.00 or 5.00a, but a different (later) compile.

I've added a few more operating system releases into the version table.

I dismantled the Windows 3.1 setup into 'section of first appearence' to see if anything new can be found there. Some new things cropped up.

The textmode section has a 'blowaway' section, which means that what is after it (or prehaps before it), is blown away. Yet the DOS setup and the fonts are scattered on both sides of it.

[asad10]

http://www.os2fan2.com/files/pcdos.pdf

Gives 404.

[os2fan2]

Thanks. It's http://www.os2fan2.com/pcdos.pdf

[os2fan2]

M57 - Model 57 recovery disks.

The cdroms are downloaded from archive.org by searching for "PS/2 Ultimedia" While there are three iso files in the set, two of these are 'select' diskettes, in other words, key-locked stuff as in the pre-download era. It is to the third one we turn our attention to: IBM_UCD_101.ISO.

This contains driver directory, installs for OS/2 2.0, Windows 3.1, WinMME, and MMPM, along with the HYPERguide. It aslo contains a backup set.

• Drivers: various machine specific drivers
• Guide: The WinMME Hyperguide.
• MMPM: Just the two-disk version. No cd-rom samples.
• OS2SE20: This is a full OS/2 + Win30 setup, despite the directory name.
• WinMME: A three-diskette setup of MME files for 3.0 and early 3.1
• WINSETUP: An unmodified version of the Windows 3.10 setup.
• BACKUP.001: A backup of most of the hard drive for reinstall.

WinMME is a 5M directory layout that comes from three diskettes. The resulting files are in true PCC fashion, dated as recieved: ie you can see what has been updated. This is its splash-screen:



The usual array of files are there: almclock, mplayer, msd, musicbox, soundrec, verinfo. The screen savers as in the Tandy set are there. The sound files indluce the 3.10 files. In essence it's a 3.00 version of what the MMPACK is 3.10.

BACKUP

I unpacked the backup files, onto a ramdisk, to see what might be seen. It is in essence, a restore set.

• DOS: PC-DOS 5.02. The Readme is much larger, and there are a few file changes (setver, basica). ibmbio and ibmdos did not make this cut.
• CDROM: Driver and cd-player for DOS and for OS/2.
• MMOS2: The installed OS/2. A handful of sound files.
• MWINDOWS: See note(1)
• OS/2: Just the two bitmaps (lighthou.vga and os2logo.bmp). see note(2).
• OS2\MDOS\WinOS/2: Has WinMME set up on it.
• OS!2_2.0_D : The desktop. All of the icons etc are saved in EA's, which are not reproduced here.

(1) To get this array, one installs Windows 3.0a, then Windows 3.1, and then WinMME. It has the 3.0 reversi, msdos, and five bitmaps, the winhelp is 3.07, not 3.10
(2) The OS/2 is a preload, but evidently installed from a cdrom. But they had no IDECDROMs then.

QBasic is the 1 rebuild in OS2\MDOS but the 2 rebuild in 502.

Mouse has the IBM version 8.20 in DOS, but the root directory and windows uses the MS-DOS 8.20.

[os2fan2]

I started to see if it were possible to compose diskettes to match those which were not supplied. The thing is that this is a PS/2 system, and the common boxes here are PS/1 style (IBM term for clone-computer).

DOS is pretty straight-forward. All that is needed is to supply the two missing files (ibmbio.com and ibmdos.com) from some other source. There are a few different files, but none suggest this. It looks like someone had yet another shot at building BASICA.COM. It does not agree with the one in 5.02.

OS/2 is version 2.00.1, which was never released as retail, and this disk represents one of the few sources of it as an install. It does install if you use diskettes from 2.00. but abends horridly at the end.

So I installed OS/2 2.00 and tried out the Win30mme thing. The setup is a DOS thing, and works quite well under OS/2 DOS. Then it starts windows, and that crashes horribly, but you can click your way through that part of the install. Restarting Win-OS/2 gives a correctly setup Win-OS/2 MME. You can even include sound, even where the OS/2 session does not have sound enabled.

Win-OS/2 3.0 is pretty terrible out of the box, and one would pine for at least some more utilities out of Windows 3.0. So i made a diskette with all of the missing files, and doggied up an INSTDOS.INF for the norton INSTDOS.EXE program. You simply expand the files to the winos2 directory, and then run a:\instdos.exe. It creates (supposedly) the required groups and icons.

The diskette contains win30 stuff, a winhelp calling itself win-os/2 help, the os2 1,3 pmfile (as pack.exe files), and the teletype driver for windows (to shut windows up on complaining about no driver). The win30 stuff contains the icons not found in winos2, and the bitmaps.

Code: Select all

aboutwep.dll   INSTDOS.EXE    PBRUSH.EXE     RECORDER.HLP   WEAVE.BMP    
BOXES.BMP      instdos.inf    PBRUSH.HLP     REVERSI.EXE    WINFILE.EXE  
CALC.EXE       INSTGRP.BAT    PIFEDIT.EXE    REVERSI.HLP    WINFILE.HLP  
CALC.HLP       MSDOS.EXE      PIFEDIT.HLP    RIBBONS.BMP    WINHELP.EXE  
CALENDAR.EXE   NOTEPAD.EXE    PRINTMAN.EXE   SOL.EXE        winmine.exe  
CALENDAR.HLP   NOTEPAD.HLP    PRINTMAN.HLP   SOL.HLP        winmine.hlp  
CARDFILE.EXE   PAPER.BMP      PYRAMID.BMP    SYSEDIT.EXE    WINVER.300   
CARDFILE.HLP   PARTY.BMP      RECORDER.DLL   TERMINAL.EXE   WRITE.EXE    
CHESS.BMP      PBRUSH.DLL     RECORDER.EXE   TERMINAL.HLP   WRITE.HLP    

winmine is from Wep 1, is the ringin here. aboutwep.dll is used by winmine.exe.

These files (except inst*.*) are packed with compress v1, /b /e /f src tgt, and unpacked with expand v2,10, using /r

Pifedit works, but OS/2 ignores the created files, and uses its own logic. Winver.300 is winver.exe, instgrp.bat is a dos7 rexx script. That REXX runs under DOS 5, but rexx.exe uses .bat, so 'rexx instgrp will make instdos.inf, as mentioned in a previous post.

You can set the full-screen wallpaper when there are bitmaps in the winos2 directory.

I tried out the PMFILE from OS/2 2.0 preview, it does not work under OS/2 2.0. So I reverted to putting the 1.3 version there and it works a treat. The three files go in different directories. The plan is to fiddle pack to replicate the built-in directories.

[Battler]

and the common boxes here are PS/1 style (IBM term for clone-computer).

Actually, the PS/1 was another IBM line of computers, some examples being the PS/1 models 2011 and 2133.

[os2fan2]

PS/2 were meant to replace computers with microchanel and whatnot, which IBM would collect the mechanicals.
PS/1 is a repetition of what everyone else was doing, because PS/2 did not go much past the keyboard and mouse in RL. You could call a compaq a PS1. Or MS-DOS OS/1. That's what the '2' was meant to mean. OS/2 on a PS/2.
They're kinds of computers.
Likewise, an MS-DOS compatible is a 1980s machine that can run MS-DOS, but not necessarily IBM graphics. You had to watch back then that you bought the game for the right platform: IBM invested heavily in developers for the IBM video.