Technical Support Bulletin

Phil Miller 
August 28, 1991

Subject: Running CPC products with DOS 5.0

This purpose of this paper is to provide a case analysis of some common configurations involving The Complete PC products, Dos 5.0, Hi memory managers such as Qemm386, Networks, and Windows.  This paper cannot take the place of reading and understanding chapter 12 of the DOS 5.0 manual.  
Attached I have several Configuration documents that show the contents of various config.sys and autoexec.bat files where certain products in various combinations are installed.  I will show that CCOM 2.62, CFAX 2.14, PFAX 1.1, and Scan 2.22 call all be loaded with more than 570K of RAM free.  The bug that did show up in some old releases of our software now has a remedy with DOS 5.0: LOADFIX.  If a program is getting the error Packed file corrupt then you need to run it with Loadfix.

	C:\> LOADFIX CFBACK

This problem should no longer be occurring with current software.  We no longer ship software that has the packed file format.  The only one where you may continue to see this is with The Complete Answering Machine.

Loading our code high with DOS works just fine.  Loading DOS high must be done carefully if you are combining features of DOS 5.0 with QEMM or 386MAX.  There must be room for the whatever you are loading high.  The examples I will provide will show what you must have and what you must  not  have.

The products of ours tested were: CCOM 2.62, CFAX 2.14, PFAX 1.1,  Scanner 2.22.   FaxIt 2.0 and WordScan were tested as well.  
These were  tested against QRam 1.0, QEMM386 5.11, DOS 5.0, NetWare 386 3.10, MicroSpeed, Logitech, and MicroSoft mice, and Windows 3.0.  
There are new versions of some of the products mentioned in the latter paragraph.  QRam is due out with a new 1.1 version that as of this date is not quite out yet.  QEMM386 has a new 5.13 version that is supposed to fix some of the problems (that I haven't seen) with DOS 5.0.  DOS 5.0 comes with a copy of Net5 which I have been running quite happily.  XMSNet5.COM and EMSNet5.Com are not supplied with the DOS5 but are available from Novell.  I have had some problems with the XMSNet5 driver with HiMem.Sys and have therefore excluded it from this discussion.
It is important to note that arbitrating the combinations of the other memory management programs with the memory management features of DOS 5.0 and Windows offered a challenge.  The machine that I am running is not the most standard of all machines.  Under the more vanilla configurations, I didn't run into any big problems.  Memory mangement was not the most frustrating issue; Device arbitration within Window's picky OS extensions was!
When you are figuring out how big each TSR is, you can't just look at the size of the final TSR in RAM and then try to load that amount, nor can you look at the .EXE size and derive the exact amount of RAM it will require.  There is a transient initialization area that will take up some RAM during the loading process, and then may be de-allocated when the program goes resident.  The final figure shown with a memory map will not reflect this initialization area's RAM requirement.  The initialization sizes vary by quite a bit from one program to the next, so no rule of thumb appears to exist.  You just have to play with the configurations to find out how they fit together best.
Dos 5.0 comes with a much better memory tool than any previously available.  Mem.EXE has a /C switch that will show you what is loaded where.  This is very important, because when you load DOS high with LoadHigh or DeviceHigh if there isn't enough room to load it up there, it simply loads it low, and it doesn't tell you that it is doing this!  Qemm and Qram do tell you when they must overide your decision, but DOS doesn't.
The user also has to know or decide whether his application mix works best with EMS or XMS memory.  Most Windows and newer software will work better with XMS if they are XMS aware.  DOS-only software will usually be written with EMS in mind if they use high memory at all.  EMM386.EXE works only with 386 machines.  DOS 5 does not provide the tools for 286 machine users to LoadHigh or DeviceHighprograms into high memory.  If they have their own XMS driver then LoadHi and DeviceHigh can work, as would be the case with QEXT.SYS, a component of QRam.


DOS5.0 with CFAX

Description:  Dos loaded high; CFAX

<<< AUTOEXEC.BAT >>>

PATH C:\DOS;C:\UTL;C:\CFAX;c:\
PROMPT $P$G
mem /c | more                       ; mem will show you how your memory is being used.
pause
CFBACK			
mem /c | more			; and now after CFBACK is loaded shows how much it took, and where.
      
<<< CONFIG.SYS >>>

Device = c:\Dos\SetVer.Exe   	; Fixes DOS version-specific  programs.
Device = c:\Dos\HiMem.Sys	; loads DOS A20 High Memory handler.
Dos    = High,UMB		; loads DOS High with Upper Memory Blocks addressed.
Buffers= 24                  		; Buffers go into Ext memory anytime DOS=High automeatically
Files  = 99
Break  = ON
LastDrive=E
Device = C:\Dos\Emm386.Exe Ram  ; This is required if you want to loadhigh anything manually.
_______________________________________________________________________________
DOS 5.0 allows the user to load command.com into high memory.  The Config.Sys in this example shows one way to do this.  The UMB parameter conflicts with QEMM386.  Specify one or the other but never both.  Also, you should never specify HiMem.Sys and Qemm386.Sys at the same time.

Buffers are automatically loaded into the HiMem area with DOS 5.0 any time you specify that DOS= High.  I have found no conflict at all with this setup, and it sure saves low memory.  Each buffer uses 512 bytes.

The AutoExec file shows how to find out how much memory is available.  I have not seen the case where CFAX 2.14 could not be loaded with more than 580K of RAM since we stopped packing the program with 2.14.  If you continue to get the problem you can load the program with:

	C:\CFAX> loadfix CFBACK

and this should handle the problem.

Note carefully that CFBACK is not loaded high.  CFBACK may sometimes be loaded high but wasn't built with that in mind.  If it loads successfully, it should be able to send and receive, but when you run CFAX, it will not be able to find the background code.  Also, you can't unload CFBACK with FAX_OFF the way you can when it is loaded in conventional memory.
Mem /c will display more than can fit on one screen if there is high memory loaded.  There isn't any /p switch like with the DIR command, so you have to pipe it to a MORE program as shown.


DOS 5.0 with CComm High

Description:  Dos loaded high; LOADHIGH CCOM using DOS; No Network.            

<<< AUTOEXEC.BAT >>>

PATH C:\DOS;C:\UTL;C:\CC;C:\CC\CAM;c:\
PROMPT $P$G
loadhigh CCBACK			; This is how you load high with DOS 5.0

<<< CONFIG.SYS >>>

Device = C:\Dos\HiMem.Sys
Dos    = High,UMB			; Use the UMB if you are loading high with DOS
Buffers= 24 
Files  = 99
Break  = ON
LastDrive=E
Device = C:\Dos\SetVer.Exe
Device = C:\Dos\Emm386.Exe Ram x=de00-dfff    ;My Network Card uses excluded area.	 
Device = C:\PPR\PPR.SYS /PDA:2 /T /X=B /Y=B /Z=B /S5 /C0	; my trackball mouse driver
Device = C:\Dos\SmartDrv.Sys 2048 1024
Shell  = C:\Dos\Command.Com C:\Dos\ /E:384 /p	; Sets environment size and ComSpec.
Device = C:\Dos\RamDrive.Sys 2048 /e		; Ram disk out of Extended RAM
_______________________________________________________________________________
In this configuration, we actually load CCBACK High.  DOS 5.0 is in total control and needn't share any control of that high memory area with some other handler.  Thus we continue to specify the UMB switch on the DOS line, and we use the HiMem.Sys driver in the Config.Sys.
I have received two FAXes and received some messages, all with the message light turned on without any problems. Windows is trying to be everything to everybody when it comes to BIOS calls, DOS video calls, and with all the video cards available, it is possible to have some incompatibilities where direct screen writes are concerned.
Notice that I have excluded an area for my Network card with EMM386.  My network card does use this I/O address in high memory that would conflict if I were not to exclude it from use.  Incidentally, Stacker's Hardware compression card also uses such an I/O address that must be excluded.  I went into Manifest after using EMM386 this way and it does share the RAM so allocated as LIM 4.0 EMS ram.  This puts an end to the problems of how people want their upper RAM configured: EMS vs. Extended RAM.  XMS with this driver installed goes both ways and allocates on a demand basis.  Also I have specified RAM with EMM386.Sys.  Either RAM or NoEMS Keywords are necessary when using the LoadHigh or DeviceHigh loader.


DOS 5.0 with NetWare Interfaces High

Description:  Dos loaded high; CFAX using DOS; Network loaded High.

<<< AUTOEXEC.BAT >>>

PATH C:\DOS;C:\UTL;C:\CFAX;c:\
PROMPT $P$G
LoadHigh C:\Net\IPX.Com		; IPX goes up high with DOS 
LoadHigh C:\Net\Net5.Com		; Net5 won't fit,  
F:Login Phil
CFBACK				; And CFBACK doesn't go high

<<< CONFIG.SYS >>>

Device = c:\dos\himem.sys
Dos    = high,umb
Files      =  60
Buffers = 24 
LastDrive=E
Device = c:\dos\emm386.exe noems  x=deff-dfff    ;  Netword excluded addr's. 
DeviceHigh = C:\Dos\SetVer.Exe
DeviceHigh = C:\PPR\PPR.SYS /PDA:2 /T /X=B /Y=B /Z=B /S5 /C0	; My trackball driver
Device          = C:\DOS\SmartDrv.sys 2048 1024
DeviceHigh = C:\DOS\RamDrive.Sys 2048 /e	 ; 2MB Ram disk in Ext.

_______________________________________________________________________________

In this configuration I am loading up the network as well as the CFAX.  I have chosen to load the network up high, since I can't unload it once loaded.  The CFAX can be unloaded for those times when needed.  It is important to remember that CFAX version 2.14 cannot be loaded high.  CCOM 2.60 was the very first product to have this capability.  
DOS has exclusive control over the high memory area, so I have enabled its UMB param in the DOS = area.  The RamDrive and the SetVer Programs are quite small so I can load them up high as well with the DeviceHigh device loader.
I have configured a 2Mb Ram drive (which I use as my D:)  on the last line of the Config.Sys. This is used for frequently used files or for a Swap area for Windows.  The driver itself is being loaded high, thus freeing 1184 bytes of low memory.

Qemm386, NetWare Hi, CFAX

Description:  DOS 5.0 loaded High; loadhi network; load CFBACK                 

<<< AUTOEXEC.BAT >>>

PATH C:\DOS;c:\qemm;c:\windows;C:\UTL;C:\CFAX;c:\	
PROMPT $P$G
LoadHi c:\mouse.com		; I am using QEMM386\LoadHi here.  They all fit!
LoadHi c:\net\ipx.com		;
LoadHi c:\net\net5.com		;
f:login phil
CFBACK  			

<<< CONFIG.SYS >>>

Device = c:\dos\setver.exe
Dos       = high 			; DOS goes High, but UMB's are reserved for Qemm.
Device = c:\qemm\qemm386.sys ram memory=1024 exclude=de00-dfff ;Network Card addr 
Buffers = 24
Files      = 99
Break   = ON
LastDrive=E
Device = C:\DOS\smartdrv.sys 2048 1024
Device = C:\Qemm\LoadHi.Sys   C:\Dos\RamDrive.Sys 2048 /e

_______________________________________________________________________________

The interesting thing here is how much more stuff can be loaded high with QEMM than can be loaded high with DOS.  QEMM recovers more high mem to start with, and allows you to spend it more carefully.  In the Config.Sys for instance we are able to load the RamDrive (all 1184 bytes of it) into high RAM.  
The network card address is again excluded from the QEMM configuration so it won't conflict.  The address range DE00-DEFF on my card is used by the card itself.  This range is not detectable by DOS (or other memory managers for that matter) until IPX.COM and Net5.COM is loaded.  At that point - or during the login, the system will hang.  I've had it happen on my system.
Note the absence of the of the UMB statement on the DOS = line.  Dos does not have to go high, but I let it go up there for this example to show it is an option.
The Complete Communicator can be loaded in exactly the same way.  Just replace the CFBACK line with CCBACK.

Windows 3.0, Netware High, CComm

Description:  Windows 3.0 - Network - MS Mouse - CCOM                          

<<< AUTOEXEC.BAT >>>

Path C:\Dos;C:\Utl;C:\;C:\Windows;C:\CC;C:\CC\Cam       ; All important dir's are path'd.
Prompt $P$G
LoadHigh  C:\Net\IPX.Com
LoadHigh  C:\Net\Net5.Com
F:Login Phil
Set Temp=D:\
CCBack
Win
<<< CONFIG.SYS >>>

Device = C:\Dos\HiMem.Sys
Dos    = High,UMB
Files  = 50
Buffers= 24 
LastDrive  = E
Device = C:\Dos\Emm386.Sys NoEms X=DE00-DEFF
DeviceHigh = C:\Dos\SetVer.Exe
Device          = C:\Dos\SmartDrv.Sys 2048 1024
Shell              = C:\Dos\Command.Com /p/e:256
DeviceHigh = C:\Dos\RAMDrive.Sys 2048 /e

_______________________________________________________________________________

Nothing fancy here.  Just DOS 5.0 and Windows.  Notice that I am using DOS' HiMem.Sys instead of Windows'.  Also, note that I am using UMBs.  I am not loading SmartDrv.Sys because of its large 25K size; Furthermore, I have noticed that its transient program loader takes a lot more RAM during its loading process - Therefore making it a bad candidate for squeezing in last.  I am loading RamDrive.Sys high with the new DeviceHigh invoker.  Note that everything here is working with Extended memory. CCBACK is not loaded high here because it would be the only thing that could fit high.  DeviceHigh loads SetVer.Exe and RamDrive because of their small size.  Nothing else goes high unless the user is running a monochrome screen and can recover the video area.

Windows 3.0, Scanner High, CComm, Netware

Description:  Windows 3.0 - Network Drivers loaded high - MS Mouse - CCOM loaded - Scanner driver loaded on its own infterface card  using  irq2  and DMA channel 3 scan .             

<<< AUTOEXEC.BAT >>>

Path C:\Dos;C:\Utl;C:\;C:\Windows;C:\CC;C:\CC\Cam;C:\Scan
Prompt $P$G
C:\Net\IPX.Com			; IPX goes low Network Drivers still go high
LoadHigh C:\Net\Net5.Com	; Net5 goes high.
F:Login Phil
CCBack
Set Temp = D:\
win

<<< CONFIG.SYS >>>

Device = C:\Dos\HiMem.Sys
Dos    ...= High,UMB			
Files .............= 50
Buffers.........= 24 
LastDrive  ...= E
Device......... = C:\Dos\SmartDrv.Sys 2048 1024
Shell      ........= C:\Dos\Command.Com /p/e:256
DeviceHigh = C:\Dos\RamDrive.Sys 2048 /e
DeviceHigh = C:\CPCScan.Sys 3e0 2 3	
_______________________________________________________________________________
The key point here is the Scanner configuration.  The Scanner had to either be located off on its own scanner interface card, or the modem had to be disabled in order to get both to work under Windows.  The problem appears to be one of interrupt arbitration under Windows between two devices that own the same interrupt.
The scanner driver used was version 2.08.  Incidentally, the version that I got off the shelf with 2.62 is still 1.1!  Get 1.6  or 2.08 into peoples hands.  They are much improved and more robust.  I was able to load the 2.08 driver high as shown.  
I was able to scan at both 200 and 300 dpi with no scan lines or any other abnormal distortions on my 386 running at 33MHz both after invoking Scan from Windows and from DOS.  
Even though CCBACK, the scanner driver, and the network drivers are all loaded in conventional memory, Windows still performed just fine in both Standard and Enhanced mode.  I even went into Word for Windows with this configuration and it worked jsut fine from Standard mode, although it took a bit longer to load.  Manifest showed that 450K or so were still available.
A word about why I selected what I did for high and low loading:  It turned out I could load either IPX low or SmartDrv low.  SmartDrv uses 25K.  IPX uses 20K.  I therefore saved the most RAM by loading up the set that you see now.  I cannot load CCBACK high when I am using the network because of the excluded area in RAM.  This excluded area makes the memory non-contiguous.  If I don't load up IPX  (and therefore Net5 also) the boards sensitive addresses never get touched.

Windows 3.0, CComm Hi

Description:  Windows 3.0 - Netware - DOS=high - CCOM loaded hi with QEMM              

<<< AUTOEXEC.BAT >>>

Path C:\Dos;C:\Qemm;C:\Utl;C:\CC;C:\CC\Cam;C:\;C:\Windows
Prompt $P$G
C:\Net\IPX.Com
C:\Net\Net5.Com
F:Login Phil
LoadHi CCBack
set TEMP=D:\
win
<<< CONFIG.SYS >>>

Device = c:\dos\setver.exe
Dos       = high
Device = C:\Qemm\Qemm386.Sys RAM MEMORY=1024 EXCLUDE=DE00-DFFF
Buffers= 24
Files  = 99
Break  = ON
LastDrive = E
Device = C:\Dos\SmartDrv.Sys 2048 1024
Device = C:\Dos\RamDrive.Sys 2048 /e
_______________________________________________________________________________
This configuration shows that CCOM can be loaded hi with QEMM, and how to go about it.  Windows still works with this configuration.  
Things to observe:
	No UMB Keyword on Dos = line.
	No DeviceHigh loaders.
	No HiMem.Sys
	No Emm386.Exe
	No Device = C:\Qemm\LoadHi.Sys lines.  There isn't room for anything else.

Windows 3.0, Netware High, PFax

Description:  Win 3.0 - Network loaded High - MS Mouse - Portable FAX 1.1 loaded in conventional memory.                       

<<< AUTOEXEC.BAT >>>

Path C:\Dos;c:\Windows;C:\Utl;C:\Pfax;c:\
Prompt $P$G
LoadHigh C:\Net\IPX.Com		; Network Drivers loaded High
Loadhigh C:\Net\Net5.Com
C:\PFax\PFaxBack			; PFAX loaded in conventional memory
F:Login Phil
set TEMP=D:\
Win 

<<< CONFIG.SYS >>>

Device = c:\Dos\HiMem.Sys
Dos    = High, UMB
Buffers= 24 
Files  = 50
Break  = ON
LastDrive=E
Device = C:\Dos\SetVer.Exe
Device = C:\Dos\SmartDrv.Sys 2048 1024
Shell  = C:\Dos\Command.Com C:\Dos\ /E:256 /p
Device = C:\Dos\RamDrive.Sys 2048 /e
Device = C:\CPCScan.Sys 3e0 2 1
_______________________________________________________________________________

Here we have The Complete FAX Portable version 1.1 being used.  Basically you want to load everything up in high RAM except PFaxBack.  In order to make Portable Fax work within Windows, you need to use the PIF editor in Windows to create a PIF file.  Use the addendum to The Complete Communicator aid you in doing this.  Make sure you check the Enhanced mode Execution selection box.  Make sure you enter /W in the Optional Parameters field and give the Memory Requirements 200K instead of the 128K default.  In the Enhanced Mode Advanced Options screen, I have all the Reserved Shortcut Keys selected just like the addendum mentions.  I don't know that it solved any problems, but I didn't see any problems with it setup that way!
WORDSCAN, Netware, CComm

Description:  Windows 3.0 - Network - MS Mouse - CCOM - WordScan setup

<<< AUTOEXEC.BAT >>>

Path C:\Dos;C:\Utl;C:\;C:\Windows;C:\CC;C:\CC\Cam;C:\Scan
Prompt $P$G
LoadHigh C:\Net\IPX.Com
LoadHigh C:\Net\Net5.Com
F:Login Phil
Set Temp=D:\
Call WordInit
CCBack
Win

<<< CONFIG.SYS >>>

Device = C:\Dos\HiMem.Sys
Dos    = High,UMB
Files  = 50
Buffers= 24 
LastDrive = E
DeviceHigh = C:\Dos\SmartDrv.Sys 2048 1024
Shell      = C:\Dos\Command.Com /p/e:384
DeviceHigh = C:\Dos\RamDrive.Sys 2048 /e
DeviceHigh = C:\CPCScan.Sys 3e0 2 3

<< WordInit.Bat >>

ECHO OFF
CLS
C:\CALERA\BIN\INPATH C:\CALERA\BIN
IF ERRORLEVEL 1 GOTO SKIP
ECHO Adding C:\CALERA\BIN to PATH.
PATH C:\CALERA\BIN;%PATH%
:SKIP
_______________________________________________________________________________

When I installed WordScan for this project, I selected the option to put all the commands into WordInit.Bat.  This file was then placed into the root directory and stays there.  The AutoExec.Bat file calls it.  Note that it uses the Call command and does not invoke it directly like a .COM or .EXE file.  This is because you want the batch file to return back to the calling file when the called file is done.  This feature was new with DOS 4 but wasn't used much.  With everybody going to DOS 5  I think this feature will receive more attention and will be used more.  Use it  know it when you have somebody running WordInit.Bat from their AutoExec.Bat.

WordScan ran just fine with this configuration.  Again note that I did have to put the scanner on its own interface card.  

FAXit for Windows

Description: FAX-It 2.0 with Cache and RamDisk loaded High.
<<AutoExec.Bat>>
PATH c:\windows;C:\DOS;C:\UTL;c:\;c:\faxit;c:\WinWord
PROMPT $P$G
C:\net\ipx.com
c:\net\net5.com
c:\mouse\mouse
set TEMP=D:\
SCH
win 

<<Config.Sys>>
device =c:\dos\himem.sys
dos=high,UMB
BUFFERS=24
FILES=99
BREAK=ON
LASTDRIVE=E
device=c:\dos\setver.exe
device = C:\DOS\smartdrv.sys 2048 1024
SHELL=C:\DOS\COMMAND.COM C:\DOS\ /E:384 /p
DEVICE=C:\DOS\RAMDRIVE.SYS 2048 /e
_
______________________________________________________________________________

{PAGE}


