Note: This website is archived. For up-to-date information about D projects and development, please visit wiki.dlang.org.

Changes between Version 13 and Version 14 of PortingJournal

Show
Ignore:
Author:
JJR (IP: 207.200.150.195)
Timestamp:
11/03/08 14:27:51 (9 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PortingJournal

    v13 v14  
    55'''Comment by John Reimer - JJR''' 
    66 
    7 Time for my first update.  Unfortunately, I've been too busy working on dwt browser to provide much info here, but now I have something solid to cover.  It's been over three months since I started working on porting the linux Browser package. About one month of that consituted a hiatus as things got busy in real life.  Now, I am happy (and relieved) to say that a working alpha version of the Browser package is now available for Linux DWT in the repository. Within the next few days, I'll be including instructions on how to use it (installation and dependencies). Meanwhile, I'll cover some of the details of my porting adventure here. 
     7Time for my first update.  It's been over three months since I started working on porting the linux Browser package. About one month of that consituted a hiatus as things got busy in real life.  Now, I am happy (and relieved) to say that a working alpha version of the Browser package is now available for Linux DWT in the repository. Within the next few days, I'll be including instructions on how to use it (installation and dependencies). Meanwhile, I'll cover some of the details of my porting adventure here. 
    88 
    99Initially, I wasn't quite sure how to approach the whole thing since I had no practical experience with XPCOM programming, beyond some passing familiarity with COM programming from years before.  
    4949That's where the first problem comes in, though.  COM is windows only. The XPCOM "trick" is to use the D COM interface type (which is internally detected by the compiler as soon as you declare or inherit from an interface called IUnknown) by aliasing nsISupports to IUnknown. Voila, you can now connect to XPCOM interfaces. But my port is for Linux, not windows... so what to do? 
    5050 
    51 COM methods are ''_stdcall'', which means they are declared extern(Windows) internally, literally forcing ''_stdcall'' decoration on the contracts whether you see it or not.  The only reason I discovered this is because I tried to fudge the rules a bit and force the same alias on Linux, just hoping that I could recourse to using a COM aliased interface to connect with XPCOM objects.  It didn't compile.  A dreaded covariance error spewed forth from the compiler.  When I first saw it, I thought the compiler had a bug because the error complained about function return types not being equivalent: "voidWindows" not being covariant with "void" returns types. What in the world is "voidWindows"?  Frank caught this one and pointed out that it was due to my using the "alias IUnknown nsISupports" (which I had adopted from dxpcom).  I realized that this immediately caused the compiler (even on linux!) to assign ''_stdcall'' calling convention to the interface. 
     51COM methods are ''_stdcall'', which means they are declared extern(Windows) internally, literally forcing ''_stdcall'' decoration on the contracts whether you see it or not.  The only reason I discovered this is because I tried to fudge the rules a bit and force the same alias on Linux, just hoping that I could recourse to using a COM aliased interface to connect with XPCOM objects.  It didn't compile.  A dreaded covariance error spewed forth from the compiler.  When I first saw it, I thought the compiler had a bug because the error complained about function return types not being equivalent: "voidWindows" not being covariant with "void" returns types. What in the world is "voidWindows"?  Frank caught this one and pointed out that it was due to my using the "alias IUnknown nsISupports" (which I had adopted from dxpcom).  After some investigation, I realized that this immediately caused the compiler (even on linux!) to assign ''_stdcall'' calling convention to the interface. 
    5252 
    5353So what could be done for the linux port of Browser?  Without access to the COM Interface, I'd have to resort to arcane workarounds that rivaled the Java version. I decided to push a little harder with the COM idea.  What if it were possible to override the calling convention.  What I needed on linux was extern(C) for all interface methods instead of extern(Windows).  What if I could mix and match?  I tried it and it worked.  I forced extern(C) calling conventions on each method ''inside'' the interface, and this effectively overrode the internal compiler assignment of extern(Windows).  Thus I obtained a COM interface with C calling convention, an appropriate interface for linux XPCOM.