Vanilla Netrek Server Development Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[VANILLA-L:1185] Re: [VANILLA-L:1184] Re: [VANILLA-L:1183] Windows Server



Cameron wrote
>Porting to Windows NT has been tried before, three or four times, with
>moderate success.  However the people who tried it got tired of it and
>dropped it without sending in the changes.

Sheldon wrote
>Hmm, how are you getting around the fork() and shmem routines?
>
>
> I'd be curious to have a look at this server code.
>
>Steve


Well the port does work, sortof.  It won't run "exactly" like the general
unix versions and here is a short list of where I am now, what it does, how
it does it, and what I am having problems with.

Where am I now:
As the code is set up now, each program is compiled seperately just like in
the general distribution and all the user needs to do is run newstartd to
start it up.

What the program does now.
1) User can connect to it and it appears that all the commands are
operational.
2) User can call in a practice robot and it does seem to work correctly.
3) Tried it with only 3-4 clients (simultaneously) until I can get it up on
an alpha server.

What does it do:
The operation of spawning the other programs are exactly the same, except
the way it does it is different.

How does it do it:
First of all forks are out, so I had to use CreateProcess instead.
newstartd is ran from a console window and all of the other programs use
the same console window that newstartd starts in.  The reason for this is
that console programs don't normally communicate to each other and kill
isn't supported in windows.  newstartd starts the ntserv process not only
in the same console window but also as a new process group, this allows
daemonii to send a CTRL_C signal to each ntserv (each ntserv is in a
seperate process group) by using GenerateConsoleCtrlEvent() and the update
occurs.  daemonii uses a windows timer to update itself, I was going to do
it with multimedia timers but I wanted to keep the load on the system down.
 shmem is replaced by calls to creating and using file-mapped memory.  The
CTRL_BREAK event is not trapped by me and this is what daemonnii uses to
cause other programs to terminate.

What I am having problems with:
1) Still have to fix newstartd to pass the correct address, Windows does
not support inet_netof.
2) For some reason encryptReservedPacket bombs but I am sure this is
because I am running it from home when I am not connected to the Internet.
3) Does anyone know of a public crypt routine so that the Windows version
can encrypt a users password?
4) Because all of the routines share the same console window, the window
changes name according to the last program called.  Not a big deal, unless
you want to find the window to stop the program.
5) Because of all the tricks I had to do to make the communication work,
the only way to correctly run the ntserv program is through newstartd,
eventhough ntserv can be ran seperately, the communication between it and
daemonii will not work.


Other changes I made that I forgot to post about:
1) using windows.h forces ANSI args to be used, so I had to change all the
uses of UNIX style va_args to ANSI ones.
2) forcing the sock handle to 0 before forking ntserv can't be duplicated
in NT, the way I had to force a way around it was to set up to new
parameters for ntserv.  The socket handle has to be passed to ntserv along
with the process id of newstartd itself, these are used in the windows
DuplicateHandle function call that I placed in ntserv to get a handle to
the socket.
3) rint, damnit I don't know how the heck it was supposed to work but it
doesn't in NT.  Might look at it later but right now I just replaced it
with a floor call if the difference between the number and floor is less
than .5 and a ceil call if it is not.

Darryl

+
++ Vanilla-l Mailing List ++
To unsubscribe: send "unsubscribe vanilla-l" to majordomo@real-time.com
For more information: http://archives.real-time.com