Well compiling ROM into windows is done through a virtual unix
environment correct? Heres what I do to get this thing going. I re-wrote the
startup script in a dos batch file. The reboot + shutdown works now as a
result of this but no clue on how to get the log files working. I have to
copy the cygwin1.dll into the area directory. Copy a prog I use in the batch
file for a "sleep" mode called choice.exe. Now for Quickmud I didn't have to
mess with srandom or long random because it was allready commented out. Nor
deal with the adding of #include <crypt.h> into act_info.c and db.c I
believe. I just check those when makefile compiles because it will whine
about not having crypt properly initialized or something to that effect. I
move -lcrypt to the back part of
rom: $(O_FILES) section, because making through cygwin doesn't recognize
where its placed by default. Of course I'm just explaining what I normally
have to do with a stock rom. Also the removing of the *.o files doesn't
work. In the C_FLAGS I add -DUnix -DNOCRYPT -DBIT_COMPILE <<<since you have
unlimited bits. Unless this doesn't need to be done. Basically I use
Quickmuds makefile with the C_FLAGS adjustments.
I make the appropriate directories ie, player, gods, log. Get into
cygwin change directory over to mud/src and make. Usually I get a bunch of
errors about else statements and warnings but I went through and put the
appropriate braces for the else whining and fixed most of the bugs from the
bugs1.txt and bugs2.txt and darkoths bug txt. No warnings or the like, even
with Unlimited bits. Note: trying to run the mud as a plain old Windows app
right out of the box with minor changes to C-Flags caused it to crash while
starting up. Always a corrupt stack. Is there any other things I may do to
accomodate the unlimited bits because all those other snippets I checked
through on quickmud didn't have too much that altered the ROM base as much
as Unlimited Bits. I'm not writing to flame this is just a question on how
can I keep it stable "without" running it through cygwin's virtual unix
environment. Thanks for the input so far. Also I did just run gdb rom.exe
before because I didn't know about the gdb console.
Dantin
----- Original Message -----
From: "Ammaross Danan" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, July 20, 2002 10:29 PM
Subject: RE: Last post
> Maybe this needs to be cleared up...
> When you compile the mud in linux and you now have an executable, you
> can not take that executable and run it in windows, and vise versa.
> (believe it or not, this has to be pointed out sometimes)
> The unlimited bit system has nothing to do with accessing mem addresses
> that windows can't hit. Trust me, I should know.
> Last I checked, quickmud w/ unlim bits compiled clean out of the box.
> >From one of the previous posts, it read like Dantin was typing 'rom.exe
> 9000' within gdb... you need to type 'run' and then the arguments e.g.
> 'run 9000'
>
> > Nobody told me I had to go into console and type what you suggested
> > before run (port #). The only problem is its not crashing.. Or is that
> a
>
> > on windows just to utilize unlimited bits. Why is it that it once
> > compiled it will not run under windows? Well thats my question. Thanks
>
> So, you think that you use cygwin to compile the thing, go through all
> that trouble and then, you can't even use it under windows? Uh huh...
>
> > program=C:\QUICKMUD\AREA\ROM.EXE cs=017F ds=0187 es=0187 fs=5AAF
>
> Who would want to go through the trouble of moving their exe over to the
> area folder every time you made it? Let alone care to... (yes, I
> know...just stick it in the makefile, etc) I just like my exe in the src
> folder...keeps things nice and segregated.
>
> Ammaross Danan
>
>
> --
> ROM mailing list
> [email protected]
> http://www.rom.org/cgi-bin/mailman/listinfo/rom
>
