Use Perl to port Windows DLLs to Palm OS 13
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."
And why? (Score:4, Insightful)
Somebody slap me if I'm wrong, though.
Re:And why? (Score:2, Informative)
looks [ibm.com] kinda like their porting Math libraries
however, you would think that PalmOS aleady had math libraries
Somebody slap me if I'm wrong, though.
I just slapped you, and I still don't understand why
Math libraries (Score:2)
Re:And why? (Score:2, Informative)
- Jalil Vaidya
I have one question. (Score:3, Interesting)
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.
Writing portable code (Score:3, Informative)
The other way (Score:4, Funny)
(... or whatever it would take to port perl to PalmOS)
MS Deliberate "Dev-Skills lock-in" (Score:1, Interesting)
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.
Heh... (Score:1)
I mean, come on...