1. EUServer 2.02
- Posted by Hawke' <mdeland at GEOCITIES.COM>
Dec 25, 1998
-
Last edited Dec 26, 1998
Barely made under the wire to be able to say
MerryXmas, here's y'alls gift from d' Hovel
:)
This is the first public release of EUServer V2.
(link is below, in sig)
A lot of code has been changed, from versions prior
to 1.70. Most versions (public released ones anyway)
before 1.70 have serious bugs, uncovered by good ole accident.
(and Kevin actually got bit by one of them:
>>However, when I 'quit' (logged off the server) with Qmodem, Euserver
>>closed and gave an error.
>>Telix, OTOH, logged in and off with no prob.
this is one of the bugs in EUServ 1.64, corrected in 1.68 and above
but i never made 1.68 available on my web page cuz I had already
begun coding EUServ 2.00a...
Sorry kevin for this 'crash'/'bug'....
)
EUServer V2.?? now sports a new GUI, *much* faster code in places,
full support is ready and waiting for the soon to be released
EUClient by Blackdog (hurry up man! :> ) and the combination
of the two, in initial testings, has been... *blistering*...
and security has been heavily updated, new utilities have
been added, and this phantom bug with CR/LF/CR+LF may have
actually, finally, been found (crosses fingers)...
*ponder* wot else...
Many bugs in helper libraries have since been found and fixed,
(including things like bug reports found in win32lib.ew and posted
to the listserv... things like that) and SrvSckIP.ew (the actual
guts i suppose of making EUServer talk) has been updated...
The serverlog command now has two more states, LOG_NEVER and LOG_DEBUG,
and the LOG_DEBUG pops a console that echos what is being written
to the log file for real time catching of those pesky bugs
(this feature is what actually caught/found/pinned down the bug
that bit kevin) and will disappear, just as neatly, when you
reset the serverlog status back to something other than LOG_DEBUG...
Be carefull about hitting the 'buttons' on the main server window...
(reboot/shutdown/hideme) as they are sensitive and I did not
have time to code in 'verification of intention' dialogs.
Also, the hideme button, *hides* EUServer... quite well :)
If you do not have a utility like 'hackit', then, using a light
tap on ctrl/alt/del will show it to you, OR, simply shut it down
reboot it from within the server...
To answer the question posed a day or so ago, about using
EUServer with DOS...
EUServer makes use of windows DLL's to provide networking over
TCP-IP. EX.EXE cannot load DLL's, SO!, this makes DOS support
for TCP-IP much more difficult, as well as making things like
NEIL.e very diffucult to mesh with EUServer.
Creating a DOS TCP stack, will and won't help you.
EUServer could be hacked to not create it's "window" for
running it in *pure* dos, but that won't help you. You still
have to run exw.exe to call/load the DLL's, and (i'm not sure)
i do not think that can be done without win9x actually running.
This leaves you with hacking EUServer to not create it's "window"
but still needing to be run under the win gui. (win32 at min).
Now, we get to the point of: well, if we already have the win gui
running, then tcp-ip is already *loaded* (depending...hrm) when
you boot the gui... so what good is the dos stack???
You would be far better off, letting EUServer handle the
logins & data exchanging with your bbs door clientele, as they
could use any telnet program (nearly) of their choice to
get to your bbs or your door game.
THEN, what you simply need is a method for your door
game and EUServer to talk. This is **FAR** and away easier
to code than trying to create a dos tcp stack, in just about
anyone's opine :)
Think of it this way, many many many people on this list have
labored, to the extents of stressing marriages, neglecting
children, and redefining insomnia => to produce the libraries
that are available to you now... so why reinvent an unneeded wheel?
EUServer would be very easily modified to echo the data received
by it from the end user to another 'place', without resorting
to popping it back over another port... other methods are far faster
and easier to send/receive data from EUServer to your bbs/doorgame...
If the doorgame/bbs is not written yet, the simplest and fastest
method, is simply making EUServer INTO the bbs/doorgame.
It's already been tested to work on port23 anyway...
just my thoughts... hope they help...
_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/ _/_/_/ _/ _/ _/_/ _/_/
_/ _/ _/ _/ _/_/_/ _/ _/ _/
_/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/
({<=----------------------------------------=>})
({<=- http://members.xoom.com/Hawkes_Hovel> -=})
({<=----------------------------------------=>})
2. Re: EUServer 2.02
- Posted by Kevin Sieger <simkin at ZEBRA.NET>
Dec 25, 1998
-
Last edited Dec 26, 1998
Hawke' wrote:
> <snip>
>
> To answer the question posed a day or so ago, about using
> EUServer with DOS...
>
> EUServer makes use of windows DLL's to provide networking over
> TCP-IP. EX.EXE cannot load DLL's, SO!, this makes DOS support
> for TCP-IP much more difficult, as well as making things like
> NEIL.e very diffucult to mesh with EUServer.
Well, this was someone else suggestion, this is not a route I'd take
either....
> Creating a DOS TCP stack, will and won't help you.
> EUServer could be hacked to not create it's "window" for
> running it in *pure* dos, but that won't help you. You still
> have to run exw.exe to call/load the DLL's, and (i'm not sure)
> i do not think that can be done without win9x actually running.
>
> This leaves you with hacking EUServer to not create it's "window"
> but still needing to be run under the win gui. (win32 at min).
>
> Now, we get to the point of: well, if we already have the win gui
> running, then tcp-ip is already *loaded* (depending...hrm) when
> you boot the gui... so what good is the dos stack???
>
> You would be far better off, letting EUServer handle the
> logins & data exchanging with your bbs door clientele, as they
> could use any telnet program (nearly) of their choice to
> get to your bbs or your door game.
>
> THEN, what you simply need is a method for your door
> game and EUServer to talk. This is **FAR** and away easier
> to code than trying to create a dos tcp stack, in just about
> anyone's opine :)
>
> Think of it this way, many many many people on this list have
> labored, to the extents of stressing marriages, neglecting
> children, and redefining insomnia => to produce the libraries
> that are available to you now... so why reinvent an unneeded wheel?
>
> EUServer would be very easily modified to echo the data received
> by it from the end user to another 'place', without resorting
> to popping it back over another port... other methods are far faster
> and easier to send/receive data from EUServer to your bbs/doorgame...
Hmm, fill us in <smirk>! Seriously, my idea was to use a combo already in
existence (turbocomm to let dos talk with winbloze, com/ip to grab the info
there). However, it would be great to bypass ports altogether (the virtual
com ports, limited to 8 or so by the fore mentioned software).
There is a monster called netmodem that allows dos based bbs' to become
telnettable, but it costs (I am cheap) and from what I've read, is rather
buggy at best. If we could come up with a way to make dos bbs' telnettable
WITHOUT netmodem, and with many, many nodes...well, Hawke', you would get
EuServer and Euphoria some extra attention. Granted this would not be on a
Bill Gates level but still, I'm sure RDS would like the promo.
> If the doorgame/bbs is not written yet, the simplest and fastest
> method, is simply making EUServer INTO the bbs/doorgame.
> It's already been tested to work on port23 anyway...
>
Yah, been looking at doing this first but still want to make my game into
something ppl with bbs' could use. Why, you ask? Love majormud for
Worldgroup/MajorBBS, but nothing close exists for the rest of the bbs
world. I personally believe it can be done. And my original would then be
available strictly under EUServer, and I'd probably lose the bbs (have no
desire to run one myself, just to make a great game). Having EUServer
communicate with the bbs first would just give me the opportunity to
demo/debug the software personally.
Thanks, and have a Vulcan nice day.
Kevin
3. Re: EUServer 2.02
Kevin Sieger wrote:
>> EUServer would be very easily modified to echo the data received
>> by it from the end user to another 'place', without resorting
>> to popping it back over another port... other methods are far faster
>> and easier to send/receive data from EUServer to your
>> bbs/doorgame...
> Hmm, fill us in <smirk>!
off the top of my head, i can think of a couple 'methods' that
would be faster, and very likely easier than trying
to start coding twin tcpip stacks that run simultaneously
and that don't conflict... (having a stack for the win gui
that euserver is working with and another stack for dos, which
the doorgame/bbs is running through, seems like a very very
big place to walk into and snarf a headache trying to get
them not to conflict)
first way would be a 'stream'... not actually sending the
data to a file on disk, but similar in that we would need
a command that mimic'd open(), like maybe open_stream()
which would return a handle, just like open() and would
accept a parameter like the second parameter in open(),
ie:"w" or "r" ...etc since we would not need it to accept
a filename as open() does for its first parameter.
second way would be using a shared memory area, and passing
of a pointer upon bootup to the two programs after allocation
of the memory area and creating of the pointer.
the 'normal' method (read that easy) doesn't actually work,
you cannot just allocate() in one program and pass the pointer
to the other program, i've tried and failed. this doesn't
mean it cannot be done, as someone better at this kinda
wierdness can likely get that to work, OR, we may
have another option for this method. Blackdog and I were
talking about it as we are attempting to code a game
as well as the client and further mods to euserver, all
at once, and the game we wish to code is the driving force
behind development of euserver and it's client companion.
(well, the other driving force is the shared windows/telnet/internet
coding environment allowing multiple Euphorians to code on
a piece of software together, in real time... handy :))
the game we wanna create will likely be with neil but we
want it to talk to euserver. ralf may be looking at this
same issue, and we will likely talk with him about it as well.
the discussion blackdog and I had centered on what may be
a windoze API call along the lines of GlobalMemoryAllocate().
from what we understand after only a small amount of research,
it may be possible for us to alloc a block of mem that any
other windows program can access, and that may also be accessible
by dos programs under dos boxes... if so, problem solved.
the third method might be some sort of assembly routine written,
(hi pete! :) r ya busy? :)) or some sort of technique whereby
we could stuff a buffer, like the KB buffer mebbe or some other
low dos buffer that isnt used often, if ever, and passing
the data thru this buffer, a method quite similar to both
of the above methods. (one is a stream buffer, the second is
a memory buffer, and this third one might be considered as
some sort of a bios/hardware/cheating buffer...)
sooooOOOOO.... there are a few methods, and hopefully,
they fill you/others in :>
> > If the doorgame/bbs is not written yet, the simplest and fastest
> > method, is simply making EUServer INTO the bbs/doorgame.
> > It's already been tested to work on port23 anyway...
> Yah, been looking at doing this first but still want to make my game
> into something ppl with bbs' could use. Why, you ask? Love majormud
> for Worldgroup/MajorBBS, but nothing close exists for the rest of the
> bbs world. I personally believe it can be done. And my original
> would then be available strictly under EUServer, and I'd probably lose
> the bbs (have no desire to run one myself, just to make a great
> game). Having EUServer communicate with the bbs first would just give
> me the opportunity to demo/debug the software personally.
well, the mods and methods described above, if you didn't make the
game yourself, would almost assuredly require access to the game
code (ergo:the majormud code) so that IT could be hacked as well
and recompiled to take advantage of what ever methodology we
decide upon to allow euserver to talk to dos programs WITHOUT
them requireing the use of ports... the game program would need
to be informed of the data appearing at euservers' welcome mat...
ttfn!
_/ _/ _/_/_/ _/ _/ _/ _/ _/_/_/ _/
_/ _/ _/ _/ _/ _/ _/ _/ _/
_/_/_/ _/_/_/ _/ _/ _/_/ _/_/
_/ _/ _/ _/ _/_/_/ _/ _/ _/
_/ _/ _/ _/ _/_/_/ _/ _/ _/_/_/
({<=----------------------------------------=>})
({<=- http://members.xoom.com/Hawkes_Hovel> -=})
({<=----------------------------------------=>})
4. Re: EUServer 2.02
Hawke' wrote:
> <SNIP!>
No plans whatsoever to hack the Majormud code. Could not get me mitts on it
anyway! The game I've been working on (at the pace of a very old snail) is
100% mine. I was wanting to give all those guys/gals with dos-based bbs' a
new door game, one that was like the above mud in playability, options,
etc. Much like an inet mud, but instead a door game. If you've ever played
the typical fantasy or rpg door on a bbs you would know why I desire such a
beast. Hehe, you enter the game and you can do stuff like buy weapons,
spells or whatever, but it is all by picking one letter! Example:
Buy [W]eapon
Buy [A]rmor
Enter [F]orest
Visit [I]nn
You get me here? Utter crap, and there are hundreds of this sort! It all
started with L.O.R.D....
While playing directly from EUServer will give me ultimately the option of
having more players on, having the bbs-door version gives the dos-bbs newer
life as well. As I stated I will probably keep the one on a EUServer, or
give the game to someone on the list who has a better connection than 28.8
to put it up.
Later,
Kevin
