| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.