Re: Porting WIne to D

2010-06-24 Thread Marcus Meissner
On Thu, Jun 24, 2010 at 11:39:49AM -0700, James Mckenzie wrote:
> Gert van den Berg  wrote:
> >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.)
> 
> That should rule out moving Wine to D for a long time.  9 Million + lines of 
> code would make this a lengthy, but not impossible, task.
> 
> >
> >D also specifically drops 16-bit support, which might cause problems
> >for the Win16 / DOS parts of Wine...
> 
> Another show-stopper for those folks using Wine to run Windows 2.x/3.x 
> programs.

Well, our 16bit code is hidden behind assembler wrappers. :)

Ciao, Marcus




Re: Porting WIne to D

2010-06-24 Thread James Mckenzie
Gert van den Berg  wrote:
>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.)

That should rule out moving Wine to D for a long time.  9 Million + lines of 
code would make this a lengthy, but not impossible, task.

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

Another show-stopper for those folks using Wine to run Windows 2.x/3.x programs.

James McKenzie





Re: Porting WIne to D

2010-06-24 Thread 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




Re: Porting WIne to D

2010-06-24 Thread Francois Gouget
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.


-- 
Francois Gouget   http://fgouget.free.fr/
A polar bear is a cartesian bear after a coordinate transform.




Re: Porting WIne to D

2010-06-23 Thread Ben Klein
Please bottom-post on wine-devel.

On 24 June 2010 09:26, Christopher Selph  wrote:
> I agreee  that just converting syntax would not be enough, but it would make
> OO design in D alot easier and faster. It an idea currently, I was just
> looking for some input.

Given that there is (by definition) no genuine OO stuff in Wine at the
moment, porting Wine (successfully) to an OO language is a task equal
to, if not greater than, reimplementing the current state of the
codebase from scratch.

On 24 June 2010 04:48, Stephen Eilert  wrote:
> On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph  wrote:
>> Well, being a garbage collected language, it would help with the memory
>> leaks in Wine. Being OOP it could extend the design of the code to make it
>> cleaner and reusable.
>
> The assertions above are opinions, not facts. Also, it requires a full 
> rewrite.
>
> Wine Initial release(per Wikipedia):4 July 1993

^^ Very important point.

I'm pretty sure that garbage collection on its own does not solve
memory leaks. Java is notorious for memory issues; if there's a leak
in the engine then no amount of fixking in your code will reduce the
memory footprint. Furthermore, if the leak is created by some
reference still being valid in the first place (i.e., not being
cleaned up by the code, which no doubt is the current case), then any
benefits of automated GC would be minimal at best.

Things that cause memory leaks are bad practice, and for a project as
large as Wine, I'm not sure relying on a language feature to clean up
the loose ends is the best idea.

Also, what benefit could an OO language bring to implementing
win32/win64? Are the Microsoft APIs actually suited to
object-orientied implementation?

> On Wed, Jun 23, 2010 at 4:17 PM, Gert van den Berg 
> wrote:
>>
>> On Wed, Jun 23, 2010 at 22:58, Christopher Selph 
>> wrote:
>> >>Porting a codebase the size
>> >>
>> >> >of Wine will probably take years...
>> >>
>> >> Actually I'm working on a program to convert C code to D code. You can
>> >> find/replace most instances of code, like unsigned int (C) with uint
>> >> (D).
>> >> The import/include files might take some work though.
>>
>> Just converting the syntax won't help much. It might compile, but it
>> lacks the design changes (such as proper OO) needed to properly
>> exploit a new language. You end up with code with the same problems as
>> the original, but in a language that the programmers are unfamiliar
>> with... (For C++, duplication of functionality in the STL is an
>> example of what often happens if you directly port C code)
>>
>> Wine (like the Linux kernel) might be a good codebase to test your
>> application on (for your own testing), since it is quite a large,
>> complicated codebase... The chances of having it accepted into Wine is
>> probably quite small... (My guess would be that your chances of being
>> struck by lightning while winning the lottery are about equal...)
>>
>> http://www.winehq.org/site/docs/winedev-guide/style-notes might give
>> you an idea of some of the things relatively simple patches struggle
>> with to get included...
>>
>> Gert
>
>
>
>
>




Re: Porting WIne to D

2010-06-23 Thread Christopher Selph
I agreee  that just converting syntax would not be enough, but it would make
OO design in D alot easier and faster. It an idea currently, I was just
looking for some input.

On Wed, Jun 23, 2010 at 4:17 PM, Gert van den Berg wrote:

> On Wed, Jun 23, 2010 at 22:58, Christopher Selph 
> wrote:
> >>Porting a codebase the size
> >>
> >> >of Wine will probably take years...
> >>
> >> Actually I'm working on a program to convert C code to D code. You can
> >> find/replace most instances of code, like unsigned int (C) with uint
> (D).
> >> The import/include files might take some work though.
>
> Just converting the syntax won't help much. It might compile, but it
> lacks the design changes (such as proper OO) needed to properly
> exploit a new language. You end up with code with the same problems as
> the original, but in a language that the programmers are unfamiliar
> with... (For C++, duplication of functionality in the STL is an
> example of what often happens if you directly port C code)
>
> Wine (like the Linux kernel) might be a good codebase to test your
> application on (for your own testing), since it is quite a large,
> complicated codebase... The chances of having it accepted into Wine is
> probably quite small... (My guess would be that your chances of being
> struck by lightning while winning the lottery are about equal...)
>
> http://www.winehq.org/site/docs/winedev-guide/style-notes might give
> you an idea of some of the things relatively simple patches struggle
> with to get included...
>
> Gert
>



Re: Porting WIne to D

2010-06-23 Thread Gert van den Berg
On Wed, Jun 23, 2010 at 22:58, Christopher Selph  wrote:
>>Porting a codebase the size
>>
>> >of Wine will probably take years...
>>
>> Actually I'm working on a program to convert C code to D code. You can
>> find/replace most instances of code, like unsigned int (C) with uint (D).
>> The import/include files might take some work though.

Just converting the syntax won't help much. It might compile, but it
lacks the design changes (such as proper OO) needed to properly
exploit a new language. You end up with code with the same problems as
the original, but in a language that the programmers are unfamiliar
with... (For C++, duplication of functionality in the STL is an
example of what often happens if you directly port C code)

Wine (like the Linux kernel) might be a good codebase to test your
application on (for your own testing), since it is quite a large,
complicated codebase... The chances of having it accepted into Wine is
probably quite small... (My guess would be that your chances of being
struck by lightning while winning the lottery are about equal...)

http://www.winehq.org/site/docs/winedev-guide/style-notes might give
you an idea of some of the things relatively simple patches struggle
with to get included...

Gert




Re: Porting WIne to D

2010-06-23 Thread Christopher Selph
>Porting a codebase the size

> >of Wine will probably take years...
>
> Actually I'm working on a program to convert C code to D code. You can
> find/replace most instances of code, like unsigned int (C) with uint (D).
> The import/include files might take some work though.
>
>
> On Wed, Jun 23, 2010 at 2:46 PM, Gert van den Berg 
> wrote:
>
>> On Wed, Jun 23, 2010 at 20:48, Stephen Eilert  wrote:
>> > On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph 
>> wrote:
>> >> Well, being a garbage collected language, it would help with the memory
>> >> leaks in Wine. Being OOP it could extend the design of the code to make
>> it
>> >> cleaner and reusable.
>> >
>> > The assertions above are opinions, not facts. Also, it requires a full
>> rewrite.
>> >
>> You can mix D code and C code...
>>
>> A more modern language can result in more readable code, but it is a
>> lot of effort for a small benefit... (And D is a very new language,
>> possibly to the degree that portability might be impacted due to a
>> lack of compilers on some of the more obscure platforms /
>> architectures).
>>
>> Certain parts of Wine might benefit from the latest (draft) version of
>> C++ and the size of the codebase can probably be reduced in size
>> slightly, but a bad port to another language doesn't help anyone...
>> (The C++ standard library is huge and might getrid of some POSIX
>> dependancies) It might require quite an extensive rewrite to get it to
>> a proper C++ program, rather than a C program containing a bit of C++
>> and compiled with a C++ compiler...
>>
>> Fixing the current problems with Wine should be a much higher priority
>> than porting it to a different language... Porting a codebase the size
>> of Wine will probably take years... C can do anything that other
>> languages can, the amount of effort might differ a bit, bit the
>> difference is probably minor compared to familiarizing yourself with a
>> new language, new libraries, etc
>>
>> (I like D - it have most features from languages like Java and C#,
>> with the option to switch off things like garbage collection and it
>> compiles to native code... Experimenting with it for new project might
>> make sense)
>>
>> (IMHO: Allowing other languages than C for some of Wine's bundled
>> applications (notepad, winecfg, winemine, etc) might make sense, as
>> long as the QC for committing patches doesn't suffer. The mixing of
>> languages within components (single application / DLL) will probably
>> cause confusion and ugly code though... Getting proper QC would
>> probably mostly involve sticking to things that AJ is familiar with.)
>>
>> Gert
>>
>>
>>
>



Re: Porting WIne to D

2010-06-23 Thread Gert van den Berg
On Wed, Jun 23, 2010 at 20:48, Stephen Eilert  wrote:
> On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph  wrote:
>> Well, being a garbage collected language, it would help with the memory
>> leaks in Wine. Being OOP it could extend the design of the code to make it
>> cleaner and reusable.
>
> The assertions above are opinions, not facts. Also, it requires a full 
> rewrite.
>
You can mix D code and C code...

A more modern language can result in more readable code, but it is a
lot of effort for a small benefit... (And D is a very new language,
possibly to the degree that portability might be impacted due to a
lack of compilers on some of the more obscure platforms /
architectures).

Certain parts of Wine might benefit from the latest (draft) version of
C++ and the size of the codebase can probably be reduced in size
slightly, but a bad port to another language doesn't help anyone...
(The C++ standard library is huge and might getrid of some POSIX
dependancies) It might require quite an extensive rewrite to get it to
a proper C++ program, rather than a C program containing a bit of C++
and compiled with a C++ compiler...

Fixing the current problems with Wine should be a much higher priority
than porting it to a different language... Porting a codebase the size
of Wine will probably take years... C can do anything that other
languages can, the amount of effort might differ a bit, bit the
difference is probably minor compared to familiarizing yourself with a
new language, new libraries, etc

(I like D - it have most features from languages like Java and C#,
with the option to switch off things like garbage collection and it
compiles to native code... Experimenting with it for new project might
make sense)

(IMHO: Allowing other languages than C for some of Wine's bundled
applications (notepad, winecfg, winemine, etc) might make sense, as
long as the QC for committing patches doesn't suffer. The mixing of
languages within components (single application / DLL) will probably
cause confusion and ugly code though... Getting proper QC would
probably mostly involve sticking to things that AJ is familiar with.)

Gert




Re: Porting WIne to D

2010-06-23 Thread Stephen Eilert
On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph  wrote:
> Well, being a garbage collected language, it would help with the memory
> leaks in Wine. Being OOP it could extend the design of the code to make it
> cleaner and reusable.

The assertions above are opinions, not facts. Also, it requires a full rewrite.

Wine Initial release(per Wikipedia):4 July 1993


Good luck.


 --Stephen

Sent from my Emacs




Re: Porting WIne to D

2010-06-23 Thread ニール・ゴンパ
On Wed, Jun 23, 2010 at 11:59 AM, Stephen Eilert  wrote:

> On Wed, Jun 23, 2010 at 1:38 PM, Christopher Selph 
> 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.



Re: Porting WIne to D

2010-06-23 Thread Stephen Eilert
On Wed, Jun 23, 2010 at 1:38 PM, Christopher Selph  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




Porting WIne to D

2010-06-23 Thread Christopher Selph
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