Wed 2002-11-06 07:05, andrew clarke (3:633/267) wrote to Tobias Ernst:

 > I did eventually get Msged to compile under BCB++.  The main problem is 
 > the SMAPI code - particularly all that _fast/pascal/near/far calling 
 > convention stuff.  I ended up going crazy and removing all the 
 > references entirely, and obviously the code looks a lot cleaner now.  I 
 > don't really know why there's any of the calling convention stuff in 
 > there when everybody's using statically-linked libraries, and nobody is 
 > running old 16-bit DOS binaries any more.  It would make life a hell of 
 > a lot easier to maintain the ports it if all of that junk was ripped 
 > out.  

OK, I take some of that back - I looked at some of the more recent
bleeding-edge binaries of HPT & FidoConfig, and you're using DLLs for
SMAPI & FidoConfig (although not for Msged yet).  I still think a lot
of the calling-convention stuff could be simplified though, eg.  doing:

#define EXPENTRY WINAPI

for the Win32 functions that are being exported.  That should allow the
same DLLs to be used with different Windows compilers (where currently you
seem to have compiler-specific DLLs, eg. presumably smapimvc.dll is for
MSVC only).

Also, I noticed with HPT 1.3.0 that the SMAPI & FidoConfig DLLs need to
be in the same directory as HPT.EXE, otherwise it won't run.  Or I could
put them in \WINNT\SYSTEM32\, but I don't like that idea much.  So I think
ideally HPT should be using getenv("FIDOCONFIG") then stripping
the filename and replacing it with "BIN\SMAPI.DLL" or whatever,
then using LoadLibrary().  This might end up being more work than it sounds
though, but it's just an idea.  It may/may not be relevant to other
systems, ie. probably OS/2 but maybe not Linux.

Also, the Win32 version of Msged 6.1.1 will freeze or segfault on startup
if you have more than 127 columns or 127 lines available in the
"Screen Buffer Size" of a Command Prompt window in Windows
NT/2K/XP.  I think the default for the Command Prompt window is 80 columns
X 300 lines when you first install Windows.  Normally I just set the Msged
shortcut to use a 80x25 buffer size (which is really the window size)
though.  I had a go at fixing this bug and couldn't actually track it down.
 Maybe Msged should resize the buffer to 127x127 if it's greater than that.
 I don't know what Win32 API call you need to use for that though.

If there's nobody working on the Win32 port, ie. you just shrug your
shoulders and say "I only do Linux/FreeBSD/OSX/etc" and I don't
hear from anybody about the Win32 port then I'll take a look at these
things myself.  ;-)

-- mail{at}ozzmosis.com

--- Msged/NT 6.1.1