1. EUServer 2.02
- Posted by Hawke' <mdeland at GEOCITIES.COM> Dec 25, 1998
- 390 views
- 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
- 391 views
- 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
- Posted by Hawke' <mdeland at GEOCITIES.COM> Dec 26, 1998
- 374 views
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
- Posted by Kevin Sieger <simkin at ZEBRA.NET> Dec 26, 1998
- 387 views
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