[os2fan2]

At the moment, i am doing a Superimposition project, joining all of the Windows 9x cdroms into one. Because documentation points to directories like /OTHER/OLDMSDOS, i have been preserving the original tree.

This allows certian programs that do mods to the running copy of windows to work correctly.

In the main, there are very few places where different files occupy the same position: the main example is LFNBACK on the Win95 and Win96 disks. (Win96 was the original name for what became Win95B: i have an uninstaller from beta 189 that complains that there is no undo file for win96.

I currently have a script up and running, that converts MS-DOS 6.22 files to work under Windows9x. This is based on a fc /b between MS-DOS 6.22 and MS-DOS 6.21.

In essence, if you change something like 6 or 7 locations, you can convert 6.21 files to run under 6.22 (in fact, the binary equals of 6.22), and accordingly, the same script can change the DOS to 7.00, 7.10 or 8.00 for MS-DOS 7 or 8.

The whole script works successfully, and currently supports a number of commands (APPEND, BACKUP, EDLIN, EXE2BIN, GRAPHICS, PRINT, REPLACE, RESTORE, TREE). There are also others which do not need this patch: (COMP, DOSSHELL, FASTHELP, INTERLNK, INTERSVR, LOADFIX, UNDELETE).

I have tried these out on builds 0950, 1214, 2222, 3000, and all work ok.

It is also interesting that the main difference between the Win98SE and WinME versions of some of the DOS commands is exactly the same: this includes drivers like HIMEM.SYS, EMM386, which are essentially the same file reporting a different version number (only).

Script to follow when made 'user friendly'. You will need the DOS 6.22 files mentioned above (DOS 6,21 works as well, except for PRINT), some kind of TOUCH utility (to change the file-dates) and a copy of REXX, eg regina, to run the script.

Load all the DOS files into a directory, and run the command

rexx dosmake 1111

where 1111 is the build number. It supports 0621, 0622, 0950, 0951, 1111, 1212, 1214, 1998, 2222, 3000. You can see these from the file dates of your system.

When processed by this proggie, you don't need to use setver for any of them.

W

[somewan]

Do you really have to change 6-7 locations?

In my experience (and if I recall correctly), you only have to patch one byte - a conditional jump opcode - in order to get a program from an older DOS version to work with a newer one. At least that was true for tree.com.

[os2fan2]

You do have to patch a large number of positions. I did a fc /b between the binaries from 6.21 and 6.22, getting this result.

Comparing files 621\APPEND.EXE and 622\APPEND.EXE
00000298: 14 16
00000360: 33 34
000008DB: 14 16
00000D87: 14 16
00001AB9: 14 16
00001F59: 14 16
00001F7A: 14 16
00002003: 14 16

Comparing files 621\BACKUP.EXE and 622\BACKUP.EXE
00004259: 14 16
00004A9E: 14 16
00005506: 14 16
0000552A: 14 16
000088D8: 33 34

Comparing files 621\COMP.EXE and 622\COMP.EXE
FC: no differences encountered

Comparing files 621\EDLIN.EXE and 622\EDLIN.EXE
00001390: 33 34
000014E2: 14 16
00001B2F: 14 16
00001E3A: 14 16
00001F92: 14 16
000020C1: 14 16
000020E5: 14 16

Comparing files 621\EXE2BIN.EXE and 622\EXE2BIN.EXE
000002FE: 14 16
00000824: 14 16
00000984: 14 16
00000A76: 14 16
00000B31: 14 16
00001E14: 33 34

Comparing files 621\FASTHELP.EXE and 622\FASTHELP.EXE
FC: no differences encountered

Comparing files 621\GRAPHICS.COM and 622\GRAPHICS.COM
00001A93: 33 34
00001BE5: 14 16
000021ED: 14 16
00002211: 14 16
00002232: 14 16
000024FE: 14 16
00002668: 14 16

Comparing files 621\GRAPHICS.PRO and 622\GRAPHICS.PRO
FC: no differences encountered

Comparing files 621\LOADFIX.COM and 622\LOADFIX.COM
FC: no differences encountered

Comparing files 621\PRINT.EXE and 622\PRINT.EXE
00000012: 7B F3
00000013: FC 64
00000439: 33 34
00001EF2: 00 3C
00001EF3: 00 4D
00001EF4: 00 48
00001EF5: 00 3E
00001FB7: 33 34
0000212A: 14 16
000026D6: 14 16
0000281B: 14 16
00002899: 14 16
00002DFF: 14 16
00002F13: 14 16
00002FAD: 14 16

Comparing files 621\REPLACE.EXE and 622\REPLACE.EXE
000022FD: 14 16
00002B42: 14 16
00003162: 14 16
00003186: 14 16
00004BBE: 33 34

Comparing files 621\RESTORE.EXE and 622\RESTORE.EXE
000057CB: 14 16
00005F24: 14 16
000067E0: 14 16
00006804: 14 16
00009173: 33 34

Comparing files 621\TREE.COM and 622\TREE.COM
00001113: 14 16
000012CD: 14 16
000012F1: 14 16
000013BB: 33 34
000014FF: 14 16

The change from 33 to 34 is a copyright date, ie 621 has 1981-1993, and 622 has 1981-1994. The change from 14 to 16 is always in a byte-pair 06 14 to 06 16. The remaining ones in PRINT.COM are left alone.

I made a rexx script, that does size checks, and makes sure that all the affected bytes. So what it does is actually check that all of these bytes are the same, and that the size and name match. It does not do it if any bit is wrong.

You simply copy the listed files into some directory, and get hold of a rexx proggie, like REGINA or REGINALD or OOREXX, and run the command

regina.exe makedos.rex 2222

It will then make the file into dos 7.1, and stamp them with 2222.

I'm thinking of adding support for DOSSHELL too, so you can have an MS-DOS 8 dosshell.

/* REXX makedos */
/* a program to make DOS commands work under win9x

  This patches the files + changes the dates to work under Win9x.
  You need MS-DOS 6.22 files, or MS-DOS 6.21.  You don't need a
  complete set, it will ignore anything that fails.  Put all the
  files in the current directory, and run this script.  You will
  have suitably patched files.

  Be sure to read the comment at the end of the file, which deals
  with how to configure your touch utility.

  Wendy Krieger, an os2 fan 2.


*/
parse arg cmdtail; parse var cmdtail dosx .
parse source . . rexxname;
  parse value reverse(rexxname) with . '\' rexxdir;
  rexxdir = reverse(rexxdir)
dosc = 0; dosv. = ''; call seldos     /* load valid dos vers */
filec = 0; filed. = ''; call hackme   /* load files to patch */
do count = 1 to dosc; call getdosv count;
    if doscli = dosx then leave; end; if doscli = 9999 then exit
    say incard
do count = 1 to filec; call getfile count; end
exit


/* these are the supported DOS versions */

getdosv:   /* here we read the dosver to see what we get */
  parse arg dosn; incard = dosv.dosn;
  parse var incard doscli dosdisp dosyear doshex dosdate dostime dosname
  dosbits = x2c(doshex); parse var dosdate 1 fyear 5 fmonth 7 fday
  parse var dostime 1 fhour 3 fmin 5 fsec
  return
dosver:; parse arg tail; dosc = dosc + 1; dosv.dosc = tail; return
seldos:   /* cli  c date dver filedate-time Windows */
call dosver '0621 6 1993 0614 19940213 062100 MS-DOS 6.21'
call dosver '0622 6 1994 0616 19940531 062200 MS-DOS 6.22'
call dosver '0950 7 1995 0700 19950711 095000 Win95'
call dosver '0951 7 1995 0700 19960202 095100 Win95a'
call dosver '1111 7 1995 070a 19960824 111111 OSR2.0'
call dosver '1212 7 1995 070a 19970410 121400 OSR2.1'
call dosver '1214 7 1995 070a 19971126 121600 OSR2.5'
call dosver '1998 7 1995 070a 19980511 200100 Win98'
call dosver '2222 7 1995 070a 19990424 222200 Win98SE'
call dosver '3000 8 1999 0800 20000906 030000 WinME'
call dosver '9999 9 9999 9999 99999999 999999 Normal End'
return


/* These are the files in 0950/other/oldmsdos that need this fix, plus
   a number of files from the supplemental disk. and dos diskettes.  */


hack:; parse arg tail; filec = filec + 1; filed.filec = tail; return
hackme:   /* name       size  copyrt   dosversions  zero-based offset */
call hack 'APPEND.EXE   10774 c 0360 v 0298 08DB 0D87 1AB9 1F59 1F7A 2003'
call hack 'BACKUP.EXE   36140 c 88D8 v 4259 4A9E 5506 552A'
call hack 'COMP.EXE     13084 x Has no version requirement'
call hack 'EDLIN.EXE    12674 c 1390 v 14E2 1B2F 1E3A 1F92 20C1 20E5'
call hack 'EXE2BIN.EXE   8424 c 1E14 v 02FE 0824 0984 0A76 0B31'
call hack 'FASTHELP.EXE 11481 x Same as DOS 5 help'
call hack 'GRAPHICS.COM 19742 c 1A93 v 1BE5 21ED 2211 2232 24FE 2668'
call hack 'GRAPHICS.PRO 21232 x Needs no patching'
call hack 'INTERLNK.EXE 17197 x Needs no patching'
call hack 'INTERSVR.EXE 37426 x Needs no patching'
call hack 'LOADFIX.COM   1131 x Needs no patching'
call hack 'PRINT.EXE    15656 c 1FB7 v 212A 26D6 281B 2899 2DFF 2F13 2FAD'
call hack 'REPLACE.EXE  20274 c 4BBE v 22FD 2B42 3162 3186'
call hack 'RESTORE.EXE  38342 c 9173 v 57CB 5F24 67E0 6804'
call hack 'TREE.COM      6945 c 13BB v 1113 12CD 12F1 14FF'
return

/* data extracted from fc /b between MS-DOS 6.21 and MS-DOS 6.22 versions.
This command is zero-offset, while REXX is one-offset.

    c points to the end-year in the copyright, eg 1981-1994 (4)
    v points to the minor version of DOS, eg 6.22 (22)

  0....:....1....:....2....:....3....:....4....:....:.   zero-offset
  MS DOS Version 6 (C) Copyright 1981-1994 Microsoft Coproration
                 ^                      c^
  ....:....1....:....2....:....3....:....4....:....:.    rexx-offset

              0  1   2        zero-offset
  Hex code    06 16 .. ..
                 v
              1  2   3        rexx-offset

   MS DOS Version [7]   offsetc - 24
   1981-[1994]          offsetc -  2
   0x0616               offsetv

*/


getfile:; parse arg filen .; incard = filed.filen
  parse var incard filename filesize filehack;
  filename = strip(filename); filesize = strip(filesize)
  testsize = stream(filename, 'c', 'query size')
  if testsize = ''  then testsize = 0
  if testsize <> filesize then return  /* incorrect size */
  if left(filehack,1) = 'x' then
    do; call touch; return; end /* no need to hack */
  parse var filehack cmd1 offsetc cmd2 filehack;
    offsetc = x2d(offsetc);  hackc = 0; hackv. = ''
  do forever; parse var filehack thishack filehack; hackc = hackc + 1
     hackv.hackc = x2d(thishack); if filehack = '' then leave; end
  call stream filename, 'c', 'open read'
  outcard = left(filename, 14) || format(filesize, 6) || ':'
  outcard = outcard charin(filename, offsetc-22, 1)
  outcard = outcard charin(filename, offsetc-2, 4)
  hackk = 1; hacktest = c2x(charin(filename, hackv.hackk, 2)); hacktrue = 1
  do hackk = 1 to hackc; hackthis = c2x(charin(filename, hackv.hackk, 2))
  outcard = outcard hackthis;
  if hacktest <> hackthis then hacktrue = 0; end
  call lineout, outcard hacktrue
  if hacktrue = 0 then return /* here begins the patching */
  call stream filename, 'c', 'close'
  call stream filename, 'c', 'open write'
     call charout filename, dosdisp, offsetc - 22
     call charout filename, dosyear, offsetc - 2
  do hackk = 1 to hackc
     call charout filename, dosbits , hackv.hackk;  end
  call stream filename, 'c', 'close'
  call touch
  return

touch:
rexxdir'\touchx.exe /t' fyear fmonth fday fhour fmin fsec filename
return

/* You need to modify the touch command, to suit your own touch format.
   For a date 1957 July 23, at 10:08:42 am the values are

      fyear = 1957    fhour = 10     rexxdir = same directory that
      fmonth = 07     fmin = 08          makedos.rex is in.
      fday  = 23      fsec = 42      filename = name of file

  Stuff that has to be unchanged is left in quotes or double quotes
  If you need to make the dates join, use one of these formats

      fyear'/'fmonth'/'fday    1957/07/23
      fhour':'fmin':'fsec      10:08:42
      fdate || fmonth || ftime  19570723
      fmonth'/'fday'/'fyear    07/23/1957

You copy your touch command into the directory, and edit the tail.

What you end up with is the files with the same date as the DOS you
are using.

*/

[os2fan2]

You might find the files generally in these places

1. Win95A CD\other\oldmsdos [all of these are supported]

2. Any copy of MS-DOS 6.21 or MS-DOS 6.22. Note Print.exe has a different elsewhere in the file. Win95A has the 6.22 version.

3. The 6.21 or 6.22 supplemental diskette.

The files are tested individually, so you can start with a mixture. The ones the rexx script lists without the 'v + hexlist' are only there to be touched. These also work with Windows, but don't check for version.

Resulting files tested under Win98 (2222), WinME (3000), Win95B (1214) and Win95 (0950) without having to setver them. When you have the wrong dos version, they show "incorrect dos version".

Fasthelp.exe also works. I'm including DOSHELP.HLP in my help for win9x rewrite. (which includes all of the above files)

Wendy

[somewan]

os2fan2, on Aug 4 2005, 10:13 AM, said:

You do have to patch a large number of positions.  I did a fc /b between the binaries from 6.21 and 6.22, getting this result.

It seems that you're doing more extensive patching
than necessary, or do any of the programs actually
require it in order to function?

I just refreshed my memory about what was needed
for tree com (from DOS 6.22), and apparently, a two-
byte patch in one location is sufficient:

C:\exec> \dos6\tree.com
Incorrect DOS version

C:\exec>tree.com
Directory PATH listing for Volume FAT16 10K
Volume Serial Number is 3E2F-DAEF
C:.
+---WINBAT
+---FDFORM18
    +---GERMAN

C:\exec>fc /b \dos6\tree.com tree.com
Comparing files \dos6\TREE.COM and tree.com
00001500: 75 90
00001501: 03 90

C:\exec>debug \dos6\tree.com
-u 1600
11FB:1600 7503          JNZ     1605
11FB:1602 F8            CLC

C:\exec>debug tree.com
-u 1600
11F9:1600 90            NOP
11F9:1601 90            NOP
11F9:1602 F8            CLC

[os2fan2]

It may be true i am doing extra patching than is required. But these appear to be the differences between DOS 6.21 and DOS 6.22. I don't know assembler etc, so i mainly do 'string hacks'.

On the other hand, changing the DOS version and copyright is more cosmetic, but it makes it look like the proggie belongs there, rather than a rope-in from somewhere else. I iamgine this may be true for lots of the other values as well.

The difference between DOSSHELL from 6.00 and 6.07 (ie the 7,0 beta based on 6.00), is purely cosmetic, (ie change MS-DOS 6 SHELL to MS-DOS 7 SHELL), but it serves to make the product look more unified.

I do know that there is a smaller number of bytes different between DOS 7.10 and DOS 8.00 utilities, much as you are saying.

HIMEM.SYS and EMM386.EXE for example, differ exactly by what it takes to print the version number.

Still, the things are pretty much binary equals, and the script checks that the bytes are equal before it patches, so it's probably more of a good thing that it does.

[somewan]

os2fan2, on Aug 4 2005, 10:56 PM, said:

It may be true i am doing extra patching than is required.  But these appear to be the differences between DOS 6.21 and DOS 6.22.  I don't know assembler etc, so i mainly do 'string hacks'. 

I hope you'll get around to it (learning assembly) - it should be pretty easy to someone as clever as you. I think that REXX thing looks more difficult, but I admit I'm biassed.

Anyway, I think a suitable way to begin would be an instruction set reference in combination with Ralf Brown's Interrupt List (freely downloadable) and the DOS DEBUG program. Use debug's search command to look for INT 21 instructions (hex: CD 21), which is the "API" for DOS system calls - such as the version check - and then explore the surrounding code (Ralf Brown's list has all the details on system call numbers and parameters to them.). That's more or less how I fixed tree.com & comp.com (I think I took the latter from DOS 5, because it wasn't on the main DOS 6 floppies).

Quote

On the other hand, changing the DOS version and copyright is more cosmetic, but it makes it look like the proggie belongs there, rather than a rope-in from somewhere else.  I iamgine this may be true for lots of the other values as well.

Yes, and appearance is very important to Microsoft. Did you know they have the Win9x "clouds" boot logo embedded in IO.SYS, just in case LOGO.SYS isn't available? It gets tranferred to bootable floppies too (that's how I noticed it).

Quote

I do know that there is a smaller number of bytes different between DOS 7.10 and DOS 8.00 utilities, much as you are saying.

I'm not familiar with DOS 8, because most of what I heard about WinME, including from Microsoft employees close to its development, was rather negative. But considering the major feature of WinMe was the feeble attempts to sweep DOS under the rug, it doesn't surprise me if they didn't spend any time on improving it.

Quote

Still, the things are pretty much binary equals, and the script checks that the bytes are equal before it patches, so it's probably more of a good thing that it does.

Certainly better than corrupting them (a different method to ensure that would be to calculate hashes or checksums).

[os2fan2]

Rexx is a programming language, used extensively in OS/2. It's pretty handy for writing things that do useful things to the computer.

I have a rexx script that reads CIV1 saved games, works out the offset, and then creates lots of units and selected civ techs for your civ. The thing used to check if the game was English or German/French, and calculates the offsets accordingly.

All in all, it's a pretty easy language to write, and much more potent than anything i seen from MSFT.

Wendy

[somewan]

os2fan2, on Aug 6 2005, 11:16 AM, said:

Rexx is a programming language, used extensively in OS/2.  It's pretty handy for writing things that do useful things to the computer. 

All in all, it's a pretty easy language to write, and much more potent than anything i seen from MSFT.

Judging from the example script you posted, Rexx does look like a language designed for getting practical results, with features taken from at least C and BASIC - kind of like Perl, which is a mixture of at least the (Unix) Bourne shell, AWK, C, C++ and SED.

By potent, you could mean a lot of things, but I suspect it may be a matter of taste... mostly whether or not you like VB and everything based on that - I personally don't, so I kind of hate to admit that I've used it enough to know that if you can endure it, you will usually get results (for example with Excel macros). All the viruses that has been written in it also demonstrate some of its power.

Quote

I have a rexx script that reads CIV1 saved games, works out the offset, and then creates lots of units and selected civ techs for your civ.  The thing used to check if the game was English or German/French, and calculates the offsets accordingly.

So you're saying you wrote a cheat program for Civilzation too? That's quite a coincidence... mine was written in Turbo Pascal, in the early to mid-90s. It edits the money available, turn number, year, difficulty level, names of tribes, leaders, cities and units, the type of government, unit defence/attack strengths, tech. advances and maybe one or two other things. Of course, you could switch to a different tribe - including the barbarians (but you have to let them capture a city first, or the game will end immediately).

I wrote cheat programs for some other DOS games as well, including "UFO: Enemy Unknown", "Indiana Jones and the Fate of Atlantis", "Red Baron", "Sim City", "Duke Nukem", "Cmdr. Keen" and "Railroad Tycoon".

Alas, my editor for "Dune 2" was of limited usefulness because I never managed to decipher the file format well enough to calculate the money offset. Did you?

[os2fan2]

I only ever played civ, and after i figured out how to write the cheat for it, i played around with lots of things.

I found in the end that giving too many techs to oneself made the game unstable, so i used to limit it to about three or four (inc railways), [later on in the game, one discovers the 'wheel'. Such is logic.

tinkering with game strengths is a bit rough. It is a lot easier to start with 6 settlers and 6 armoured infintary units, and use these to build an extensive rail network. [there's a cheat on delaying turns for settlers doing things.]

So by 3000 BC, you should have about five or six cities connected by a decent rail network, and a good deal of land under irrigation, plus a couple of great wonders under way.

I did discover where the money was hiding in railway tychoon, but that's as far as i got.

[somewan]

os2fan2, on Aug 7 2005, 11:31 PM, said:

I found in the end that giving too many techs to oneself made the game unstable, so i used to limit it to about three or four (inc railways),

Yes, railways are important to have early, because they must either be built before a city is founded in the square, or never (and that's a shame).

So if I recall correctly, that's what I used to do, as well as maxing the money, mostly leaving the rest to normal gameplay (and save+restore).

Quote

tinkering with game strengths is a bit rough.

I found that turning those annoying nuclear weapons into ground units and reducing their range was one of the more useful edits at some points in the game. (Although they would still occasionally roll into your city by rail...)

Quote

[there's a cheat on delaying turns for settlers doing things.]

Yes, I think that was one of the better-known cheats as I saw it mentioned elsewhere. Did you know you could build railroads on water?

Quote

I did discover where the money was hiding in railway tychoon, but that's as far as i got.

I didn't bother with anything else either.

[os2fan2]

I mean, if you have 8 armoured units, and 8 settlers, it's pretty easy to wait a few turns before you get your first city up and running. I mean, veteran cities with no city have no support costs, and so are quite handy.

I did build railways out on the sea, too. Good to build them where the whales and fish are.

By the way, civ1 got me into doing interesting things with computers, and turned me from a user to a power user.

W

[somewan]

os2fan2, on Aug 8 2005, 03:19 AM, said:

I mean, if you have 8 armoured units, and 8 settlers, it's pretty easy to wait a few turns before you get your first city up and running.  I mean, veteran cities with no city have no support costs, and so are quite handy.

I can only imagine - unit creation is one of the few valuable feature my editor didn't have. Do you still have the offsets and details on that?

I also didn't decipher the maps - that would have been pretty interesting too.

Quote

By the way, civ1 got me into doing interesting things with computers, and turned me from a user to a power user.

I wish it had had the same effect on my brother (he played it almost as much as I did).