Hi folks, This is mostly for those who are curious about tech operations and programmers; sorry for some difficult words: In order to understand the below text, I assume you know what .exe and .dll is and be able to access ROM image files based on a previous post/instruction. Here are some notes on "hypothesized" internals of KeySoft 9.2 based on ROM image files: * File download improvements: In KeySoft 9.1, Humanware "fixed" 60 MB download limit by using httpdownload.exe. While it allowed download of larger files, it didn't give the user the status of file download simply because the engine was an executable, not a library (dll) and cannot output what it is doing (for now); if it was a library (DLL), then keySoft would have grabbed status of download from this library and printed download status as it progresses - and this is what KeySoft 9.2 is doing now. When you examine 9.2's ROM files, you won't see httpdownload.exe, as the routine from there has been integrated to KeyWeb's portion of keysoft.exe, explaining more memory usage after 9.2 upgrade and being able to see file download status on files - especially larger files greater than 60 MB, as tested using JAWS 13 download (112 MB in size). * Zipping/unzipping: The properties of .exe from file download can be applied to zipping/unzipping routine; This is evidenced by the fact that file compression/decompression is handled by its own executable named apexzip.exe. Because .exe does not give you output on what it is doing, naturally no info is given on number of files zipped/unzipped. >From what I understand it, the "ultimate" solution is integrating zip/unzip functionality as part of file manager, but it increases size of keysoft.exe; another solution is to put apexzip as a library, thereby giving it some foundation from where it can interact with the user, but it also has a problem: once zip functionality has been executed, the library will stay with keysoft.exe until the Apex has warm booted. The third solution could be using the same .exe but adding output routines, which could open the doors for the future. * Sendero GPS's executable: The reason why GPS was able to give you messages was because it was a DLL, not an independent executable like KeySoft; well, it does its own thing, the ability of this guy to be updated independent of KeySoft and the file format gives it away as a dynamic program that gets loaded to KeySoft's running space. Putting it all together (for future roads): We already have provisions for SDK's on Apex; the question is: would there be a way to compile a C++ source code that'll be linked with KeySoft; in other words, a way of creating a DLL that gets loaded when called by KeySoft and exited when done (like what Sendero's gpstalk.dll is doing now) would give programmers one step closer to coming up with third-party programs that'll run under Apex. All that remains would be a way to use KeySoft specific ways of talking to the user and getting their input - and we could already have an Apex version of "Hello World". Next step: how to "kill" iesample.exe under CE's OS calls...
Again sorry for possible confusion and tech talk - it just occured to my mind and had to write my feelings about it. Thanks, and hope this helps. Cheers, Joseph Lee University of California, Riverside ___ Replies to this message will go directly to the sender. If your reply would be useful to the list, please send a copy to the list as well. To leave the BrailleNote list, send a blank message to [email protected] To view the list archives or change your preferences, visit http://list.humanware.com/mailman/listinfo/braillenote
