Cygwin SWR Copyover

Yea, I got SWR compiling in cygwin and I can run the server and everything, which is great, because I want to code offline. Problem is, copyover won't work due to the way the mud is handled. Has to make an exe that has to be in the area folder. I was wondering if there's a startup script or program that will do like it does in a unix shell and just run the mud and if it crashes reboot it. Mainly so I can copyover on the mud and not have to recopy the exe.

You can try editting you makefile to move the file into /area, and change the path of EXE_FILE.

I've already done that, but the way windows works, when the mud is running, the exe can't be modified, so I have to shut the mud down, re-copy the exe, reboot the mud. I was wanting to know if I could have it NOT do that so I could actually copyover. Perhaps move the mud temporarily into ram or something.

You can compile to a file called server.new.exe, and have your startup script always copy server.new.exe to server.exe before actually running it. That way, the MUD will shut down, the script will come into play, it will copy the newly compiled version, and life will be good. :)

That's still not exactly what I want, but is probably going to end up being what I'm going to do, nice idea. Although, I really want to have it all contained in one exe and have it copyover the same as on a UNIX system, without any user intervention and without the mud shutting down. I was wondering if was a way to do that.

It could be possible to have the copyover alternate between "server.1.exe" and "server.2.exe"- it would run whichever one is not running, and your compiler would compile to that. The program would have to know which executable is currently running, of course.

However, I've only heard bad things about getting copyover working correctly in Windows systems (even with Cygwin), so, well, I wouldn't get too hopeful about getting it to work just like on Unix.

Hmm, I was afraid of that. Sigh, guess I'll be converting my desktop to a Devian box sooner than I planned, damn windows. Besides, I hardly ever use it anyway, server time, laptop's all I use :)

Ksilyan said: "You can compile to a file called server.new.exe, and have your startup script always copy server.new.exe to server.exe before actually running it."

This is my current makefile:

------------------------------------------------------------
CC = gcc
PROF =
NOCRYPT =
#Uncomment the next line if you want request support
#DBUGFLG = -DREQUESTS
C_FLAGS = -g3 -Wall $(PROF) $(NOCRYPT) $(DBUGFLG)
#L_FLAGS = $(PROF) -lcrypt

O_FILES = act_comm.o act_info.o act_move.o act_obj.o act_wiz.o boards.o \
build.o clans.o comm.o comments.o const.o db.o fight.o \
handler.o hashstr.o id.o interp.o magic.o makeobjs.o \
misc.o mud_comm.o mud_prog.o player.o requests.o \
reset.o save.o shops.o skills.o special.o tables.o track.o update.o \
space.o bounty.o swskills.o

C_FILES = act_comm.c act_info.c act_move.c act_obj.c act_wiz.c boards.c \
build.c clans.c comm.c comments.c const.c db.c fight.c \
handler.c hashstr.c id.c interp.c magic.c makeobjs.c \
misc.c mud_comm.c mud_prog.c player.c requests.c \
reset.c save.c shops.c skills.c special.c tables.c track.c update.c \
space.c bounty.c swskills.c

H_FILES = mud.h bet.h

all:
make swreality
# rm -f $(H_FILES)

swreality: $(O_FILES)
rm -f swreality
$(CC) $(L_FLAGS) -o swreality $(O_FILES) -lm
chmod g+w swreality
chmod g+w $(O_FILES)

.c.o: mud.h
$(CC) -c $(C_FLAGS) $<

clean:
rm -f $(O_FILES)
------------------------------------------------------------

What do I need to add/change in order to be able to do as Ksilyan has suggested?

Marowi

This part here:


That's the rule that says what to do to build "swreality", the executable.
Notably:


That part there says to use the compiler $(CC), with flags $(L_FLAGS), to output executable "swreality" using code objects $(O_FILES), and finally, also link in the "math" library (-lm).

So, you'd just change swreality to swreality.new or something like that. Then you need to change the startup script, of course.

I can change it to that, but that would only work the first time, and only if I deleted the swreality.new after I shut down the mud. I need a system whereby I can create a new exec file, run it, and still be able to copyover. Is there some way I could create an exec file with a variable attached that adds to itself so that the exec file can be created multiple times, and the previous file deleted?

(bump)

I don't think you understood Ksilyan's suggestion.

If you compile to create a file, then make an immediate copy of that file (eg. swreality.new.exe) then run the new file, you can always compile again to the original one, since it isn't in use.

Then as part of the copyover code you shut down the one you were running (swreality.new.exe) do the copy again, and then start it up again. This will always work, not just the first time.

Compile swreality.exe
Kill swreality.new.exe
Copy swreality.exe to swreality.new.exe
Run swreality.new.exe

I think I understand now..
..now to turn that into a script.

Anyone have any ideas?

Marowi

Ok, update on problem...

I've got it to compile to a different directory, with the file being 'toth1.exe' - I can't work out how to end 'toth.exe' (the mud) before I compile to 'toth1.exe' and then copy 'toth1.exe' OVER 'toth.exe'.

Please help :-S

Also, I'm not using cygwin to run the mud, only to compile it.. should I be?

Why end it before you compile? What if you have compile errors? When the compile and link are finished just type "reboot mud now" into your client, and let the startup script notice it has stopped, copy the new .exe over and start it up again.

Personally I use Cygwin to run the MUD as well, why not?

Well, cygwin wouldn't run the startup, because I didn't download the tcsh shell (because your guide doesn't say to ;-) ). I downloaded tsch and now run it via startup.

Here's my startup script:


and here's my makefile



So.. what do you suggest? I implement a copyover code that, when I type copyover, compiles - if there are no errors - ends toth, copies toth1 to toth and executes toth?

Where does the descriptor information get stored for those currently connected in that process?

Whilst I personally see it as a defeat, I'm close to securing a Linux server, so this topic is void for me.. although.. I know for a fact that many others would like to know how it is done, and if you get bored or something.. yeah. Shouldn't take /you/ too long to work it out, but I got as close as I could (not that close..)

Thanks for your time anyway.

In Cygwin you shouldn't need to do this:

../../../../../bin/tcsh

It should know where the bin things are (via the current path).

As for copyover, I have commented before that I think it is more effort than it is worth, however if you can get it to work, very good.