TIP: Click on subject to list as thread! ANSI
echo: muffin
to: William McBrine
from: Bob Jones
date: 2003-08-17 15:24:12
subject: Re: QWK problem(s)

BJ> Would you care to join the development team 
 BJ> working on getting Maximus
 BJ> ported?

 WM> I'm not sure how much time I can devote to it right now. But, yeah, sure.

Thanks.  I've added you to the development maximus team on the sourceforge site.  

 BJ> If so, what platforms beside a Linux based, Intel 
 BJ> based (little endian,
 BJ> 32 bit) CPU platform can you help us out with?  And what compilers /
 BJ> make systems would you want to be using?

 WM> Pretty much everything. ;-) Check out 
 WM> http://multimail.sf.net/ and see what 
 WM> I've used it on. Originally that was Linux/gcc/i386-specific.

Ah....  Thanks for the reference.  You've done to multimail what I'd like
to see done with the current maximus / squish / sqafix code.  

Since this started with the short cut Wes was using for packing structures
when using the GNU GCC compiler, and questions concerning that and
endianness,  what are you using in your code for dealing with 

(a) big vs little endian for data that needs to be stored or transfered
that currently is being done in a binary format, and

(b) packing of data structures for binary reading / writing in a portable way?

As I've mentioned in the past, I've used NexStep, and it was simple to
convert our code to run on the different CPU types supported with NextStep
3.2 and 3.3, even with real time binary data transfers between different
systems.  [We had Motorola 68000 series, Intel 80486 and later, and HP RISC
CPUs all running in parallel, and cleanly transfering binary data, etc. 
NextStep also supported Sun boxes at that point in time.]  Having a good
library that just works is nice.  Any way....                              
                 
                                                                           
Let's see....  From memory, Max uses binary data files for

(a) User database
(b) Compiled configuration file(s)
(c) Squish message basaes
(d) QWK data packets
(e) File database
(f) Mex compiled code
(g) Mecca compiled files.

and probably some other areas.  Each of these areas have yet to really be
looked at for portablility between existing systems (32 (and 16) bit,
little endian intel based) and other platforms.  I'll admit that some areas
don't need to port between systems (such as compiled configuration files,
compiled mex code and compiled mecca files), since those files are retained
as source and the tools to compile them for use with the BBS are part of
the package.  But QWK, Squish and user databases are another matter.
                                    
Wes started clean up in a way that allows the code to compile on different
Unix based systems, but we haven't gotten down to using the data between
different system types.  I was able to take some of my Squish databases
from my OS/2 box and use them directly under Linux, although I may have
re-built the index files.  Eventually, I'd like to transfer the entire
system (including all binary files) from OS/2 to linux (intel based).... 
The packing game Wes started doing will support my minimal needs, but isn't
a complete solution....  On the other hand, from a packing only
perspective, I think what Wes is doing is ok for the all the platforms at
this time....

So, before making further changes in how we handle these things, I'd like
to get some positive comments from you about how you've handled things in
other code.

Thanks....

Bob Jones, 1:343/41


--- Maximus/UNIX 3.03b
* Origin: Top Hat BBS -- Linux Alpha Setup (1:343/40)
SEEN-BY: 633/267 270
@PATH: 343/40 41 10/345 106/1 2000 633/267

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.