After we finally get 1.5.6 out the door, I'll begin moving read/write/lseek calls as inline method calls to FileMgr. They'll just call ::read/::write/::lseek in the default impl. This should isolate all fileio into FileMgr, as far as I can remember.
untgz is optional code. you shouldn't need it unless you're planning to get the remote installation features working. There should be approprate ifdef's already in the code so you can define them in your evc++ project files so it's left out (I think it's CURLAVAILABLE so having it undefined should leave it out by default; which means you might be ok just removing it from the project). I don't think there are any other calls in the engine that you would refer to as System (time,etc).
The thread issue has been mostly ignored in the engine. We haven't defined any type of critical section mechanism, but might in the future. I'll be sure to keep it abstract so we can redefine it per os, since it will be very different between linux/windows, as it stands. There are things that lend themselves to letting a client of the engine use it in multiple threads-- e.g. you can interrupt a search by changing a method variable on a module; mod->terminateSearch = true; but I'm sure there are plenty of things that wouldn't work well if multiple threads hit at the same time.
I'm really excited about your work! Please feel free to ask questions and comment to your hearts desire :)
-Troy.
Herb Ledebohm wrote:
That's what I thought and I agree. Since the #ifdef(s) would primarily be for system services (file/directory, time, etc.), these things should be broken out into OS specific abstraction layers (like the FileMgr class you mention). I'm actually pleasantly surprised at how much of the code compiles just fine.
A good example of where some work is needed is in untgz.c which includes files like time.h, fcntl.h, io.h and errno.h to name a few. None of these exist for WCE. Although the functionality required can be provided, there will have to be changes made to get it working. Unless you guys are really pressed to get this done asap, I'd like to take the time to get familiar with all the code and make the changes myself. I just wanted to get a feel for the preference on this. I know at my place of employment, there are very strong opinions on these issues ;)
Some of the items that might be best in an osal: File/Directory (yes, including read/write/seek) System (time, etc) Memory Mgmt (maybe? -- haven't gotten this far yet) Process/Thread Mgmt (again, maybe? -- haven't gotten this far yet)
Forgive me please, if I'm mentioning things already considered/done. I'm still finding my way around.
Thanks!
----- Original Message ----- From: "Troy A. Griffitts" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 17, 2003 3:09 AM
Subject: Re: [sword-devel] PocketPC Development -- _WIN32_WCE #ifdef(s) and
other questions
Herb, If the wince compiler is still so non-standard as to not support our ANSI/ISO compliant C++ code, then microsoft, like always, still sucks :)
I'd prefer you NOT clutter the code will a million ifdef's. Can you give me an example? We already added a bunch of stuff to get it to compile once on the wince compiler. I took much of it out because there are better ways to handle some of the things that were ifdef'd. Please give me an example and maybe I can add something for you that will help.
Most of the file io routines should be isolated in the FileMgr class, so writing your own FileMgr replacement should do the trick. We can consider moving the read/write/lseek calls to FileMgr methods if this will help you.
I'm sorry if I don't sound too friendly toward microsoft. We've already cluttered our code with a number of workarounds for their non-conformant compiler and it just makes me angry. Nothing personal.
-Troy.
Herb Ledebohm wrote:
What is the stance on me adding a number of these to the source? #ifdef _WIN32_WCE ...or... #ifndef _WIN32_WCE
If you guys prefer that we don't litter up the code with a bunch of definition checks like these then I'll need to break out some of the
code
(which I'll have to do for directory/file services, system time, etc. anyway) and handle it in the project file.
Comments? Preferences?
Also, I'm leaning towards supporting only PocketPC2002+ since that is
the
toolset I have.
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
