Porting WIne to D

[Gert van den Berg]

On Thu, Jun 24, 2010 at 10:55, Francois Gouget wrote:
> OOP:
>
> A lot of the Windows API is exported through DLL entry points and these
> are not object oriented. Where the Windows API is object oriented is:

OOP in C is not impossible wither... It is harder than it could be,
but it is possible....

> Wine also has very strong requirements with regards to threading, CPU
> register usage, exception handling, all of which require very low-level
> control which negates the advantages high level languages might have in
> these areas.

The good:
* D is specifically intended to support low-level applications.
* Built in UTF-8 / UTF-16 / UTF-32 support
* Types defines size - an int is always 32-bit
* COM support
* C-compatibility
* Standardized inline assembly
* Build-in support for unit-tests, etc. (Will require all the tests to
be rewritten in a different way though..)

D still have some issues, such as two incompatible, competing
"standard libraries"... Version 2 might be worth considering for some
new projects...

Like the D website says:
Who D is Not For
    * Realistically, nobody is going to convert million line C or C++
programs into D. Since D does not compile unmodified C/C++ source
code, *D is not for legacy apps*. (However, D supports legacy C API's
very well. D can connect directly to any code that exposes a C
interface.)

D also specifically drops 16-bit support, which might cause problems
for the Win16 / DOS parts of Wine...

I'm not sure how widely gcd/dmd is supported. Will it run on some of
Wine(lib)'s rarer platforms? (like MIPS Linux, Itanium Linux,
x86/x86_64 Solaris, SPARC Linux, *BSD on unusual platforms, OS X
(PowerPC, x86 and x86_64))

Linking to C code from D is obviously supported. I'm not sure how well
it is supported in the other direction (crucial for winelib...)

It is not clear if non-Unicode strings are supported... (No
non-Unicode char type exist...)

Gert