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

And why?

[andfarm]

When was the last time anybody needed to port a Windows DLL to PalmOS? I can't think of many libraries that would be used on both Windows and PalmOS --- the two have completely different interfaces and OS architectures, AFAIK.

Somebody slap me if I'm wrong, though.

Re:And why?

[agnosonga]

I can't think of many libraries that would be used on both Windows and PalmOS

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

[andfarm]

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?

Re:And why?

[jalilv]

There are times when you have an application running on Windows (and not necessarily PocketPC) that you need to port to run on Palm OS. Anyone who has done this even for a smaller code base knows the pain of doing this. An application on Windows may have a main executable and a bunch of DLLs. The article shows how to convert the DLLs to Palm Shared libraries and can be very useful for small and large projects equally. Lot of companies are allowing their employees to use the handhelds of their choice. In such situations you need to port your applications to PocketPC, Palm, Blackberry, add your favourite PDA here.

- Jalil Vaidya

I have one question.

[BoomerSooner]

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.

Writing portable code

[cpeterso]

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.

The other way

[Penguin]

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)

MS Deliberate "Dev-Skills lock-in"

[Anonymous Coward]

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.

Heh...

[SpiffyMarc]

Am I the only person that just cracks up every time they type WIN32_LEAN_AND_MEAN?

I mean, come on...