Use Perl to port Windows DLLs to Palm OS
developerWorks writes "Porting existing Windows DLLs to Palm OS has historically been a tedious process. This article introduces you to an interesting technique that makes this process easier by using Perl. It demonstrates a Perl script that analyzes existing C source code and automatically generates many of the source files required for porting. You should be able to use the code outlined in the article to help with your own porting projects."
Somebody slap me if I'm wrong, though.
TANSTAAFI: There Ain't No Such Thing As A Free iPod.
Why?
If you've chosen PocketPC over Palm why would you switch? Kind of like going from Windows to DOS.
Plus the UI components will not work at all. So simply copy/pasting your code to CodeWarrior from the Embedded Tools would work (assuming you tried to keep it close to compatible, again why?).
The hardest thing for me as a developer is the logic, not the code. Hell with good design documents and a well thought out plan the code is almost secondary.
I don't think writing Perl scripts to munge your C sources is a very safe or easy to maintain design. Everyone knows that different systems have different APIs and "quirks". I think the Linux kernel takes an interesting approach to portable code. C macros (#defines and #ifdefs) are only allowed in header files, so the C source files for the core code are exactly the same for all platforms. All the platform-specific quirks and macro workarounds are isolated to header files specific to just that platform's arch directories.
cpeterso
I think what we have here is a Singularity of Geekiness, sort of like when Magneto (Ian McKellan, Gandalf) was talking to Count Dooku (Chris Lee, Saruman) in Lord of the Rings.
Don't get too close to the event horizon of lameness, the nerddom might suck you in for all eternity.
(moderators note, it's called humor)
Now we just need to be able to use Windows DLLs to port perl to PalmOS!
(... or whatever it would take to port perl to PalmOS)
- Peter Brodersen; professional nerd
The thing that surprises me is _just how awkward_ writing Windows DLLs (or anything on Windows :-) ) is compared to DLLs on other platforms - the departures from "bog standard" C or C++ stuff are astounding. If you learn to program "Microsoftian" C, even the core stuff is different. It pollutes the brain.
It's HARDER to move to Unix after learning Windows stuff than starting at Unix from scratch - you have to "unlearn" so much arbitrary crap.
And it's NOT just "different platform, different rules".
AmigaOS was also completely "alien" at the DLL-design level, more different from Unix than Windows is from Unix, using late-binding (loaded at run-time by an OpenLibrary() call) "libraries" with binding via jumptables rather than symbolic linking - more like a primitive version of component-based-programming than anything else.
AND YET: the process for writing code felt very similar to Unix, and did NOT involve bizarre bastardisations of C beyond the bare minimum single line "pragma" directives for declaring external late-bound jumptables.
I'm forced to conclude that MS DELIBERATELY MAKES THEIR STUFF DIFFERENT, gratituously inventing changes in terminology, extra language keywords, and arbitrary restrictions that can none the less be coded around (but the code-around breaks on platforms without the restriction) for "Developer programming skills lock-in", a different kind of "vendor lock-in"
Coding for windows isn't coding in C or C++, it's coding to some bizarre Microsoftian wierdness.
In fact, I'm sure the Palm already has math libraries of some sort --- I've currently got MathLib on mine, though I don't know what IBM is trying to do. Perhaps something MathLib doesn't?
TANSTAAFI: There Ain't No Such Thing As A Free iPod.
Am I the only person that just cracks up every time they type WIN32_LEAN_AND_MEAN?
I mean, come on...