WWN Issue 267

This is the 267th issue of the Wine Weekly News publication. Its main goal is to eat leftovers. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org

This week, 211 posts consumed 1871 K. There were 72 different contributors. 41 (56%) posted more than once. 43 (59%) posted last week too.

The top 5 posters of the week were:

17 posts in 50K by Alexandre Julliard
10 posts in 30K by Francois Gouget
9 posts in 26K by Dimitrie O. Paun
9 posts in 37K by Frank Richter
8 posts in 24K by Jakob Eriksson

News: Sparx Systems Interview	03/19/2005	Archive
News In last week's news section we mentioned an Australian company, Sparx Systems, uses CrossOver Office as a way to run their app on Linux. I asked Sam Mancarella some questions about it to get a feel for how well the process works. I was thrilled Sam delved into the technical aspects of what they're doing. Overall, it sounds like it's been a positive experience for the company: BV: Could you give a brief summary of what Enterprise Architect does? Sam: Enterprise Architect is a UML 2.0 based modeling tool. It offers high-end features and performance at a price that allows for an entire development team to be outfitted, realizing the true potential of a collaborative and shared modeling environment. Our corporate focus is to provide an affordable, high-quality, team based modeling environment founded on the UML 2.0 specification, with comprehensive support for model driven generation of common development artifacts (documentation, source code, test scripts, requirements, resourcing and more). Enterprise Architect is an extensible environment supporting pluggable technologies using MDA and Software Factory concepts. A brief on EA's features include: UML 2.0 Support with all 13 UML 2 diagrams supported MDA (Model Driven Architecture) support (available soon in EA 4.6) Support for large models Team support Easy to use, explorer like interface Very low cost of ownership MDG Link plug-ins for Visual Studio.NET and Eclipse Forward and Reverse Code Engineering for C++ Java 1.5 Visual basic Delphi C# 2.0 VB.Net PHP 5 Database Modeling, forward and reverse database engineering Comprehensive HTML and RTF document generation (new WYSIWYG RTF Document generator available soon in EA 4.6) BV: Running a Windows application with Wine or CrossOver Office certainly seems like a good way to enter a new market. What advantages have you found? Sam: Absolutely. Porting a complex Windows application like EA to an OS like Linux is a very complex and expensive task for a company like Sparx Systems (EA's code base is in excess of over 500,000 lines of C++ code). "Porting" EA to the WINE/CrossOver Office environment was definitely a cost-effective solution in getting EA on the Linux platform. Over the past couple years, we at Sparx Systems have received several requests from users for native Linux and OS/X ports of EA. As we needed to undertake some research on the feasilibity of porting such a large application like EA outside of Windows, important to us were answers to key questions such as: the technical limitations, benefits and gaps which we needed to address before porting EA how many of our current userbase (in excess of 40,000 worldwide) would see value in an EA port to Linux, and most importantly how many new users would such a port attract and is the market potential significant enough for us to explore further. Given that the best way to answer these questions was to ultimately have a version of EA available in Linux we decided that an attempt to make EA's .exe work in WINE was the most suitable approach as it allowed us to continue to develop in a familiar environment, whilst provide users with a version of Linux they can use with minimal setup. As a result, we went with CrossOver Office mainly because of its extended support for many of the subsystems not readily supported in Wine (Help, MSXML, MSHTML, etc...) as well as the ease by which a cxoffice environment can be configured and manipulated with little regard to the underlying Linux/nix variant. BV: Has using CrossOver Office raised your support costs?* Sam: Our support/maintenance costs haven't changed as a result of the additional development/testing and maintenace cycles we need to perform - we already test EA on 4 Windows platforms (win98, winnt, win2k, winxp) to begin with so adding one other didn't really hurt. Debugging in cxoffice is a little trying at times as we tend to have to "debug" a release build on our test cxoffice environment - we have recently moved our Windows development onto Visual Studio 2003 so hopefully our attempts at remote debugging our cxoffice build will prove worthwhile. BV: Are you considering a native Linux port? Sam: We certainly are - we're considering a "native Non-Windows" port to firstly accommodate the x86 Linux variants as well as OS/X in the longer term. Porting an application like EA is not just a matter of making our codebase compile under WineLib and so forth, we also have to redesign a number of major subsystems to work outside of Windows (DB backend, XML parser, HTML, COM and so on). It is this process of design refactoring and redesign that is what we're concentrating our efforts on at the moment for the short term - once these subsystems are given the all-clear we can move on with our porting efforts. In short - watch this space! :) BV: So it sounds like you guys are actively developing EA on Linux. Sam: Yes, for our current EA on Linux users, please keep an eye on our website - http://www.sparxsystems.com for any up to date information. For prospective EA on Linux users, please download and try our evaluation, we'd love to hear your thoughts :) Thanks Sam! (Also, someone asked me recently about the interview series that was started a few years ago. It was great, and its something I wish I had time to work on more; unfortunately it was extremely time consuming. At some point I'll likely try to pick it up again.)

News: Sparx Systems Interview

03/19/2005

Archive

News

In last week's news section we mentioned an Australian company, Sparx Systems, uses CrossOver Office as a way to run their app on Linux. I asked Sam Mancarella some questions about it to get a feel for how well the process works. I was thrilled Sam delved into the technical aspects of what they're doing. Overall, it sounds like it's been a positive experience for the company:

BV: Could you give a brief summary of what Enterprise Architect does?

Sam: Enterprise Architect is a UML 2.0 based modeling tool. It offers high-end features and performance at a price that allows for an entire development team to be outfitted, realizing the true potential of a collaborative and shared modeling environment. Our corporate focus is to provide an affordable, high-quality, team based modeling environment founded on the UML 2.0 specification, with comprehensive support for model driven generation of common development artifacts (documentation, source code, test scripts, requirements, resourcing and more).

Enterprise Architect is an extensible environment supporting pluggable technologies using MDA and Software Factory concepts. A brief on EA's features include:

UML 2.0 Support with all 13 UML 2 diagrams supported
MDA (Model Driven Architecture) support (available soon in EA 4.6)
Support for large models
Team support
Easy to use, explorer like interface
Very low cost of ownership
MDG Link plug-ins for Visual Studio.NET and Eclipse
Forward and Reverse Code Engineering for
- C++
- Java 1.5
- Visual basic
- Delphi
- C# 2.0
- VB.Net
- PHP 5
Database Modeling, forward and reverse database engineering
Comprehensive HTML and RTF document generation (new WYSIWYG RTF Document generator available soon in EA 4.6)

BV: Running a Windows application with Wine or CrossOver Office certainly seems like a good way to enter a new market. What advantages have you found?

Sam: Absolutely. Porting a complex Windows application like EA to an OS like Linux is a very complex and expensive task for a company like Sparx Systems (EA's code base is in excess of over 500,000 lines of C++ code). "Porting" EA to the WINE/CrossOver Office environment was definitely a cost-effective solution in getting EA on the Linux platform.

Over the past couple years, we at Sparx Systems have received several requests from users for native Linux and OS/X ports of EA. As we needed to undertake some research on the feasilibity of porting such a large application like EA outside of Windows, important to us were answers to key questions such as:

the technical limitations, benefits and gaps which we needed to address before porting EA
how many of our current userbase (in excess of 40,000 worldwide) would see value in an EA port to Linux, and most importantly
how many new users would such a port attract and is the market potential significant enough for us to explore further.

Given that the best way to answer these questions was to ultimately have a version of EA available in Linux we decided that an attempt to make EA's .exe work in WINE was the most suitable approach as it allowed us to continue to develop in a familiar environment, whilst provide users with a version of Linux they can use with minimal setup. As a result, we went with CrossOver Office mainly because of its extended support for many of the subsystems not readily supported in Wine (Help, MSXML, MSHTML, etc...) as well as the ease by which a cxoffice environment can be configured and manipulated with little regard to the underlying Linux/*nix variant.

BV: Has using CrossOver Office raised your support costs?

Sam: Our support/maintenance costs haven't changed as a result of the additional development/testing and maintenace cycles we need to perform - we already test EA on 4 Windows platforms (win98, winnt, win2k, winxp) to begin with so adding one other didn't really hurt. Debugging in cxoffice is a little trying at times as we tend to have to "debug" a release build on our test cxoffice environment - we have recently moved our Windows development onto Visual Studio 2003 so hopefully our attempts at remote debugging our cxoffice build will prove worthwhile.

BV: Are you considering a native Linux port?

Sam: We certainly are - we're considering a "native Non-Windows" port to firstly accommodate the x86 Linux variants as well as OS/X in the longer term. Porting an application like EA is not just a matter of making our codebase compile under WineLib and so forth, we also have to redesign a number of major subsystems to work outside of Windows (DB backend, XML parser, HTML, COM and so on). It is this process of design refactoring and redesign that is what we're concentrating our efforts on at the moment for the short term - once these subsystems are given the all-clear we can move on with our porting efforts. In short - watch this space! :)

BV: So it sounds like you guys are actively developing EA on Linux.

Sam: Yes, for our current EA on Linux users, please keep an eye on our website - http://www.sparxsystems.com for any up to date information. For prospective EA on Linux users, please download and try our evaluation, we'd love to hear your thoughts :)

Thanks Sam!

(Also, someone asked me recently about the interview series that was started a few years ago. It was great, and its something I wish I had time to work on more; unfortunately it was extremely time consuming. At some point I'll likely try to pick it up again.)

Direct3D Update	03/21/2005	Archive
DirectX Paul Vriens wanted to know what might happen to Oliver Stieber's Direct3D 9 work since Oliver might have problems submitting it: There were at least 4 patches or so he sent which were not applied (yet). If the sole reason for that is that it couldn't be merged/applied to CVS I could give it a try. But that's about the only thing I can do regarding wined3d stuff. Oliver sent an update with where all of this needs to head: I've just merged with wine head and am about to resend the patches, and another couple for stateblocks and sampler states. After that there's vertex declarations and resource tracking, pointsprites, non-power2 textures, memory management, D3DPOOL_DEFAULT texture operations and a few more tidyups. Then I should have all the stable work synced with winehead. After that stateblocks need to be refactored to get offscreen textures, swapchains and multiple devices/threads working properly which may take a while to stabilise. A software vertex pipeline also needs writing to fill in the gaps in the hardware support which is fairly easy, and d3d8 interfaces need to wrap up wined3d. Shaders needs moving across from d3d8 which is fairly simple and shader 2.0 support needs writing which is a little trickier.

Direct3D Update

03/21/2005

Archive

DirectX

Paul Vriens wanted to know what might happen to Oliver Stieber's Direct3D 9 work since Oliver might have problems submitting it:

There were at least 4 patches or so he sent which were not applied (yet).

If the sole reason for that is that it couldn't be merged/applied to CVS I could give it a try. But that's about the only thing I can do regarding wined3d stuff.

Oliver sent an update with where all of this needs to head:

I've just merged with wine head and am about to resend the patches, and another couple for stateblocks and sampler states.

After that there's vertex declarations and resource tracking, pointsprites, non-power2 textures, memory management, D3DPOOL_DEFAULT texture operations and a few more tidyups.

Then I should have all the stable work synced with winehead.

After that stateblocks need to be refactored to get offscreen textures, swapchains and multiple devices/threads working properly which may take a while to stabilise. A software vertex pipeline also needs writing to fill in the gaps in the hardware support which is fairly easy, and d3d8 interfaces need to wrap up wined3d.

Shaders needs moving across from d3d8 which is fairly simple and shader 2.0 support needs writing which is a little trickier.

Theming Revisited 03/21/2005 Archive

Theming Revisited	03/21/2005	Archive
Controls The topic of theming has popped up again in a few different threads. Frank Richter went beyond hypothesizing about it and implemented a sample. He started off a thread with: To see how easy (or not) it would be to make the controls use themes, I tried to get themed buttons; the result is the attached patch (to try it out, you need an .msstyles file and appropriate registry setup). It's probably not perfect as it is, comments/questions are welcome. Screenshot: http://img87.exs.cx/my.php?loc=img87.=winewiththemedbuttons3xh.png Some funny side effect when theming is enabled: applications show up in standard colors, but as soon as the first button is created, the colors switch to the theme's colors. I guess opening the theme data in the button code triggers some uxtheme initialization that in turn changes the system colors. Also, all applications get themed buttons, which diverges from WinXPs behaviour and may or may not be desired for some apps. Mike Hearn liked the method Frank used: Hey, brilliant work! Definitely submit this - it doesn't matter if not everything is themed all at once, this can be a long term project and the approach you've taken seems to be a good one. Yes XP does not theme all apps for compatibility reasons. Once more of our controls are themable I guess we can start to worry about switching it on at the right time. I'd suggest posting this to wine-patches and seeing what happens. Once we get it into CVS, would you be willing to move on and do the other controls? Dmitry Timoshkov felt more work needed to go into the low-level parts of it, user32 cannot depend on uxtheme or any other high level dll. You need to make all the work inside of uxtheme by subclassing/patching every class you wish to change the painting for, and do all the painting inside of uxtheme. I'm not sure how to do it cleanly without adding an explicit dependency of every app on uxtheme. Do you know how Windows does theming on low level? Mike wasn't sure that approach would be best: Hmm, why not? For DLLs that can be recompiled and used on Windows this policy makes sense but our user32 cannot be, so I do not see what we would lose by having this. The alternative is to copy/paste the code into comctl32 which is what Microsoft appears to have done, and I know we don't want to do that Dmitry explained why it would still be a problem, It creates circular dependencies and an impossibility to correctly start up Wine. Imagine for a moment that ntdll depends on foo.dll which in turn imports kernel32. Frank thought that could worked around by loading uxtheme.dll only when it was actually needed. After some investigation it appeared a special, and undocumented API, called RegisterUserApiHook in user32.dll was respsonsible for getting theming to work. Alexandre weighed in and said however Windows makes it work should be how Wine does it. Rob Shearman was familiar with RegisterUserApiHook and wasn't sure if Wine should use it: `typedef DWORD (CALLBACK * USERAPIHOOKPROC)(HINSTANCE hInstance, FARPROC *fnUserApis);` `DWORD WINAPI RegisterUserApiHook(HINSTANCE hInstance, USERAPIHOOKPROC fnUserApiHook);` fnUserApis is an array of User functions that can be overridden. RegisterUserApiHook is a function that is called once for the entire system and then user32 loads the specified module for each process and calls the specified fnUserApiHook function for that process. It is a cumbersome interface that may not be worth duplicating. Frank went back to seeing how Windows actually worked and came up with a question about the process, Most interesting is probably to find out how the standard controls from user32 are themed. Poking a bit around in comctl32 6.0, it seems that it actually just registers the standard classes with RegisterClassW, nothing more. AFAIK you can't register a class when the class name is already used, so it would be interesting to know why comctl32.dll can get away with it. Boaz Harrosh had a theory about how it worked and then provided a possible method for dealing with it: Maybe it only register as per Process, which makes sense. And it does that before any window is displayed. Actually I know when. (A bug I had) it does it in the InitCommonControlsEx call. Not even in the DLLMain. An app that needs theming needs 3 things. Link to comctl32 call InitCommonControlsEx a manifest Right? So I guess you have it. I'm not 100% but I think there is no need for duplicate code. All comctl32 needs to do is chain to the user32 classes, only overriding PAINT messages and some mouse events. So you don't have to reinvent the wheel. Do you need lots of themed controls WM_PAINT code? Check out codeproject.com GUILIB project. They owner draw all the windows controls with theme support. Rob cautioned: It's not just the painting that needs to be overridden. The controls often need to be able to calculate their size. The interface to UxTheme is fairly straight-forward. The SDK sample "ThemeExplorer" is probably worth looking at.

Controls

The topic of theming has popped up again in a few different threads. Frank Richter went beyond hypothesizing about it and implemented a sample. He started off a thread with:

To see how easy (or not) it would be to make the controls use themes, I tried to get themed buttons; the result is the attached patch (to try it out, you need an .msstyles file and appropriate registry setup). It's probably not perfect as it is, comments/questions are welcome.

Screenshot:

http://img87.exs.cx/my.php?loc=img87.=winewiththemedbuttons3xh.png

Some funny side effect when theming is enabled: applications show up in standard colors, but as soon as the first button is created, the colors switch to the theme's colors. I guess opening the theme data in the button code triggers some uxtheme initialization that in turn changes the system colors.

Also, all applications get themed buttons, which diverges from WinXPs behaviour and may or may not be desired for some apps.

Mike Hearn liked the method Frank used:

Hey, brilliant work! Definitely submit this - it doesn't matter if not everything is themed all at once, this can be a long term project and the approach you've taken seems to be a good one.

Yes XP does not theme all apps for compatibility reasons. Once more of our controls are themable I guess we can start to worry about switching it on at the right time.

I'd suggest posting this to wine-patches and seeing what happens. Once we get it into CVS, would you be willing to move on and do the other controls?

Dmitry Timoshkov felt more work needed to go into the low-level parts of it, user32 cannot depend on uxtheme or any other high level dll. You need to make all the work inside of uxtheme by subclassing/patching every class you wish to change the painting for, and do all the painting inside of uxtheme. I'm not sure how to do it cleanly without adding an explicit dependency of every app on uxtheme. Do you know how Windows does theming on low level?

Mike wasn't sure that approach would be best:

Hmm, why not? For DLLs that can be recompiled and used on Windows this policy makes sense but our user32 cannot be, so I do not see what we would lose by having this.

The alternative is to copy/paste the code into comctl32 which is what Microsoft appears to have done, and I know we don't want to do that

Dmitry explained why it would still be a problem, It creates circular dependencies and an impossibility to correctly start up Wine. Imagine for a moment that ntdll depends on foo.dll which in turn imports kernel32.

Frank thought that could worked around by loading uxtheme.dll only when it was actually needed. After some investigation it appeared a special, and undocumented API, called RegisterUserApiHook in user32.dll was respsonsible for getting theming to work. Alexandre weighed in and said however Windows makes it work should be how Wine does it. Rob Shearman was familiar with RegisterUserApiHook and wasn't sure if Wine should use it:

typedef DWORD (CALLBACK * USERAPIHOOKPROC)(HINSTANCE hInstance, FARPROC *fnUserApis);

DWORD WINAPI RegisterUserApiHook(HINSTANCE hInstance, USERAPIHOOKPROC fnUserApiHook);

fnUserApis is an array of User functions that can be overridden.

RegisterUserApiHook is a function that is called once for the entire system and then user32 loads the specified module for each process and calls the specified fnUserApiHook function for that process. It is a cumbersome interface that may not be worth duplicating.

Frank went back to seeing how Windows actually worked and came up with a question about the process, Most interesting is probably to find out how the standard controls from user32 are themed. Poking a bit around in comctl32 6.0, it seems that it actually just registers the standard classes with RegisterClassW, nothing more. AFAIK you can't register a class when the class name is already used, so it would be interesting to know why comctl32.dll can get away with it.

Boaz Harrosh had a theory about how it worked and then provided a possible method for dealing with it:

Maybe it only register as per Process, which makes sense. And it does that before any window is displayed. Actually I know when. (A bug I had) it does it in the InitCommonControlsEx call. Not even in the DLLMain. An app that needs theming needs 3 things.

Link to comctl32
call InitCommonControlsEx
a manifest

Right? So I guess you have it.

I'm not 100% but I think there is no need for duplicate code. All comctl32 needs to do is chain to the user32 classes, only overriding PAINT messages and some mouse events. So you don't have to reinvent the wheel.

Do you need lots of themed controls WM_PAINT code? Check out codeproject.com GUILIB project. They owner draw all the windows controls with theme support.

Rob cautioned:

It's not just the painting that needs to be overridden. The controls often need to be able to calculate their size.

The interface to UxTheme is fairly straight-forward. The SDK sample "ThemeExplorer" is probably worth looking at.

Finding Regressions	03/24/2005	Archive
Debugging The topic of finding which patches caused a regression came up three separate times this week. Me thinks it's time to give a little coverage to it. Joris Huizer asked about how to track down a problem with Internet Explorer: I tried to search for information on regressions on the winehq site but I couldn't find it (maybe it should be made visible on the documentation page?) Anyway, in Internet Explorer a visual regression happened: with my previous cvs build from 15 march, things were displayed correctly, but now (cvs build from 23 march) the 'address' and the 'links' fields are displayed incorrectly: they are bigger than they should be, and they are 'striked through' which should not happen; See also the attached screenshots - I'm sure it's clear what I mean. Could someone point me to the correct pages to find out what caused this? I'm sure someone will be fix this a lot faster than I could do but I want to learn how to solve such a problem :) James Hawkins supplied the relevant information: You could run a regression test. http://www.winehq.org/docs/winedev-guide/x1344 Make sense? Okay, now everyone go out and locate your favorite regressions and let us know where the bugs are. Extra credit will be awarded for supplying a patch yourself.

Finding Regressions

03/24/2005

Archive

Debugging

The topic of finding which patches caused a regression came up three separate times this week. Me thinks it's time to give a little coverage to it. Joris Huizer asked about how to track down a problem with Internet Explorer:

I tried to search for information on regressions on the winehq site but I couldn't find it (maybe it should be made visible on the documentation page?)

Anyway, in Internet Explorer a visual regression happened: with my previous cvs build from 15 march, things were displayed correctly, but now (cvs build from 23 march) the 'address' and the 'links' fields are displayed incorrectly: they are bigger than they should be, and they are 'striked through' which should not happen; See also the attached screenshots - I'm sure it's clear what I mean.

Could someone point me to the correct pages to find out what caused this? I'm sure someone will be fix this a lot faster than I could do but I want to learn how to solve such a problem :)

James Hawkins supplied the relevant information:

You could run a regression test. http://www.winehq.org/docs/winedev-guide/x1344

Make sense? Okay, now everyone go out and locate your favorite regressions and let us know where the bugs are. Extra credit will be awarded for supplying a patch yourself.

Help Save Winrash	03/24/2005	Archive
Testing We've had a bit of a problem lately with Wine's automatic testing infrastructure. About 9 months ago a system was put into place to automatically download Wine's test suite and run it on Windows systems. The idea was that guesses about how the Windows API performed could be tested every day on a large number of systems. Well, it actually worked. People did notice problems with Wine and the tests, and problems actually did get fixed. Ivan Leo Puoti wanted to know if the system would be back up again: Currently winrash users aren't returning any results from their testing. This is because we need tests to run on a visible desktop, better still in interactive mode. To save both the tests and winrash we need winrash to be somewhat similar to windows automatic updates, when new tests are available, winrash should pop up and say "new tests are available, run now?" and then give a yes/no, later option. Like this we can have interactive tests, and use winrash so people don't have to remember to download/run the tests. I do it but downloading the exe manually/opening a command line in the desktop/running the tests with the -t option/deleting the test.exe file isn't exactly user friendly. Maybe this task should go in the todo list, or should at least go on the web site somewhere, it would be an attractive task for newcomers with windows programming experience. Chris Morgan, the author of winrash, has been pretty busy lately and mentioned in IRC he just doesn't have the time right now to fix some of the issues. This seems like a pretty good opportunity for someone to get involved since the there's a pretty good guideline of what needs to be done. Rob Shearman replied to Ivan, I have already sent links to documents on MSDN that state how to make a service run on an interactive desktop. As some of the tests are a little distracting graphically, we should probably do the dialog as you suggest. I guess this is really up to the people running the test machines. If the source to winrash was in the Wine tree I would already have fixed it by now. That brought up moving the winrash source into the Wine CVS. Originally winrash was thought to be a general purpose utility and was put on SourceForge as its own project. Apparently that's hindered development more than anything. Dimi thought it was worth making it part of Wine so it could be managed more easily. Steven Edwards had another reason for merging it, I have enough CVS and SVN trees on my desk without having to manage another and manage dealing with keeping them in sync when they share code. If ReactOS is going to use Winetest and Winrash I really need the winrash sources to be in WineHQ CVS or the ReactOS people with either A) fork it or B) write their own service. Ivan went on to point out some problems with winetest that could be cleaned up, Currently the tests also open a windows explorer window, and leave it open. Recently winetest is leaving a testdir directory behind it, so cleanup needs to be done better. I think the whole winetest gui should go up when tests are run, so the user can get the progress bar. Winrash can probably be integrated into the CVS in programs/. I would help myself but I lack a real win installation (not counting qemu), a recent build of win, and need to get on with ntoskrnl.

Help Save Winrash

03/24/2005

Archive

Testing

We've had a bit of a problem lately with Wine's automatic testing infrastructure. About 9 months ago a system was put into place to automatically download Wine's test suite and run it on Windows systems. The idea was that guesses about how the Windows API performed could be tested every day on a large number of systems. Well, it actually worked. People did notice problems with Wine and the tests, and problems actually did get fixed. Ivan Leo Puoti wanted to know if the system would be back up again:

Currently winrash users aren't returning any results from their testing. This is because we need tests to run on a visible desktop, better still in interactive mode. To save both the tests and winrash we need winrash to be somewhat similar to windows automatic updates, when new tests are available, winrash should pop up and say "new tests are available, run now?" and then give a yes/no, later option. Like this we can have interactive tests, and use winrash so people don't have to remember to download/run the tests. I do it but downloading the exe manually/opening a command line in the desktop/running the tests with the -t option/deleting the test.exe file isn't exactly user friendly. Maybe this task should go in the todo list, or should at least go on the web site somewhere, it would be an attractive task for newcomers with windows programming experience.

Chris Morgan, the author of winrash, has been pretty busy lately and mentioned in IRC he just doesn't have the time right now to fix some of the issues. This seems like a pretty good opportunity for someone to get involved since the there's a pretty good guideline of what needs to be done.

Rob Shearman replied to Ivan, I have already sent links to documents on MSDN that state how to make a service run on an interactive desktop. As some of the tests are a little distracting graphically, we should probably do the dialog as you suggest. I guess this is really up to the people running the test machines. If the source to winrash was in the Wine tree I would already have fixed it by now.

That brought up moving the winrash source into the Wine CVS. Originally winrash was thought to be a general purpose utility and was put on SourceForge as its own project. Apparently that's hindered development more than anything. Dimi thought it was worth making it part of Wine so it could be managed more easily. Steven Edwards had another reason for merging it, I have enough CVS and SVN trees on my desk without having to manage another and manage dealing with keeping them in sync when they share code. If ReactOS is going to use Winetest and Winrash I really need the winrash sources to be in WineHQ CVS or the ReactOS people with either A) fork it or B) write their own service.

Ivan went on to point out some problems with winetest that could be cleaned up, Currently the tests also open a windows explorer window, and leave it open. Recently winetest is leaving a testdir directory behind it, so cleanup needs to be done better. I think the whole winetest gui should go up when tests are run, so the user can get the progress bar. Winrash can probably be integrated into the CVS in programs/. I would help myself but I lack a real win installation (not counting qemu), a recent build of win, and need to get on with ntoskrnl.

Images from video4linux Devices	03/20/2005	Archive
Graphics Getting webcams to work has come up in the past few weeks and it seems there's some people trying to get stuff like that working. Luis Lenders sent a patch to wine-devel this week: don't know if it's of much use for anyone, but i can now view the images from my webcam in the preview window in programs like Virtualdub, Paltalk and WebCamnow. Basically the attached "patch" reads an RGB-image from my video4linux device and "turns" this into a bitmap, which is then displayed. The device must be able to "read RGBs". In case you would like to try, replace dlls/avicap32 with the attached one, and replace include/vfw.h with the attached vfw.h. I'm skilled enough to turn this into a real patch, maybe someone with more programming capabilities could give it try. I think Luis meant that he's not skilled enough to get this into Wine. However, it may serve as a starting point for someone else. Rick Romero took a look at it and fixed some problems: That code doesn't with my QuickCam 3000, which defaults to YUV420. The attached patch adds YUV420 support back in to vidcat.c, and should still work with RGB cams.

Images from video4linux Devices

03/20/2005

Archive

Graphics

Getting webcams to work has come up in the past few weeks and it seems there's some people trying to get stuff like that working. Luis Lenders sent a patch to wine-devel this week:

don't know if it's of much use for anyone, but i can now view the images from my webcam in the preview window in programs like Virtualdub, Paltalk and WebCamnow. Basically the attached "patch" reads an RGB-image from my video4linux device and "turns" this into a bitmap, which is then displayed. The device must be able to "read RGBs". In case you would like to try, replace dlls/avicap32 with the attached one, and replace include/vfw.h with the attached vfw.h. I'm skilled enough to turn this into a real patch, maybe someone with more programming capabilities could give it try.

I think Luis meant that he's not skilled enough to get this into Wine. However, it may serve as a starting point for someone else. Rick Romero took a look at it and fixed some problems:

That code doesn't with my QuickCam 3000, which defaults to YUV420.

The attached patch adds YUV420 support back in to vidcat.c, and should still work with RGB cams.

World Wine News