LPMUD PARSE 3.1.2-MSDOS - Version 1.3 ------------------------------------- This file is an exact copy of the file readme.1st found inside the ok312exe.exe archive. The idea is that you read at least to Chapter 4. before attempting to extract these archives, thus saving you time and space in case you don't need both archives. The sections/lines in this file that are NEW since the last release (1.2) are prepended with the word NEW!. Archive name : ok312exe.exe All the files EXCEPT the mudlib. ok312lib.exe A 2.4.5 mudlib. (Still version 1.2, no changes.) ok312u13.exe Simple upgrade for those who are already running OK312 v1.2 Type : Self extracting LHA archives. Contains : EVERYTHING YOU NEED TO RUN LPmud ON YOUR 386/486 BOX!!!! LPmud parser version 3.1.2 for MSDOS both COMPAT_MODE (for mudlib 2.4.5 or older) and non-COMPAT_MODE (for mudlib 3.0 or newer) A virgin 2.4.5 MUDLIB, already converted to MSDOS. NOTE! No parser source! You can get this at several anon FTP sites anyway... Needs : 386sx or better. Just forget it if you've only got a 286 or less. You might be thinking 'Surely it will just go a bit slower? All I want to do is code anyway so...' But the truth is that OK312 is compiled using GCC, which ONLY produces 386-code. So there is absolutely NO possibility that it will work on a 286. From 1.8Mb to 3.5Mb, depending on the low level setup of your hard disk, for the files alone. In addition to this comes the disk space LPmud uses to swap objects out to disk, no idea how much that is, but the more space the better. See Chapter 7. Technobabble for a few notes on this. Introduction ------------ RIGHT! This is it! A complete, up to date(!), LPmud for MSDOS! As some of you might know, John Olson uploaded a complete package to foof a few weeks ago. This was version 3.0.45 (!) though. Booo, hisss!!!! OLD!!! ANCIENT!!! :-) I take NO (You read it, NO!) responsiblity for whatever might happen when you try to follow these instructions. This archive is provided free of charge. No warranties whatsoever... I tried earlier to just give out the updated parses (3.1.2.) but that turned out to be a semi-disaster... I had tons (well, Kbytes) of E-Mail from people wanting a complete LPmud package for MSDOS and how they should go about getting one. To add insult to injury, I had forgot to include a vital file, causing the parses to be unusable... (Sorry about that... $#%@#% GCC... ;-) So this time, I'm going for the full whack, everything you ever wanted to know about LPmud under MSDOS. (Well, almost..) NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! As some of you might have noticed, there were a few bugs in the last release (as usual :-). Most notably : 1. The native mode parse didn't work at all. This was due to me getting a couple of files mixed up. The result was that several functions were not included (the getuid() and similar functions...) 2. I had used the default 800K release space. (I.e. the space LPmud allocates to try a graceful shutdown when memory is low.) This is now set to 100K. 3. The read_file() didn't work at all, works fine now. The reason for it refusing to work was the good old LF vs CR-LF problem. I've done a really nasty hack to get it to work, and it _might_ fall over when you try some really fancy read_file() calls. See Chapter 7. Technobabble for more info on what I actually did... Some added features : NEW! 1. The COMPAT_MODE mudlib now goes in /lpmud/lib245 instead of /lpmud/mudlib and the native mode mudlib goes into /lpmud/lib3 This was partially to avoid renaming the mudlib directory all the time if you have both a 2.4.5 and a 3.0 mudlib. Also to try to create some sort of standard (Ref Rosendaals CD version) NEW! 2. You can now use VCPI compatible programs with this version of the parse. It is compiled with the latest copy of DJ's GCC and allows co-existence with programs like QEMM, EMM386 and DESQVIEW. Unfortunately NO MS Windows compatibility yet... More compatibility details at the end of this file. NEW! 3. There is now an upgrade-archive called ok312u13.exe, which contains ALL the files that have changed since the last version (1.2). If you are currently running (or trying to ;-) that version all you have to do is a) Back up your /lpmud/bin directory. b) Execute ok312u13.exe in the /lpmud directory This will extract new copies of most of the binaries into /lpmud/bin, quite possibly overwriting the ones you have there depending on if you have renamed them or not. c) Rename your /lpmud/mudlib to either /lpmud/lib245 or /lpmud/lib3 depending on the mudlib version you have. Table of Contents ================= Chapter 1. What these archives contains. 2. What hardware you need. 3. What software you need. 4. What to do with these archives. 5. What to put in your autoexec.bat/config.sys (and what to remove). (Or, how to get this beast working...) 6. Odds and ends. NEW! 7. Technobabble Appendix A. What to do when something goes wrong, and why. (This usually amounts to running around in circles screaming...) B. Where to go for extra goodies. C. List of (most of the) files in these archives. D. Caveat & Revision history. ******************************************************************************* * 1. What these archives contains. * ******************************************************************************* Basically, everything you need. What it doesn't contain is the SOURCE for the parsers. IF you need them there are plenty of places to get them... It is split into two files, ok312exe.exe and ok312lib.exe. This is to accommodate(sp?) the people that already have either a mudlib and/or an older version of the parser already. ok312exe.exe ------------ This is all the files you need EXCEPT a MUDLIB. Contains the following directories: bin The executables (i.e. the parsers and the extra exes). config Dunno of this is needed or not... Only 45K anyway. NEW! These are not needed, but what the heck :-) doc The docs for setting up and running LPmud. READ THEM!!! drivers Video-drivers used by the parsers. NEW! These are not needed either, but... :-) Note that the above is all you need for a full UPGRADE from a previous version of LPmud for DOS. Just read Chapter 4. if you know what you're doing and just want the new parsers.... Note the go32.exe ! ok312lib.exe ------------ This is a 2.4.5 MUDLIB converted to MSDOS. Contains the following directory: lib245 This is a complete, converted 2.4.5 mudlib for MSDOS. Ready to roll... NEW!!! This directory used to be called mudlib, it's now renamed to accommodate those who have both a 2.4.5 (/lpmud/lib245) and a 3.0 mudlib (/lpmud/lib3) on their hard disk. NEW! ok312u13.exe ------------ This is the upgrade file from the 1.2 version. See introduction above for more information on how/when to use it. ****************************************************************************** * 2. What hardware you need. * ****************************************************************************** LPmud is not too bad when it comes to hardware requirements. The following is a must: A 386sx or better, i.e. 8088, 8086, 286 are NO GOOD here. A hard disk with at least 3 Meg free. The more the better!!! (Aim for at least 5 Meg free. More if you are coding more than a few rooms/objects.) A VGA card (I think) or better. Dunno about this one... When it comes to RAM I have no idea at all what it needs. 1 Meg should be sufficient. I've got 8 Meg so I can't check if 1 Meg will work. See Chapter 7. Technobabble for more information about ram usage. Things you DON'T need: A maths coprocessor, we use an emulator instead. NOTE that you have to use the emulator that comes with this package, none other will work! ****************************************************************************** * 3. What software you need. * ****************************************************************************** A fairly recent version of DOS. Version 3.1 or newer I think it is. That's about it, the rest is included in these archives. ****************************************************************************** * 4. What to do with these archives. * ****************************************************************************** First of all, the archives have to be extracted. This is where there is a certain scope for misunderstandings. The two files (ok312exe.exe & ok312lib.exe) are ALL you need to run LPmud on your 386/486 box. Users typically fall into one of three categories here: 1) Have got a running LPmud complete with MUDLIB already, just wants the updated parsers. Have a certain knowledge about how things work. Typically done some work on a castle, possibly modified the MUDLIB as well. 2) Have got an old/new version of the LPmud parser, but possibly no MUDLIB. Couldn't get it to run properly. Gave up. 3) Totally green. Haven't got anything working at all, need to be told step by step what to do to set it up. Below are separate instructions for each of the above. Chose the one that fits your description and read the explanation for that. Category 1 ---------- What you need to upgrade to 3.1.2. from an older version of the parser is just a few files. Execute the file ok312exe.exe in a temp-directory somewhere and dig out the bits you need. Hints: bin\pars312c.exe 3.1.2 parser in COMPAT_MODE. (2.4.5 mudlib ) bin\pars312.exe 3.1.2 parser in non-COMPAT_MODE (3.* mudlib ) bin\master.c New master.c (put in mudlib\obj or mudlib\secure depending on type of MUDLIB) NEW! I have just tried a very (VERY) old version of mudlib.n. The non-COMPAT_MODE parser worked fine with this, but I had to use the old (mudlib.n) version of master.c. I also had to transfer the function get_simul_efun() from the bin\master.c to the secure\master.c. AND I had to merge the two simul_efun.c files (because it seems to need functions from both files.) bin\simul_efun.c Same as for master.c. bin\go32.exe Needed to run the most of the new exes, including the new parses. Put it somewhere in your path (eg. \lpmud\bin) bin\emu387 New faster version bin\indent.exe New version The rest is mostly the same as before. If you had something running before all you should have to do is insert the 5 files above and play away. Category 2 ---------- Scrap the lpmud stuff you have gathered so far (Just save any work you have done on a castle or similar) Everything you need is included in the files in these two archives. Make backups of anything you have done yourself!!! Read Category 3. Category 3 ---------- Right... Here we go. This is just to install the two archives. We don't start to fiddle with the autoexec.bat or config.sys until Chapter 5. This is a good place to take a backup of any information you don't want to loose. So you can't blame me if something blows up... People seem to like getting numbered instructions : 1. Find a hard disk that has more than 3 Meg free, alternatively MAKE SPACE :-) 2. Create the directory \lpmud I.e. go to your top directory and type mkdir lpmud This new directory should be empty. 3. Move/copy the two files, ok312exe.exe and ok312lib.exe into this new directory. 4. Go into the \lpmud directory. 5. Execute the two files mentioned above. They are self extracting archives and will create a lot of new files and subdirectories. 6. If nothing has gone wrong so far, i.e. no 'disk full' errors or anything you can delete the two files : ok312exe.exe and ok312lib.exe. Make sure you have backups though, in case you screw up later... :-) 7. BROWSE! Have a look around and familiarise yourself with the directories. The most important at the moment is the \lpmud\doc directory. There you can find information about most things, some relevant and some becoming relevant later. 8. This concludes the extraction. Relax, have a Coca Cola. Now comes the tough part... ****************************************************************************** * 5. What to put in your autoexec.bat/config.sys (and what to remove). * ****************************************************************************** First of all, for the newbies and also the rest of you. Create a system boot disk so that you can boot your machine in the case you screw up the autoexec.bat or config.sys. If you don't know how to do this I suggest you read a good DOS book before going any further. Now, back up your autoexec.bat and config.sys. ! The following is a simplification of what actually goes on, but it's ! hopefully not too incorrect and should serve as an explanation for all the ! strange stuff you have to do to your autoexec.bat and config.sys. Anything compiled with DJ's GCC (a C compiler) for MSDOS must obey certain rules. All the programs you got with this archive was compiled with GCC. That means you have to do certain things to your autoexec.bat and config.sys. Read the file \lpmud\doc\copying for a note of what this does to the copyright of the program... NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! NEW! The previous version I compiled was very restrictive in the number of programs it tolerated. NO MORE!!! (Well, getting better anyway 8-) As some of you might know, the 386 family of CPUs can EMULATE several 8086s by going into a certain CPU state. Some programs use this state to control the behaviour of other programs. Prime examples are DeskView and Windows. They place the CPU into this special mode so they can control, potentially several, other programs. The programs then usually talk to these 'controller' programs when they need memory/services etc. This trick is also used by most MEMORY MANAGERS like emm386, QEMM, 386MAX and others. The previous version didn't tolerate ANY of the above programs at all. This version will happily coexist with most of them. I'm now running my standard setup when running LPmud. HIMEM.SYS, EMM386.EXE, SMARTDRV.EXE etc etc A VERY IMPORTANT NOTE ABOUT MEMORY MANAGEMENT : 1. Note that if you are running with a VCPI server, like QEMM or 386MAX, then LPmud will use *expanded* memory for it's physical memory needs, not extended. When the CPU is in V86 mode, the V86 manager must provide VCPI services for LPmud. Since VCPI is an extension to EMS, disabling EMS will disable VCPI, and prevent LPmud from running. For emm386.sys, this means that you can't use the "noems" switch. This means in reality that you have two choices: - Running a 'clean' machine without any memory managers or anything. or - Running under a program/memory manager that can provide EXPANDED memory. Sadly, MS Windows doesn't follow the VCPI standard so you can't run LPmud under it... :-( With that background, we should be ready to modify our startup files. Comments on a few DOS programs : SMARTDRV.EXE & SMARTDRV.SYS : I've also heard that the smartdrv is not such a good idea to use. Stay away from disk cache programs in general. NEW! I have had no problems so far using the LATEST version (that came with Win 3.1) of SMARTDRV.EXE. Your milage may vary, there have been a few hickups but I'm not sure what causes them yet... SHARE.EXE : It's a MUST, whether it goes in your config.sys, autoexec.bat or you just run it before you start LPmud. MEMORY MANAGERS : These now work fine. I'm using emm386 myself. This includes emm386, QEMM, 386MAX, DeskView and others. HIMEM : This works fine for me under DOS 5.0, both DOS high and UMB's no problems at all. WINDOWS 3.x : Sadly a NO NO. You can't run LPmud under Windows at all. See end of file in Chapter Technobabble for details. autoexec.bat ============ The autoexec.bat should at least contain the following. The paths should remain as they are, but you can change the drive-letters to whatever suits your system best. (You can of course change the paths that doesn't have 'lpmud' in them) NB! Make sure you get the '/'s and the '\'s in the right direction!: PATH c:\;c:\dos;d:\lpmud\bin set GO32TMP=d:/tmp set GO32=emu d:/lpmud/bin/emu387 driver d:/lpmud/drivers/tseng4k.grd gw 1024 gh 768 set SERIAL=d:/lpmud/lines set HOME=d:/ Note the following about the statements above: 1. The PATH should of course be set up to reflect where you have the files you need. Just add wherever you decided to put \lpmud\bin to it. 2. GO32TMP as to point to a valid directory! If you have already got a temp-directory set it to that, otherwise create one! This is the directory LPmud will use to swap objects onto disk to save memory. 3. GO32 requires some explanation, and can be split in two parts: emu d:/lpmud/bin/emu387 This is the maths coprocessor emulation. driver d:/lpmud/drivers/tseng4k gw 1024 gh 768 This is the graphics driver, and must be changed to whatever you have. The different drivers can be found under d:/lpmud/drivers vga.grd is probably a good choice if you are using a vanilla vga board. The gw and gh is default graphics width/height. I'm not totally sure if this driver-part is actually needed or not. Experiment... NEW! I've been reliably told that the 'driver d:...' bit can happily be scrapped since LPmud doesn't use any of the graphics modes at all. The segment below is an extract from a document explaining the use of the GO32 variable. Some people might find it useful. The full document is included as \lpmud\drivers\readme.jo ************************ EXTRACT START ************************************ The GO32 environment variable: This variable controls the options available in go32 or debug32. The syntax of this variable is: SET GO32=[parm [value]] [parm [value]] . . . Parameters: ansi Use ANSI commands to control the color in debug32 mono Use the Monochrome monitor for debugging - useful when debugging graphics applications 1rm Redirect stdout (file #1) to the monochrome monitor 2rm Redirect stderr (file #2) to the monochrome monitor 1r2 Redirect stdout (file #1) to stderr (file #2) 2r1 Redirect stderr (file #2) to stdout (file #1) emu [path] Use the specified file as the 80387 emulator driver [path] Use the specified file as the graphics driver gw [width] Default graphics width gh [height] Default graphics height tw [width] Default text width th [height] Default text height These parameters may occur in any order. Note that "1rm" and "2rm" are done before "1r2" and "2r1", so "1rm 2r1" sends stdout to the mono monitor and stderr to any redirection used. Examples: C:\> set GO32=mono driver c:\djgpp\drivers\tseng4k.grd gw 1024 gh 768 tw 132 th 43 C:\> set GO32=ansi C:\> set GO32=driver c:\djgpp\drivers\tseng4k.grd ansi C:\> set GO32=mono 1rm 2rm * The paging mechanism understands how SuperVGA's map their memory onto the AT bus and automatically swaps pages as the program tries to access them. The program sees a linear range from 0xD0000000 to 0xD0100000 that corresponds to each pixel in the 256-color modes of SuperVGAs. To use this feature, you'll have to set the GO32 environment variable like this: C>set go32=driver c:\djgpp\drivers\tseng4k.grd gw 640 gh 480 tw 132 th 43 These parameter pairs can be omitted or rearranged as needed. They are the "driver" name, default graphics width and height, and default text width and height. Libgr.a doesn't have to be recompiled, nor do graphics programs, when a different graphics mode is selected (the extender handles it). It is strongly recommended that the program use the GR_default_graphics and GR_default_text modes to switch to graphics or text. These modes use the parameters specified by the GO32 environment variable, allowing the user to select a favorite graphics and text mode. ******************************* EXTRACT END ******************************** 4. SERIAL is a variable that points to a file where LPmud can find default variables for serial line use. You can connect to LPmud using the serial port as well as the keyboard itself. Even though you don't intend to use this feature, this variable has to point to a (potentially empty) file. Here is the HELP screen in the comdrv.com program: Usage is COMDRV [-C n] [-E n] [-I n] [-M] [-N n] [-O n] [-P n] -C n use COM port n (1<=n<=4). Default is 1 -E n enable line editing in a buffer of n characters -I n set input buffer size to 2^n bytes (4<=n<=15). Default is 4096 (2^12) -M monitor all COM ports (ignores all other options) -N n use interrupt number n (0<=n<=15). Defaults are 4,3,4,3 -O n set output buff. size to 2^n bytes (4<=n<=15). Default is 4096 (2^12) -P n use port base n (0<=n<=FFFE). Defaults are 3F8,2F8,2E8,2E0 Here is John Olson's explanation of the SERIAL stuff: ************************** SERIAL EXPLANATION START *********************** If you plan to support connections over serial lines, you have to load a communications driver for each port. The following command loads a driver for COM2 with local line editing (79 characters buffer) enabled: \LPMUD\BIN\COMDRV -C2 -E79 In addition to that, \LPMUD\LINES has to be edited to reflect the configu- ration, e.g.: # line bps carrier 1 2400 y 2 38400 n \LPMUD\LINES has to be present and the environment variable SERIAL has to point to it even if no serial lines support is desired. Lines can be commented out by prefixing them with a '#'. + + I'm not currently using the serial facilities, so my \lpmud\lines file + has only got the line '# This is a file' in it, nothing more. There + are three files included in this archive you can look at: + \lpmud\lines, \lpmud\lines2 and \lpmud.ser + Choose the one that suits your needs. + -OK **************************** SERIAL EXPLANATION END *********************** 5. The HOME variable. If you are planning to use indent.exe (I've never used it...) then this variable should point to the directory in which the file indent.pro resides. I haven't got this file, nor have I seen it. I assume it's some sort of template for how the indent program should indent your C file... If you don't intend to use the indent program (i.e. since you technically can't :-) just set this variable to point to a VALID directory. That concludes the things you SHOULD have in your autoexec.bat. Whatever more you put into it is your choice. config.sys ========== BUFFERS=30 STACKS=0,0 FILES=40 SHELL=C:\DOS\COMMAND.COM C:\DOS\ /e:1024 /p INSTALL=C:\DOS\SHARE.EXE Some notes on the lines above: 1. Buffers, stacks and files: Doesn't really matter how much you set these to. (I would assume that LPmud use a few open files at the same time though, so a good, high number on buffers and files might be a good idea.) 2. The shell variable has to be set (I think :-). The above line is what I have it set to, your own might be different. Just make sure it's set. 3. The SHARE line should go in somewhere. You can just as easily just start it somewhere else. 4. If you decide to use the 'ansi' option in the GO32 variable (see above) then remember to start up ANSI.SYS as well! I.e. put DEVICE=C:\DOS\ANSI.SYS in your config.sys. 5. Again you can include any other elements in the config.sys you might need, such as device drivers for disks, harddisks, videocards etc etc That should conclude the changes you have to do to your setup files. We're almost ready to roll now... The following are two batch-files I wrote to start up LPmud. You might want to copy them into a directory in your path. lpmud.bat --------- d: d:\lpmud\bin\pars312c >>\lpmud\log lpmud3.bat ---------- d: d:\lpmud\bin\pars312 >>\lpmud\log You might not need the last one, since that requires that you have a 3.* MUDLIB. You are most likely to have a 2.4.5, since that is what comes with this archive... Of course, if you have installed LPmud on another drive, change the drive- letter in the above batch-files. That should be you up and running LPmud 3.1.2. MSDOS version 1.2. Now reboot to make the changes you have made to the autoexec.bat and config.sys take place and type lpmud If you're lucky and everything has gone according to plan, you should see the following line appear after the batch file has been executed and the direcory change has taken place (Inside the batch file): Parse 3.1.2.-MSDOS v1.3 (COMPAT_MODE) compiled by Aragorn@NANVAENT 29/3-92 cadp01@vaxb.strath.ac.uk (Olav Kolbu) okolbu@ifi.uio.no o If something else happens then you (or I) have made a mistake somewhere. See Appendix A for troubleshooting. o If that's what you see take two seconds to run around your chair and scream YYYYYYYYYEEEEEEEEESSSSSSSSSSSSSS!!!!!!!!!!!!! Now, after around 5-10 seconds (The parser has to load /obj/armour /obj/weapon and all those...) you should see a reversed line at the botton of the screen saying #1 [AVAILABLE] Hit RETURN, and the text will change to #1 [CONNECTED] A few seconds after that (It now loads /obj/player) the login screen should appear, looking something like this: Welcome to (LPmud 2.4.5). Administrator and supreme ruler : Version : 03.01.02 What is your name : Log in as user 'aragorn', with no password. This is a level 1000 user, but hasn't got a workroom or anything. If you have come so far, it's time to run around that chair again... Now, there are a few special keys you can use: F1 ... F10 switch to the respective console You can have up to 10 people logged in on the console at the same time, swapping between them by pressing a Function key from 1 to 10. Alt-H ("hangup") disconnects the currently active console Alt-S suspends LPmud and spawns a DOS shell. EXIT returns to LPmud. If you haven't got a TSR editor (get one) or are very keen on programming in 'ed' then this is the command you will use a lot when you're editing. The game is shut down with the shutdown command which can be issued by any wizard. The people command shows the connection type in the "IP address": 0.0.0.100 to 0.0.0.109 are virtual consoles (I.e. F1 - F10) 0.0.0.110 to 0.0.0.113 are COM1 ... COM4 THAT'S ALL, FOLKS! ****************************************************************************** * Chapter 6. Odds and ends * ****************************************************************************** As you are well aware of, DOS is rather restricted when it comes to filenames, especially compared to UNIX. This means that some filenames that are written UNIX-style, e.g. this.is.a.file, has to be converted to DOS format. The standard 2.4.5. mudlib contains a lot of these conversions. E.g. mount_top2.c has become mnt_top2.c under DOS This shouldn't inhibit you much, but remember to check if the two filenames are the same in UNIX and in DOS when you are transferring castles to and from your PC to a UNIX box. Typically this should only be necessary for the destination of your castle.c and other object you load outside your castle. ****************************************************************************** * Chapter 7. Technobabble * ****************************************************************************** If you are satisfied with your achievements so far and want to get on with the coding, then you can just scrap this chapter. It just for those who like to get an explanation why things work/doesn't work. OTHER PROGRAMS -------------- Most of you out there that got the 1.2 version (this is 1.3) of OK312 probably didn't like the fact that LPmud had to be run under an almost bare setup (no memory managers or anything.) This was due to the fact that GCC (The UNIX C compiler ported to MSDOS) didn't support any other modes than real mode using a flat addressing space. The latest version of DJ's GCC for MSDOS supports both XMS & VDISK memory allocation strategies. This means that LPmud will run quite happily under VCPI programs such as QEMM and 386MAX. It will, however, NOT run under Windows 3.x as this is a DPMI and doesn't support full VCPI. Here are some extract from the readme's that came with the compiler: * The VDISK method of allocating extended memory is supported. The INT 15h method is also. When the extender runs out of conventional and extended memory, it uses a paging file named $(GO32TMP)/pageXXXX.386, where XXXX is an unspecified hex value. This file is normally removed on exit. * Up to 128 MB of physical memory and 128 MB of disk swap space are allowed. A 512K machine is sufficient, but very slow due to paging. * The extender runs programs at logical address 0. A copy of the first 1 MB of physical memory (including the AT channel) is mapped to 0xE0000000 in the program's address space. The stack grows down from 0x7FFFFFFC in the program's address space. Data usually starts at 0x00400000. OK NOTE: The 'extender' is the go32.exe program that kickstarts the rest of the parser and handles all the memory stuff. * Symbols are stored in virtual memory, so you won't run out of symbol space until both extended memory and the disk are all used up. For large programs, you might notice a slight delay while it looks up symbols. Programs with a lot of lines in a given module may run out of memory as the line number table is built in real memory and transferred to virtual memory. * Signals are not reported to the program. However, interrupts do continue to get serviced while in protected mode (ie: keypress, timer, etc). Here are some Questions and Answers from the GCC readme's. They apply to LPmud as well... Q: I installed an 80387 emulator in my AUTOEXEC, but it still doesn't work. Why? A: The CPU is running in *protected* mode, not real mode, and the information needed to emulate the 80387 is different. Not to mention that the exceptions never get to the real-mode handler. You must use the emu387 emulator, which is designed for go32. Q: I can't run a.out programs under Windows. A: Nope, you can't. Go32 only supports VCPI, and Windows provides DPMI 0.9, which isn't enough for Go32 to work correctly. Q: Can I run this on my 286? It has protected mode also... A: True, but the 286 isn't a 32-bit processor. A 386 really is required. Q: Can I use gcc on my 512K machine? A: Yes, but the disk better have at least 4Mb of free space for paging. Go32 will use all available extended memory (up to 128M) and up to 128M of disk space, for a grand total of 256M of virtual memory for your application. Try a malloc(50*1024*1024) some day. Q: Why do my compiles are running VERY SLOW, even though I use a ramdisk for swap and a disk cache? A: Gcc requires at least 1Mb of virtual memory to run, usually close to 1.5M. If there isn't this much real memory available, it starts paging to disk. It's good to leave about 1M of extended (not expanded) memory available for go32 to run programs with. When it needs to page a lot, you spend most of your time paging and little time actually running. Note that if you are running with a VCPI server, like QEMM or 386MAX, then go32 will use *expanded* memory for it's physical memory needs, not extended. NOTE THE ABOVE (last two sentences)(re-read it until you get it...) Will vastly improve your throughput if you have messed up your memory allocations in the first place. Q: Go32 complains that the CPU must be in V86 mode to run. A: When the CPU is in V86 mode, the V86 manager must provide VCPI services for go32. Since VCPI is an extension to EMS, disabling EMS will disable VCPI, and prevent go32 from running. For emm386.sys, this means that you can't use the "noems" switch. AGAIN NOTE THE ABOVE, especially the bit with the 'noems' switch! Memory usage ------------ As some of you might have found out, the COMPAT_MODE parser has increased in size by about 45K since the last version. This is due to the fact that the new GCC (v2.1) simply refuses to compile some of the source files using the optimize (-O) flag. No idea why actually, it doesn't even give an error, just doesn't produce an object file... I ran the COMPAT_MODE version under a 32-bit debugger to get some idea on the memory usage. These data are VERY approximate but is probably correct to the nearest 100K or so. I'm not sure how the debugger works compared to the executable itself, but here goes: When loading the parse in under the debugger it creates about 100K of debug informaton and then starts the parser. Just before it starts loading in the first LPC objects the memory usage is typically 400K-450K. After that you're mostly on your own as the rest of the memory use depends on the number of castles you load and how many objects they in turn autoload. At the point where I get the login-prompt I use about 750K-800K (got a few heavy objects and a massive player.c). From there on it usually only increases a little. To get a good idea on how much memory you are using press Alt-s in the game. This will give you a DOS prompt, but NOT until it has swapped the ENTIRE mud out to disk. All you have to do to check the memory usage is to locate the swap-file, it should be in the directory you have designated as your temp directory (look at environment variables TEMP/TMP/GO32TMP or similar). I'm not sure what will happen if it runs out of diskspace when trying to swap out. It might die horribly or it might just tell you it can't give you a DOS prompt... read_file() problems -------------------- The read_file() has been knackered on most of the MSDOS conversions of the parse so far. This is due to the fact that MSDOS uses TWO characters to represent a , both Carriage Return and Line Feed. UNIX only uses 1 character (Line Feed). This then causes some problems when the compiler reports how many characters it just read in from a file. LPmud internals work in UNIX 'mode' i.e. is taken to be 1 character. GCC, the C compiler, is trying to do both ending up making a mess of some of the read/write file functions, especially fread()/fwrite() used by read_file()/ write_file(). So, basically, I had to fake the return value from the fread() and do a bit of cleaning up at the end of the string returned... Here goes: Fread() is called like the following in the fread(): fread(return_string, size_of_object, num_object, file prt); where return_string is what you get back, size_of_object is how large the object you want to read in is (in bytes) and num_object is the number of objects of the previously mentioned size to read in. Usually the object business is dropped and something like: fread(str, 1024, 1, fp); is used to read in 1024 bytes from the file. The problem is that this function usually returns 0 if it fails. The MSDOS version also returns 0 if it couldn't read the full 1024(or whatever) bytes... Had to fix that... Another thing is that the function believes that it has read in more than it actually has, since a CR-LF in the file is converted to a LF in the returned string. So for every CR-LF in the file you get and extra redundant character at the end of the string. E.g. File : abCRLFcdCRLF (8 characters) gives: abLFcdLF (8 characters) So I had to go through the string, count the Line Feeds and subtract that number of characters from the end of the returned string. Not the most elegant solution in the world, but... :-) I must say that there are weeks between every time I see such a badly written function like the LPmud read_file()... ****************************************************************************** * Appendix A. What to do when something goes wrong, and why. * ****************************************************************************** Common problems: Q: Nothing happens when I start the parser! A: The file go32.exe must be somewhere in your path for things to happen. It can be found in \lpmud\bin, and since this directory should be in your path already this problem shouldn't occur if you don't move it. Q: It just comes up with: CPU must be in REAL mode (not V86 mode) to run this program A: You are running a program that puts the CPU in the wrong mode. This can be programs like Memory Managers, Windows, DesqView etc etc Remove these from memory (alternatively remove them from your startup files (autoexec.bat & config.sys)) and try again. Q: It just comes up with Cannot find SERIAL (or something similar) A: There are a number of DOS variables that has to be set, see Chapter 5. Q: It just comes up with No 387 detected! (Or something similar) A: Again, several DOS variables have to be set. The GO32 variable handles 387 emulation, see Chapter 5. Any more common questions??? ****************************************************************************** * Appendix B. Where to go for extra goodies. * ****************************************************************************** There are numerous sites where you can get LPmud specific stuff. Castles, parsers, mudlibs etc etc Here is a list of the most prominent ones, please mail me if you think you know of any that are not on this list but deserve to be. * foof... IP = Dedicated MUD site, check out /MsdosMUD/lp for MSDOS specific LPmud things. * alcazar.cd.chalmers.se IP = THE site... (Hi Lars! :-) I know this is rather weak at the moment, but I'm typing this at home and haven't got my lists here. Will be expanded in the next version (If you send me some info... :-) ****************************************************************************** * Appendix C. List of (most of the) files in these archives. * ****************************************************************************** ok312exe.exe ------------ \lpmud\bin\emu387 : The maths coprocessor emulator \lpmud\bin\comdrv.com : The Serial port driver \lpmud\bin\fundesc.exe : Semi useless program... \lpmud\bin\indent.exe : Semi useless program... \lpmud\bin\go32.exe : 386 Extender (VITAL!) \lpmud\bin\pars312.exe : The new parse, in COMPAT_MODE (2.4.5 ML) \lpmud\bin\pars312c.exe : The new parse, in non-COMPAT_MODE (3.* ML) \lpmud\bin\tarpat.exe : Tar file extracter. \lpmud\bin\compress.exe : Compressor/uncompressor. \lpmud\bin\master.c : LPC file (Master object) \lpmud\bin\simul_ef.c : LPC file (simulates obsolete functions) \lpmud\config\*.c : Some source files, can't see why I should keep these... \lpmud\doc\bugs : Bugs not yet fixed (From the CD gang) \lpmud\doc\compat : What has changed for the COMPAT_MODE \lpmud\doc\compress.doc : Manual for \lpmud\bin\compress.exe \lpmud\doc\tarpat.doc : Manual for \lpmud\bin\tarpat.exe \lpmud\doc\autoxbat.smp : Sample autoexec.bat from John Olson \lpmud\doc\cfgsys.smp : Sample config.sys from John Olson \lpmud\doc\copyrigh : Copyright notice from Lars \lpmud\doc\credits : Credits list from Lars \lpmud\doc\done : What the CD gang has done so far \lpmud\doc\readme : Old readme from Werner Almesberger \lpmud\doc\readme.1st : This file, written by Olav Kolbu \lpmud\doc\copying : FSF Copyright notice (Since this is compiled with GCC...) \lpmud\drivers\aheada.grd : Graphics drivers for use in the GO32 : variable. \lpmud\drivers\aheadb.grd \lpmud\drivers\ati.grd \lpmud\drivers\chips.grd \lpmud\drivers\everex.grd \lpmud\drivers\genoa.grd \lpmud\drivers\oak.grd \lpmud\drivers\paradise.grd \lpmud\drivers\trident.grd \lpmud\drivers\tridnt89.grd \lpmud\drivers\tseng3k.grd \lpmud\drivers\tseng4k.grd \lpmud\drivers\vga.grd \lpmud\drivers\video7.grd \lpmud\lines : The file pointed to by the SERIAL variable \lpmud\lines2 : Sample \lpmud\lines file \lpmud\lines.ser : Sample \lpmud\lines file \lpmud\version.oms : My (Olav Kolbu) version file, please quote this when mailing me a problem. ok312lib.exe ------------ \lpmud\mudlib\* : The complete 2.4.5 MUDLIB ok312u13.exe ------------ \lpmud\bin\go32.exe : VCPI compatible 386 Extender. \lpmud\bin\indent.exe : New version of useless program... \lpmud\bin\pars312.exe : New, working, native mode parser. \lpmud\bin\pars312c.exe : New, better, COMPAT_MODE parser. \lpmud\bin\emu387 : Faster maths emulation ****************************************************************************** * Appendix D. Caveat & Revision history. * ****************************************************************************** CAVEAT ------ As always when converting a new parse to MSDOS there is a whole lot that has to be fiddled, tweaked, added and removed. The usual MSDOS routines by Werner Almesberger has been used (Got any updates Werner?). I've only used it for a couple of hours, but everything seems to be in order. If you find any bugs that might have been caused by the conversion to MSDOS please let me know and I will try to fix them. (They might be Werner Almesbergers fault 8-) File sharing sucks in LPmud. Shelling out to dos (Alt-s) too many times, and the parser will fall over. When you get 'Can't #include "std.h"' or something similar and you know it's there, it's time for a shutdown and reboot. A TSR editor might be a good solution. This behaviour is lessened by the use of SHARE.EXE and keeping the variables FILES and BUFFERS relatively high. Might experience some problems regarding MSDOS use of CRLF vs UNIX LF RELEASE HISTORY --------------- Release 1.3 : 24/4-92 Name : ok312exe.exe and ok312lib.exe Replaces version 1.2 Also ok312u13.exe, containing just the files that have changed from version 1.2 to 1.3 : Fixed several bugs: 1. Native mode parse now actually WORKS! :-) 2. Upgraded docs (A LOT!) 3. Both parsers now work with VCPI programs (QEMM, DESQVIEW etc) 4. Changed a memory allocation from 800K to 100K 5. Fixed read_file() Release 1.2 : 8/4-92 Name : ok312exe.exe and ok312lib.exe : Added a MUDLIB (2.4.5.) Rewrote the documentation. If you can't follow them now, please tell me what your problem is and I'll include it in the docs. Release 1.11 : 6/4-92 Name : m312-111.exe : Found out that the 1.1 release lacked a file, namely go32.exe. This is the DJ-GCC 386 DOS Extender, i.e. the program that makes room for the parse. It was in my path all the time, so I didn't think the mud needed it at all. Sorry about that... ;-) This release never made it out (Well, it was on foof for about 1 hour before I removed it again. Too many mail messages wanting a mudlib included.) Release 1.1 : 1/4-92 Name : msdos312.exe : Released both 3.1.2 parsers for MSDOS. Included some help in installing LPmud from scratch. No mudlib included. Next version will probably have mudlib(s) included, possibly in separate files. Got swamped again by people that couldn't get it to run properly... 29/3-92 : Released the 3.1.2 COMPAT_MODE parser for MSDOS. Got swamped by people emailing me to put up 3.1.2 non-COMPAT_MODE and also to provide some help in installing it. ??/?-92 : Compiled 3.0.46 - 3.1.1, not released. ??/?-91 : Got a copy of Werner Almesbergers LPmud 3.0.45 port for MSDOS. Release 1.11 : 6/4-92 : Found out that the 1.1 release lacked a file, namely go32.exe. This is the DJ-GCC 386 DOS Extender, i.e. the program that makes room for the parse. It was in my path all the time, so I didn't think the mud needed it at all. Sorry about that... ;-) ---------------------------------------------------------------------------- COMING : 1. The CD versions of the parser (1.0.55?) and mudlib for MSDOS. This was released (but not posted anywhere yet) by Erik Rosendaal (sp?) so I wont bother with this one. 3. Well, what do you need? NOT COMING : 1. A Novell Netware version. I have no(well, almost) access to a Novell network, so I'm not going to attempt anything like that in the near future. If any of you know people working on such a project please let me know, I know of several people who would die for such a conversion... :-) WANTED : Other 3.0 mudlibs... ADDRESSES --------- I can be reached at the following addresses: MUD --- Aragorn on NANVAENT (Administrator) IP=130.159.220.6 Port=3000 - University of Strathclyde, Glasgow, Scotland. Open 5pm-9am Weekdays, all day weekends (GMT) EMAIL ----- o.kolbu@strath.ac.uk (at least until July 1992, probably longer) okolbu@ifi.uio.no (Always) SNAIL-MAIL: ----------- Olav Kolbu (Until July 1992) 45 1/r Bellshaug Gardens Glasgow G12 0SA Scotland Olav Kolbu (Always) Libakkveien 1 A 1184 Oslo 11 Norway Now, this archive is provided free of charge (as most other programs should). All I'm asking for is that if you find this archive/information helpful send me a postcard. :-) (Use the address in Norway...) No postcard so far... :-( HAPPY MUDDING!!! The usual Trademarks and Copyrights apply to the commercial products I have mentioned in the text above. ***************************** END OF FILE ************************************