Windows 3.0 and Dos 5 Setup for Wildcat version 3 -------------------------------------------------- Revised : 01/17/92 Before you start ------------------ This version of Win3cat3.txt superceedes all previous versions. If you have a previous version, and you find some statements that contradict each other between the two, believe this one! (g) I just means that I've learned something that I didn't know before. Not an exact science, this learning process. Also, all responsibility and liability for using these tips rests with the user. I will not be held accountable for any kind of damages incured by you when you use this document. I will tell you that I have tested these tips on my machine, and they do work on my machine. I haven't destroyed anything yet. I fully expect them to work on just about any 386 machine that generally equals or exceedes my configuration. However, no guarantees are made. Setting it all up... -------------------- I have been running Wildcat V3.02s under Windows 3.0 for about a month now quite successfully. I am running it on an Fast Data 386/25 DX with 4 Meg of Ram, and MS-Dos 5.0. This document explains my implementation. There are three support files provided with this package: CAT1.PIF - This Windows PIF runs CAT1.BAT in 386 Enhanced mode under Windows 3.0. I set it up to run full screen in background and foreground mode. I also set the multi-tasking options to 100,100. This gives Wildcat the same percent of CPU time regardless of whether its the forground task or a background task. Generally your users will not notice any performance degradation if you are running another task with Wildcat in background. The reason for the "1" in the name is easy: This will eventally be Node 1 of a 3-node multi-line BBS. Its is an easy way to identify which node is which under Windows, as well as keeping everything separated that has to be separate for each node. CAT1.BAT - This is the batch file to run Wildcat Node 1. Its pretty straightforward. The only changes to this file for starting other nodes should be the environment variables, and uncommenting the other two batch files, so that they will run when Windows runs CAT1.BAT. WCSYSOP.GRP - This is a program group for the Wildcat MAKEWILD, MAKEWILD READ ONLY, MAKEQUES, WCPRO, WCREPAIR, WCFILE and CATCOLOR utilities, plus a few other goodies. You can add this program group by using the Windows PROGRAM MANAGER FILE option and select "NEW..." and then select "Program Group". On the next panel enter whatever title you choose and then enter C:\WC30\WCSYSOP.GRP if you put it in the C:\WC30 directory. Some configuration notes: For Dos: --------- Here is my config.sys file for Dos 5: FILES=40 buffers=50,8 device=C:\dos\himem.sys device=C:\dos\emm386.exe 384 d=48 ram DOS=high,umb DEVICEhigh=c:\DOS\ansi.sys devicehigh=C:\dos\smartdrv.sys 1024 256 stacks=0,0 Some quick notes here - The d=48 on the EMM386 line. Ths increases the size of the DMA buffer used to communicate with the EMS and UMB areas. It speeds everything up, and may allow you to run some applications under Windows that wouldn't run otherwise, like Fastback 2.x. Also, the 50,8 on the buffers line. Even though the Windows book says you can get by with as little as 10 buffers with Smartdrive in place, I found this not to be true. I multi-task a lot of Dos applications, and some of them just won't go without a goodly amount of buffers. The ,8 enables "look ahead" buffers for disk access, and should always be included. This option first appeard in IBM PC-Dos 3.3 (undocumented) and was also in some versions of Dos 4.0. Ms-Dos 5.0 should have it in all versions. It does quite a job in speeding up disk access, especially when you have older, slower components. Here is my autoexec.bat file for Windows and Wildcat: @echo off cls path=c:\;c:\dos;C:\WINDOWS;c:\mouse;c:\fastback;d:\wildcat set fastback=c:\fastback set TEMP=c:\temp set TMP=c:\temp loadhigh share /f:4096 /l:40 prompt $v$_$p$g win /3 Notice the LOADHIGH SHARE line. Be sure to ALWAYS load SHARE when in a multi-tasking environent. When running Wildcat 3, be sure to provide 40 locks because Wildcat can have up to 40 files open at once. And, since you're doubling the number of locks over the default of 20, its best to double the size of the area to hold those locks, hence, the /f:4096 switch. A quick note on the WIN command line. I put the /3 on there just to be sure that Windows always starts up in 386 Enhanced Mode, or dies in the attempt. Even though Win is smart enough to determine startup mode by itself, based on machine configuration, I take no chances. If for some odd reason Windows comes up in Standard Mode (like on a 286, or a 386/486 with only 1 meg of ram), then it only multi-tasks Windows aplications. Wildcat is a Dos application, so if you switch away from Wildcat in Standard Mode, it freezes. Not good for the caller on the other end of the line! If you've seen pervious versions of this file, I used to have CAT1.BAT on the WIN /3 line. If you really want to run Wildcat in a window, this is the only way I know of to make Wildcat start up properly. If you run Wildcat in full screen mode, by setting the correct PIF option, you can start Wildcat a different way. Put CAT1.PIF in your WIN.INI file, on the LOAD= line to run minimized, or on the RUN= line to run non-minimized. For Windows ------------ First (and foremost) the PIF! If there's a heart to Windows, the Program Information File is it. The options you set in the PIF will determine whether an application runs well, poorly, or not at all! Yes, the book says you can run programs without defining a PIF, but in that case, Windows will use either its default internal settings (from the Control Panel) or the settings in _DEFAULT.PIF. So either way, your program WILL be using a PIF of some sort. Might as well take a few minutes and create a PIF that matches your program's operation as much as possible. You'll get the most out of it (your program AND Windows) that way! CAT1.PIF in detail: (start the PIF editor and look at CAT1.PIF if you want) First screen of the PIF editor - The first few boxes pretty much explain themselves. CAT1.BAT tells Windows what file you're going to run, Wildcat Node 1 names the icon when its on the screen, and the directory tells Windows where to find CAT1.BAT. The next few items get interesting. Here's what they say: There must be at least 128k free conventional memory to start Wildcat, and the Dos session that runs Wildcat can take up to 640k conventional memory (important for Dos shells, doors, Tomcat, etc.). We are going to run Wildcat full screen, and we want it to run constantly, even if its in the background. Close the window when Wildcat is shut down. Always check this box. No sense clutering up your screen with inactive items. Second screen of the PIF editor (Advanced Options) Multi-tasking Options: The default priorities are 50 and 100. I set the background priority to 100 also, so that Wildcat will get the same precentage of system resources regardless of whether its running foreground or background. Exactly what that percentage will be is hard to determine, since it will depend on what other tasks are running with Wildcat, whether they are Windows or Dos applications (because of the way Windows does time slicing) and what forground / background priorities they have. The important thing is that Wildcat always needs to get its fair share of time, while not slowing your work down too awfully much at the keyboard. This is why Detect Idle Time is set, so Wildcat will return resources to the system while he's not doing anything (like while the caller is reading a message or looking at a list of files). All of your other PIFS should have Detect set on too, so they can give resources to Wildcat when THEY aren't busy. Memory Options: The 275k EMS memory is for Wildcat's overlay file. This is for the "Hold overlay in EMS if available" question in Makewild. Keeping the overlay in EMS is always a good deal, because it speeds Wildcat up a lot. In the Windows environment, the faster an application runs, especially a Dos application, the better. The 256k XMS memory is a new wrinkle for Wildcat 3.02 and later. The Makewild questions about enabling swapping Wildcat out of memory and where (DISK, EMS, XMS) prompted this. I used to have all "extra" memory assigned to EMS, but I picked the XMS option for v3.02 because Windows likes to use XMS memory over EMS whenever possible. Since making the change, Wildcat takes less system resources and seems to run much smoother under Windows with other tasks running at the same time. I set the High Memory option mainly because the Windows book suggested it. It supposedly will free up some more conventional memory in the Wildcat session, and I'm all for that. Notice also that I set all of the LOCK options. This ensures that all of Wildcat is in main memory at all times. This is VERY important for any communications type program. Even though it takes only a few milliseconds to swap a program page in from disk, a comm program or BBS just can't afford the time to wait. So lock Wildcat in and let everything else swap around it. It will cost you memory, and maybe some speed on other tasks, but when the modem speaks, Wildcat just HAS to be there with an answer. If locking Wildcat in memory really kills your system's performance, about all I can suggest is another meg or two of memory. Sorry, fortunes of war. Video Options: Its VERY IMPORTANT that you set Low Graphics here, and run Wildcat in 80x25 screen mode. I know, if you're running Windows, you've most likely got a VGA monitor, and you're itching to run Wildcat in 43 line mode with the Fireworks screen blanker. But remember - Windows will only run a high-res graphics application as a full-screen, forground task. If you try to put high-res stuff in background or in a window, you get that neat little Windows message about the application being frozen untill you switch back to it. Once again, not good for the poor person hanging on the other end of the phone line. To avoid this, run Wildcat in 80x25 mode always, and use a screen blanker other than Fireworks. The Fireworks are high-res too, as far as Windows is concerned! I use the ol' reliale Box myself. Also, don't select any of the Monitor Ports options. You'll just slow down BBS operations, because Windows will be in there port checking every time a local screen update is made. No need to Emulate text mode or retain video memory either. Other Options: I left this section set at the defaults. Fast paste is ok, but I wouldn't allow closing the window while Wildcat is active. Never tried it myself, but I'm a little nervous about letting Windows close a Dos application. Especially if it has lots of files open. I defined the CTRL-W shortcut key to switch directly to Wildcat. You can change it if you want. For Wildcat ------------ I've pretty much covered this stuff already, but here's a qiuck review: In Makewild: Set things up like you are going to run in native Dos. Be sure to set the Swap options to Y and swap to XMS on version 3.02 or EMS in earlier versions. Also, hold the overlay in EMS. Do NOT use the Fireworks screen blanker. For multi-line, set the Network type to Dos Share. Opertaions: When running Wildcat, keep it in 80x25 screen mode. Wheter you run it in full-screen mode or a window is up to you, but there does appear to be some overhead for local screen writes when Wildcat is windowed. This seemed to slow down response for callers with high-speed modems. Don't put Wildcat into 43 line high-res mode under Windows in any case. Be carefull about poking around in the Wildcat direcories while someone is online. Share should keep you out of any real trouble, AKA trashed files and the like, but what happens if you are in a full-screen application, like a text editor? You're working on a display screen that Wildcat wants to send to the caller. Ooops - sharing violation - but you don't know it, because your editor has update rights to the file. The caller doesn't know it either, because Wildcat is hung up waiting on you to answer the Abort, Retry, Fail message from Share on the local screen - the local Wildcat screen - that you can't see, because your editor is in full-screen mode! When in doubt, shut Wildcat down, even when you run single line. That's about it - hope this is of help to some of you. I'm running a single line Wildcat at this point, but I'll be evolving this into a multi- line setup over time. I'll let you know how it all works out when I get there myself. I'm sure it will prove to be "interesting". Joe Rhinehart The Comm * Port BBS 614-870-6544 HST 14400 non-v32, v42