Hi everyone, new here. I have been fooling around with the idea of porting WIne to the D programming language. What do you think would be the chances of sucess? D has the speed of C, but is a garbage collected language and OOP.
D: http://www.digitalmars.com/d
Chris
On Wed, Jun 23, 2010 at 1:38 PM, Christopher Selph cds.wine@gmail.com wrote:
of sucess? D has the speed of C, but is a garbage collected language and OOP.
And that would help how, exactly?
--Stephen
Sent from my Emacs
On Wed, Jun 23, 2010 at 11:59 AM, Stephen Eilert spedrosa@gmail.com wrote:
On Wed, Jun 23, 2010 at 1:38 PM, Christopher Selph cds.wine@gmail.com wrote:
of sucess? D has the speed of C, but is a garbage collected language and OOP.
And that would help how, exactly?
--Stephen
Sent from my Emacs
Frankly, this sounds crazy and pointless. Your time would be better spent improving the current codebase, in C.
On Wed, 23 Jun 2010, Christopher Selph wrote:
Hi everyone, new here. I have been fooling around with the idea of porting WIne to the D programming language. What do you think would be the chances of sucess? D has the speed of C, but is a garbage collected language and OOP.
Garbage collecting:
Wine has strong requirements as far as the memory layout is concerned. Some applications don't expect to receive pointers to data above 3GB for instance. Windows also provides heap management routines and Windows applications create heaps, allocate memory inside them and don't expect things to move around. I suspect none of this would play well with garbage collecting. It would probably still be possible to use the garbage collector for a small fraction of Wine's allocations, but it seems to me that there would not be much point.
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: * For some msvcrt parts. But the name of the corresponding C++ functions must be mangled in the Visual C++ way which probably does not match the D way. So we would still need to do the impedance adaptation in the spec file. * For COM objects. However these must have a very specific binary layout for compatibility with Windows applications. Again I doubt D objects would naturally generate the right datastructures. So you'd need to add an impedance adaptation just like for C.
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.
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
-
Christopher Selph -
Conan Kudo (ニール・ゴンパ) -
Francois Gouget -
Gert van den Berg -
Stephen Eilert