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 wine-devel@mohag.netwrote:
On Wed, Jun 23, 2010 at 20:48, Stephen Eilert spedrosa@gmail.com wrote:
On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph cds.wine@gmail.com
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
On Wed, Jun 23, 2010 at 22:58, Christopher Selph cds.wine@gmail.com 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
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 wine-devel@mohag.netwrote:
On Wed, Jun 23, 2010 at 22:58, Christopher Selph cds.wine@gmail.com 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
Please bottom-post on wine-devel.
On 24 June 2010 09:26, Christopher Selph cds.wine@gmail.com 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 spedrosa@gmail.com wrote:
On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph cds.wine@gmail.com 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 wine-devel@mohag.net wrote:
On Wed, Jun 23, 2010 at 22:58, Christopher Selph cds.wine@gmail.com 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
-
Ben Klein -
Christopher Selph -
Gert van den Berg