LPMUD PARSE MUDOS 0.9.16-MSDOS - Version 1.0b
---------------------------------------------
Converted to MSDOS by Olav Kolbu (Aragorn@NANVAENT & @TMI-2)
- Addresses at the end of the document.
- Good MudOS(ish) LPC coders wanted for mountainous
area, enquire at NANVAENT... ;-)
This file is an exact copy of the file readme.1st found inside the
ok0916.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.
NOTE: This is a PLAIN, no frills MudOS 0.9.16 driver for MSDOS. NO
extensions have been added. This means that if your mud-site
have modified the driver, its mudlib is not likely to work.
If there is enough demand, I might do specific drivers. Have
the administrators of the mud in question send me an email.
NOTE2: This readme-file was written a bit too fast, so disregard
typos, funny sentences and the complete lack of structure... :-)
Archive name : ok0916.exe The MudOS driver, config and
other necessary files to run the driver.
NO Mudlib! I repeat, NO Mudlib.
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 OK0916 is
compiled using GCC, which ONLY produces 386-code. So there
is absolutely NO possibility that it will work on a 286.
About 400Kb for the driver and its support files.
In addition to this comes the disk space LPmud uses to
swap objects out to disk, not too much. The game takes
about 1Mb in your temp-directory when swapped out completely
(shelled to DOS).
The more space the better in other words...
Introduction
------------
Some of you have possibly used the ok312.exe, either in NATIVE or COMPAT
mode. Well, this is the MudOS version. Works more or less the same. This
release is ment for people who have access to a MudOS compatible mudlib.
This can be Basis, Nightmare or the one your favourite MudOS mud uses.
The official MudOS mudlib (Basis) is currently undergoing a rewrite and
if the TMI-2 mudlib boyz get their act together I'll make a bundled version
at some point.
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...
SHORT INFO:
You can use VCPI compatible programs with this program.
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...
More compatibility details at the end of this file.
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.
7. Technobabble (including info about known problems)
8. General ramblings about Borland C/MSC/Windows etc.
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.
D. Caveat & Revision history.
E. Addresses and the POSTCARD bit.
X. Changes since the last release.
*******************************************************************************
* 1. What this archive contains. *
*******************************************************************************
Basically, everything you need EXCEPT a mudlib.
What it doesn't contain is the SOURCE for the driver. IF you need it,
tough cookies. It's not _that_ hard to convert, and you can get the
unix source from TMI-2... :-)
ok0916.exe
------------
Doesn't contain any directory structure, so the files should be extracted
(by simply running ok0916.exe) in x:\lpmud\bin, where 'x' is your favourite
hard disk.
The following files are included in the archive:
ok_mudos.exe - The driver itself, this is the one you run.
readme.1st - Duplicate of this file.
config - Runtime configuration of the driver.
emu387 - Maths emulator used by the driver.
go32.exe - 32 bit extender used by the driver.
options.h - This is a file from the source, just to
let you know which #defines were used
to compile the driver. Fairly standard stuff.
******************************************************************************
* 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 a few Mb free, size depending on the mudlib you intend
to use. The driver only takes about 500Kb, but while extracting the
archive you will need about 1 Mb.
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.
- A MudOS compatible mudlib.
NOTE! This Mudlib should go into the directory \lpmud\lib3, or you
have to change the file 'config' (and the batch-file explained
later in this document) to reflect the change. I strongly
recommend you to use \lpmud\lib3 to avoid troubles.
That's about it, the rest is included in these archives.
******************************************************************************
* 4. What to do with this archive. *
******************************************************************************
Right... Here we go. This is just to install the archive. 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 *smile* :
1. Find a hard disk that has more than 1Mb free, alternatively
MAKE SPACE :-) When you get the mudlib, more space will be needed.
(Might as well make some space right away, as the driver is NO good
without a mudlib.)
2. Create the directory \lpmud
I.e. go to your top directory and type
mkdir lpmud
This new directory should be empty.
3. Go into the \lpmud directory.
4. Create the directory \lpmud\bin
I.e. type
mkdir bin
This new directory should be empty.
5. Move the okmudos.exe into this new directory, \lpmud\bin
6. Execute the file okmudos.exe
6. If nothing has gone wrong so far, i.e. no 'disk full' errors or anything
you can delete the file : okmudos.exe. Make
sure you have backups though, in case you screw up later... :-)
8. This concludes the extraction. Relax, have a Coca Cola. (Did you know
that 'Coke' is the second best known name/phrase in the entire world?
('OK' is #1)). Oh well, enough trivia, 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.
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.
MudOS 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.
If you didn't understand the above, just remembers this: If the driver
starts up nicely, you're ok. If nothing happens or it dies, there might
be a program in your autoexec.bat/config.sys that MudOS doesn't like.
Alternatively you haven't followed the instructions closely enough.
Comments on a few DOS programs :
SHARE.EXE : This is a good thing to run, might save
you corrupting a few mud-files.
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.
STACKER : It will run on a stacked harddisk, and it
highly recommended that you buy this program
as it will save you a lot of diskspace if
you plan on having a large mudlib.
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
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.
THIS IS VITAL! MudOS have to have access to its auxillary files!
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 itself onto disk when you shell out to dos.
Needs about 1.2-1.5Mb free.
3. GO32. Not much to say, keeps track of the Maths emulator.
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.
Note that this feature isn't really supported, you can get a package
called comdrv17.zip (Think it's zip) on the net, and this will allow
you to connect the mud to serial input (modems etc). I haven't had any
use for this so I haven't included it.
Here is a sample \lpmud\lines file, the rest of the instructions you
need to use the serial stuff is in the comdrv17-archive:
# Start of file, comments like this is skipped
# line bps carrier
1 2400 y
2 38400 n
# End of file
5. The HOME variable.
Erm, not really sure if this is needed anymore. Just set it
to a valid directory and forget about it...
That concludes the things you SHOULD have in your autoexec.bat. Whatever
more you put into it is your choice.
Note that if you have a lot of variables set already (or your path is long)
then MSDOS might not be able to set all the variables. Verify that all
the variables are set by typing 'set' and checking against the list above
once you have rebooted after the autoexec.bat/config.sys changes.
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! The shelling out-sequence uses
it (system(getenv("COMSPEC")) for those who wants to know. 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. 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 is just a quick batch-file to start LPmud and redirect the
error-messages. You might want to copy it into a directory in your path.
lpmud.bat
---------
d:
d:\lpmud\bin\ok_mudos.exe >>d:\lpmud\lib3\log\stderr
Of course, if you have installed LPmud on another drive, change the drive-
letter in the above batch-files.
Note also that the batch-file redirects errors etc into
\lpmud\lib3\log\stderr. This is just a random file, and can be changed
to suit your needs.
That should be you up and running MudOS 0.9.15 (if you have a mudlib.)
Now reboot to make the changes you have made to the autoexec.bat and
config.sys take place and type
lpmud
This can be done without a mudlib as well, just to make sure everything
is set up correctly.
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):
LPmud Driver MudOS 0.9.15 - MSDOS v1.0a
compiled by Aragorn@NANVAENT 20/3-93
okolbu@ifi.uio.no (Olav Kolbu) o.kolbu@strath.ac.uk
This is a beta-release, and I would appreciate some feedback on it.
Here are some of the known problems, and other bits that might get fixed:
- Flushing the errors so that the redirected errors are up to date.
For some reason fflush() doesn't work, probably because of the
multilevel dup()'ing I had to do. :-)
- get_dir() doesn't take wild-cards. Looks like stat() and
a few other library fns doesn't work the same under DOS.
- Probably millions of other bugs, you try converting this... ;-)
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!!!!!!!!!!!!!
IF you don't have a mudlib, the driver will keel over here. You can read
the reason in the redirected file (\lpmud\lib3\log\stderr or whatever
you have called it).
If you HAVE a mudlib, the following should happen:
Now, after around 5-10 seconds of frantic disk activity, 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 the login screen should appear, with a familiar
login prompt at the bottom. The exact wording of this is impossible for
me to know, as this is handled by the mudlib you are using.
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 players 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
Like leaving a player net-dead. Good to have for those
bugs in the mudlib that leaves your player with no
way of quitting.
Alt-S suspends LPmud and spawns a DOS shell. EXIT returns to
LPmud.
If you haven't got a TSR editor or are very keen
on programming in 'ed' then this is the command you will
use a lot when you're editing.
This command uses the environment variable COMSPEC, if
there is enough call for it I might have it look for
other variables as well so you can customise the spawn.
Ctrl-C Pressing this a couple of times will kill the driver.
(You'll get a few <3>'s but eventually you'll beat the
signal-handler.)
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 *
******************************************************************************
Note 1
======
The name 'MSDOS' is always set in this driver, so you can have MSDOS specific
code in your lpc-source.
E.g.
.
.
.
write("You are running: ");
#ifdef MSDOS
write("THE MSDOS DRIVER!!!\n");
#else
write("a unix driver...\n");
#endif
.
.
.
Note 2
======
Socket-functions.
All the socket-efunctions except one (dump_socket_status()) return -42
(No sockets in DOS... :-)
Note 3
======
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.
When converting a mudlib to DOS format, this is the primary problem you
will come across. The MSDOS MudOS driver doesn't care too much about
your files having CRLF (DOS style) or LF (UNIX style), but it has to have
its filenames in order.
Here are a few points about filenames:
1. Only 1 (one) full stop ('.') in a filename in DOS.
2. Up to 3 characters after the (possible) full stop.
3. Up to 8 characters before the (possible) full stop.
4. IF your unix files have more than 8 characters before the full stop
you will have to make sure that ALL files in a directory are
distinguishable in the first 8 characters (only required for
files with the same extension of course). The MSDOS driver manages
to match say read_file("twiddlybob.c") with the MSDOS filename
'twiddlyb.c', but NOT read_file("aragorn.test") with
the MSDOS filename 'aragorn.tes'. (I _think_ the last statement there
is correct... :-)
Problems arise when the UNIX files are too long:
UNIX:
work_of_art_1.c
work_of_art_2.c
These two files both become 'work_of_.c' under dos, with the second
file overwriting the first one when extracting from, say, a tar file.
(A typical example is the MudOS source itself, where socket_events.c
and socket_errors.c both come out as socket_e.c. (Fooled at least 1
guy... (No, it wasn't me :-))
5. No fancy characters in filenames, MSDOS is quite strict on this. See
your DOS manual for a list of valid characters.
******************************************************************************
* 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. Also if you
experience some strange happenings, this might be the place to look
for explanations.
OTHER PROGRAMS
--------------
The latest version of DJ's GCC for MSDOS supports both XMS & VDISK
memory allocation strategies. This means that MudOS 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 driver 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).
(If you didn't understand any of that, remember the title of this chapter...)
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
------------
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).
If it runs out of diskspace when shelling out to dos, the driver will crash.
get_dir() problems
------------------
The DOS version of stat() doesn't quite work the way the UNIX one does,
so this function (get_dir()) doesn't at the moement take wild-cards.
get_file("/w") will return ({ "w" }), whereas get_file("/w/") or
get_file("/w/.") will return the files in the directory 'w'. Things
like get_file("/w/aragorn/*.c") doesn't work... I'm looking into it... :-)
Looks like I'll have to rewrite some bits of the function, possibly all
of it... Oh well, anyone care to contribute? :-)
flushing the error-file
-----------------------
As you will notice quickly, redirecting the errors doesn't do you that
much good. It's only when you shell out to DOS that the error-file
is updated. I tried fflush()'ing every file descriptor every heart_beat
but it still refused to work. This might have something to do with
the dup() stuff I do to tag the stderr onto the stdout stream.
I'm looking into that as well... :-)
socket-functions
----------------
All the socket-functions except one (dump_socket_status()) return -42
Couldn't be bothered doing a proper implementation... *grin*
(exec return dump_socket_status() at some point... ;-)
speed
-----
Due to several things the driver is quite slow when it comes to reading in
new lpc code like rooms and other objects. This is something you have to
live with or buy a faster machine... :-) I think DOS is the main offender
here, as on my machine MudOS runs a bit faster under Linux than under DOS.
I'm sure this didn't come as a big surprise... :-)
******************************************************************************
* Chapter 8. Ramblings etc *
******************************************************************************
/* START SHAMELESS PLUG */
In order to get this beast running under MSDOS I had to make 116 (just
counted my '#ifdef MSDOS' there :-) changes to the driver, some quite
major. In addition to this there is about 25K of extra code to handle the
socket stuff under MSDOS, so I do hope you appreciate this effort (by
sending me a postcard... 8-)
/* END SHAMELESS PLUG */
Some people have asked me why I've used GCC and not something more DOS-
specific like Borland C or Microsoft C. There are several reasons for this.
One is the memory addressing. GCC provides a flat memory model, while
BC/MSC still don't have any memory managers worth using. You have to compile
with a huge memory model and mess around with far pointers. Another is that
both LPmud 3.1.2 and MudOS (currently 0.9.16) are written to be compiled by
GCC. There are functions used in the driver source which is only available
in GCC, not in BC or MSC. Still, these are not too numerous, so a driver
compiled with BC or MSC is plausible. I tried it the other day with MSC, and
after a few hours I had something that almost linked. The only thing missing
was 3-4 functions used for handling/traversing directory-structures (opendir(),
closedir() and one or two others.) Don't know how it would have run though,
as I couldn't be bothered writing those functions. But it would have run in
an MS Windows window so it _might_ be worth doing. :-) Not too hot on it as I
don't use the MSDOS driver myself anymore, I use Linux.
******************************************************************************
* 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.
Note that the file SERIAL is pointing to has to exist.
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.
Q: It dies with an exception.
A: Make sure go32.exe is in your path and that there IS NO OTHER go32.exe
in your path that might be executed BEFORE this go32.exe. This go32.exe
is different from the one that came with ok312.exe and they are not
interchangeable!
Also, make sure that the relevant environment variable actually points
to the emu387.
Any more common questions???
******************************************************************************
* Appendix B. Where to go for extra goodies. *
******************************************************************************
There are numerous sites where you can get LPmud specific stuff. Castles,
drivers, mudlibs etc etc This is probably in the FAQ.
* ftp.ccs.northeastern.edu
Quite a lot of stuff and this is where ok09xx.exe will be uploaded
first.
* Wherever they keep Nightmare these days, it just changed I'm told.
* TMI-2
* alcazar.cd.chalmers.se (Old 3.1.2 driver for MSDOS is there)
THE site, but old and dated now... (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 D. Caveat & Revision history. *
******************************************************************************
CAVEAT
------
As always when converting a new driver 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, but rewritten quite extensively to fit the way
MudOS do their sockets. I've not actually tried this MSDOS driver (What!?),
but a very modified one ment to run the NANVAENT mudlib (support command
priority and a dozen new efuns.) 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.
File sharing sucks in LPmud. Shelling out to dos (Alt-s) too many times,
and the parser might 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. The real problem is that the chdir() command I use after a spawn()
doesn't seem to work sometimes. To make sure, always exit the shell when
standing in the root of the mudlib-tree (\lpmud\lib3) A TSR editor might
be a good solution. I can't recommend any such Shareware editors as all
the ones I know about you have to send money to the author before you get
the program at all. And I'm not doing that jsut to find out that the
editor doesn't work when running the mud... :-)
This file-sharing problem is lessened by the use of SHARE.EXE and
keeping the variables FILES and BUFFERS relatively high.
You might also experience some problems regarding MSDOS use of CRLF vs
UNIX LF. I've modified some of the relevant functions but some might
have slipped through the 60 seconds of alpha testing. *grin*
RELEASE HISTORY
---------------
************************* MudOS *****************************
Release 1.0b MudOS 0.9.16 LPmud :
28/3-93
Upgrade to 0.9.16, other than that it's
more or less equal to last release. See
Appendix X for changes.
Release 1.0b MudOS 0.9.15 LPmud :
20/3-93
First official release. Still a few known
bugs. NO mudlib.
Release 1.0a MudOS LPmud with NANVAENT (and Discworld) extensions.
13/3-93
Not released to the public. Internal NANVAENT
release.
********************** LPmud 3.1.2 **************************
Release 1.3 3.1.2 LPmud : 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 versions 3.0.46 to 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... ;-)
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. There might be one coming
from some other guys, as they have approached me about getting
the source...
******************************************************************************
* Appendix E. Addresses and the POSTCARD bit. *
******************************************************************************
ADDRESSES
---------
I can be reached at the following addresses:
MUD
---
Aragorn on NANVAENT (Administrator)
IP=130.159.220.8 Port=3000 - University of Strathclyde, Glasgow, Scotland.
Open 5pm-9am Weekdays, all day weekends (GMT)
/*** GOOD CODERS WANTED FOR MOUNTAINOUS AREA, ENQUIRE AT NANVAENT :-))) ***/
EMAIL
-----
okolbu@ifi.uio.no (Always)
o.kolbu@strath.ac.uk (Still good)
SNAIL-MAIL:
-----------
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. :-)
So far I've only gotten about 10 postcards from the massive number of
people using the 3.1.2 driver, and most of them seem to come from Canada.
If all of you bothered to send me a card, then you might see bugfixes on
this driver, and also updates as the TMI-2 driver boyz upgrade the driver.
(How's that for a threat... hehehehe :-)
HAPPY MUDDING!!!
The usual Trademarks and Copyrights apply to the commercial products I
have mentioned in the text above.
******************************************************************************
* Appendix X. Changes since the last release. *
******************************************************************************
Last release was 0.9.15 v1.0b.
This release is 0.9.16 v1.0b.
Changes:
1. Upgraded to 0.9.16.
2. Changed #define NO_ANSI to #undef NO_ANSI under compilation to
allow the use of ansi-codes in the mudlib. (Requires you to have
ansi.sys installed if you don't want garbage.)
3. This release (0.9.16) now has floats.
4. New efuns in 0.9.16, all these are available in the DOS version:
MISC FUNCTIONS
int reclaim_objects();
int memory_info(object|void);
object *objects();
void set_reset(object, void|int);
int shadowp(object);
void reload_object(object);
int virtualp(object);
MATHS FUNCTIONS
float cos(float);
float sin(float);
float tan(float);
float asin(float);
float acos(float);
float atan(float);
float sqrt(float);
float log(float);
float pow(float, float);
float exp(float);
float floor(float);
float ceil(float);
int floatp(mixed);
int to_int(string|float|int);
float to_float(string|float|int);
MATRIX FUNCTIONS
float *id_matrix();
float *translate(float *, float, float, float);
float *scale(float *, float, float, float);
float *rotate_x(float *, float);
float *rotate_y(float *, float);
float *rotate_z(float *, float);
float *lookat_rotate(float *, float, float, float);
float *lookat_rotate2(float *, float, float, float, float, float, float);
NOTE that four (4) of the new matrix efuns can actually crash the
driver, this is not my fault, but bugs in the unix driver... :-)
***************************** END OF FILE ************************************