Slashdot Mirror

← Back to Stories (view on slashdot.org)

Use Perl to port Windows DLLs to Palm OS

Posted by Hemos on from the move-it-all-around dept.

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."

2 of 13 comments (clear)

  1. I have one question. by BoomerSooner · · Score: 3, Interesting

    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.

  2. MS Deliberate "Dev-Skills lock-in" by Anonymous Coward · · Score: 1, Interesting

    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.