Re: [Tools 5/6] winetest: Add statistics for the number of unit tests with errors or todos.
Francois Gouget wrote: Also tweak the headers and footers a bit. --- This gives us a better idea of how many unit tests are failing. winetest/gather | 67 ++ 1 files changed, 62 insertions(+), 5 deletions(-) diff --git a/winetest/gather b/winetest/gather Hi Francois, I think something is 'wrong' with the statistics for the Wine group: http://test.winehq.org/data/200803211000/#group_Wine They are the same for every box with respect to the X + Y. The title (on mouse over) is correct though. -- Cheers, Paul.
Re: [Tools 5/6] winetest: Add statistics for the number of unit tests with errors or todos.
Paul Vriens wrote:
Francois Gouget wrote:
Also tweak the headers and footers a bit.
---
This gives us a better idea of how many unit tests are failing.
winetest/gather | 67
++
1 files changed, 62 insertions(+), 5 deletions(-)
diff --git a/winetest/gather b/winetest/gather
Hi Francois,
I think something is 'wrong' with the statistics for the Wine group:
http://test.winehq.org/data/200803211000/#group_Wine
They are the same for every box with respect to the X + Y. The title
(on mouse over) is correct though.
Would this do? :
diff --git a/winetest/gather b/winetest/gather
index 294ad06..fdacff5 100755
--- a/winetest/gather
+++ b/winetest/gather
@@ -362,7 +362,7 @@ EOF
pass;
my $count=!$report-{todos} ? $report-{errors} :
!$report-{errors} ? $report-{todos} :
- $group-{errors}+$group-{todos};
+ $report-{errors}+$report-{todos};
my $prcnt=!$report-{todos} ? percent($report-{errors}, $unit_count)
:
!$report-{errors} ? percent($report-{todos}, $unit_count)
:
--
Cheers,
Paul.
Re: MinGW cross compilation fails for d3dx9_36/tests
Are you currently working on this? Is it a problem that needs to be fixed on the mingw side? It's indeed a mingw issue and has to be fixed on that side. I've never touched mingw so I'm relying on either Hans Leidekker, Stefan Leichter or Paul Millar to take this up. The problem is that it is a mingw issue but they don't want any patches from wines win32 api in their mingw w32api. They believe that looking at the actual ms header files taints our headers legally speaking. Stefan, hans, and PaulM maintain a rather large set of patches against w32api. [1] So its a constant catchup game from when wines headers get new additions until someone sends paulm a patch updating the mingw w32api. I made a script [2] that will cross build winetest from git source no mingw patches needed. In theory this could be useful in keeping the cross built winetest.exe's rolling. To use the script you need 3 dirs a wine-git, wine-native, and a wine-pe. Set those locations in the config part of the script as well as the build and host settings for your compiler and cross compiler. At the end winetest.exe will be in wine-pe/programs/winetest/ folder. This setup is from PaulMs recipe [3] with some tweaking. Also if you trust me and just want the exe its at [4]. Hope this helps, John P.S. I logged some test results from my win2k machine, it seems they are at [5]. Seems like I missed some setting though as the date is not right. Advice on how to fix that would be delicious =) [1] http://readlist.com/lists/lists.sourceforge.net/mingw-users/1/5419.html [2] http://klehm.net/wine/crossbuild_winetest.sh [3] http://www.winehq.org/pipermail/wine-devel/2006-December/053069.html [4] http://klehm.net/wine/winetest.exe [5] http://test.winehq.org/data/06d429d6b6b6d63beaeda130a3bb261ef3b9fb41/
Re: MinGW cross compilation fails for d3dx9_36/tests
John Klehm wrote: P.S. I logged some test results from my win2k machine, it seems they are at [5]. Seems like I missed some setting though as the date is not right. Advice on how to fix that would be delicious =) It uses the file programs/winetest/build.id for this. -- Cheers, Paul.
GSOC proposal: DirectPlay4
Hello everybody, I plan on applying for Google's Summer of Code to work on DirectPlay4 support in wine. (This was mentioned on the ideas page, http://wiki.winehq.org/SummerOfCode). I've looked at the code currently in wine, and it looks like there is some work done, but a number of the functions exported in the corresponding dlls are stubs or partial stubs. Alot of work needs to be done to dplay to make it more compliant (or at least more functional). This would allow several games that depend on DirectPlay to work without copying dll's from a windows partition. So I intend to makes sure the IDirectPlay4 COM interface is sufficiently implemented and that it meets the requirements set forth in in the DirectPlay4 specification. If time permits, I'd like to look into the Reliable Specification for DirectPlay4, but i think implementing just the core specification will keep me busy. I've never worked on an open source project before, but I have wanted to for quite some time. I'm looking forward to contributing to a project that I've used quite a bit in the past few years. ;) I thought I would introduce myself a bit here. I'm currently a computer engineering student at a University in the United States. I've been programming since I was about 13, and I've had all kinds of personal projects from a somewhat functional 3D game engines to a ray tracer. I was also chosen to participate on our school's team for the ACM programming competition. In short, I'm a programmer at heart. I'm putting the final touches on my application and would greatly appreciate any thoughts or comments before I submit it through Google. Thanks, Matthew Canterbury
Re: MinGW cross compilation fails for d3dx9_36/tests
John Klehm [EMAIL PROTECTED] writes: P.S. I logged some test results from my win2k machine, it seems they are at [5]. Seems like I missed some setting though as the date is not right. Advice on how to fix that would be delicious =) It's now using the git commit sha1 instead of a date when building from a git tree, that's a feature. I'm hoping we can standardize on that to make sure all test runs properly identify the exact source used. -- Alexandre Julliard [EMAIL PROTECTED]
Re: amstream: IAMMultiMediaStream::EnumMediaStreams
Nikolay Sivov wrote:
@@ -144,9 +144,18 @@
{
IAMMultiMediaStreamImpl *This = (IAMMultiMediaStreamImpl *)iface;
-FIXME((%p/%p)-(%ld,%p) stub!\n, This, iface, Index, ppMediaStream);
+TRACE((%p/%p)-(%d,%p)\n, This, iface, Index, ppMediaStream);
-return E_NOTIMPL;
+/* check out of range */
+if(Index 0 || Index = This-nbStreams)
+return S_FALSE;
+/* NULL pointer */
+if(!(*ppMediaStream))
+return E_POINTER;
+
+*ppMediaStream = This-pStreams[Index];
+
+return S_OK;
}
You need to call IMediaStream_AddRef on the returned stream.
--
Rob Shearman
Re: MinGW cross compilation fails for d3dx9_36/tests
On Tue, Mar 25, 2008 at 4:39 AM, Roderick Colenbrander [EMAIL PROTECTED] wrote: As a sidenote. You are also cross compiling wine dlls so now and then. It would be useful to also cross compile d3d8/d3d9 and wined3d but for wined3d -DUSE_WIN32_OPENGL must be set. Well let me know how this works for you. I'll refactor my script a bit later today but for right now you have to run this one after the winetest script, as this one counts on the environment that the winetest script sets up. Script to crossbuild d3d dlls [1] and the dlls themselves [2], [3], [4] are out there. John [1] http://klehm.net/wine/crossbuild_d3d_dlls.sh [2] http://klehm.net/wine/d3d8.dll [3] http://klehm.net/wine/d3d9.dll [4] http://klehm.net/wine/wined3d.dll
Re: MinGW cross compilation fails for d3dx9_36/tests
On Fri, Mar 28, 2008 at 6:05 AM, John Klehm [EMAIL PROTECTED] wrote: On Tue, Mar 25, 2008 at 4:39 AM, Roderick Colenbrander [EMAIL PROTECTED] wrote: As a sidenote. You are also cross compiling wine dlls so now and then. It would be useful to also cross compile d3d8/d3d9 and wined3d but for wined3d -DUSE_WIN32_OPENGL must be set. Well let me know how this works for you. I'll refactor my script a bit later today but for right now you have to run this one after the winetest script, as this one counts on the environment that the winetest script sets up. Script to crossbuild d3d dlls [1] and the dlls themselves [2], [3], [4] are out there. John [1] http://klehm.net/wine/crossbuild_d3d_dlls.sh [2] http://klehm.net/wine/d3d8.dll [3] http://klehm.net/wine/d3d9.dll [4] http://klehm.net/wine/wined3d.dll Sorry I forgot it the first time, but you'll also need libwine.dll [1] in addition to the other d3d dlls. Test them out on your own window machine with [2]. Just put them in the same directory as the program. John [1] http://klehm.net/wine/libwine.dll [2] http://www.codesampler.com/source/dx8_multitexture.zip
Re: 2/2 WineD3D: initial post pixelshader blending support
Am Freitag, 28. März 2008 10:25:31 schrieb Roderick Colenbrander: Hi, Store a flag whether a format supports blending in the formats table. This patch uses the flag in the blending code and in a few other places to verify if we should turn on blending for the given format. A next patch will also us e this flag for a CheckPixelShaderBlendingCapability call for CheckDeviceFormat. Later on I plan to move more of the Check*Capability functions over to the table. Regarding the glDisable(GL_BLEND) in the CTXUSAGE_CLEAR setup: You have to mark the D3D state dirty in the context when doing that, otherwise blending might not be re-enabled properly on the next draw. I also think that disabling blending for clearing is orthogonal to the rest of the patch and should be done in a separate patch. +#define WINED3DFMT_FLAG_POSTPIXELSHADER_BLENDING 1 Maybe use 0x1 instead of 1? That will make adding new flags beyond 8 clearer. Otherwise it looks good!
Re: [3/5] WineD3D: Support clipplanes with GLSL shaders
Am Freitag, 28. März 2008 02:57:46 schrieb Stefan Dösinger: Please do not apply this patch yet. We are not sure if we should write the Z corrected coord as clip coord or not
Re: GSOC proposal: DirectPlay4
On Thursday 27 March 2008 19:50:02 Matthew Canterbury wrote: Hello everybody, I plan on applying for Google's Summer of Code to work on DirectPlay4 support in wine. (This was mentioned on the ideas page, http://wiki.winehq.org/SummerOfCode). I've looked at the code currently in wine, and it looks like there is some work done, but a number of the functions exported in the corresponding dlls are stubs or partial stubs. Alot of work needs to be done to dplay to make it more compliant (or at least more functional). Currently all it does is to not crash apps trying to load it. :) This would allow several games that depend on DirectPlay to work without copying dll's from a windows partition. So I intend to makes sure the IDirectPlay4 COM interface is sufficiently implemented and that it meets the requirements set forth in in the DirectPlay4 specification. Good, the idea here is to finish up the COM interface and make it send the appropriate dplay messages. If time permits, I'd like to look into the Reliable Specification for DirectPlay4, but i think implementing just the core specification will keep me busy. He, probably not worth the effort for now. I'd focus on the core protocol. My guess is that we can get all games to work without it. You need to think about how you want to go about implementing the protocol step by step and what game you want to be using for testing. Have you played with the DirectPlay dissector in Wireshark already? You need to get Wireshark from SVN to get the latest, greatest version of the dissector. Try and get some network captures of the game you want to test to see what the messages look like on the wire and how a typical dplay session looks like. Looking forward to your application, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
Re: MinGW cross compilation fails for d3dx9_36/tests
John Klehm [EMAIL PROTECTED] wrote: The problem is that it is a mingw issue but they don't want any patches from wines win32 api in their mingw w32api. They believe that looking at the actual ms header files taints our headers legally speaking. Stefan, hans, and PaulM maintain a rather large set of patches against w32api. [1] So its a constant catchup game from when wines headers get new additions until someone sends paulm a patch updating the mingw w32api. Then perhaps we (Alexandre) should reconsider the stance about using Wine headers and import libraries in preference to mingw ones. -- Dmitry.
Re: MinGW cross compilation fails for d3dx9_36/tests
Dmitry Timoshkov [EMAIL PROTECTED] writes: John Klehm [EMAIL PROTECTED] wrote: The problem is that it is a mingw issue but they don't want any patches from wines win32 api in their mingw w32api. They believe that looking at the actual ms header files taints our headers legally speaking. Stefan, hans, and PaulM maintain a rather large set of patches against w32api. [1] So its a constant catchup game from when wines headers get new additions until someone sends paulm a patch updating the mingw w32api. Then perhaps we (Alexandre) should reconsider the stance about using Wine headers and import libraries in preference to mingw ones. Agreed, the idea of using w32api is that we want to help improve mingw by finding problems in their headers and libraries, but if they are not going to accept our patches anyway, then there's clearly no point in continuing to make our life harder by using their stuff. -- Alexandre Julliard [EMAIL PROTECTED]
Re: MinGW cross compilation fails for d3dx9_36/tests
Alexandre Julliard wrote: Dmitry Timoshkov [EMAIL PROTECTED] writes: John Klehm [EMAIL PROTECTED] wrote: The problem is that it is a mingw issue but they don't want any patches from wines win32 api in their mingw w32api. They believe that looking at the actual ms header files taints our headers legally speaking. Stefan, hans, and PaulM maintain a rather large set of patches against w32api. [1] So its a constant catchup game from when wines headers get new additions until someone sends paulm a patch updating the mingw w32api. Then perhaps we (Alexandre) should reconsider the stance about using Wine headers and import libraries in preference to mingw ones. Agreed, the idea of using w32api is that we want to help improve mingw by finding problems in their headers and libraries, but if they are not going to accept our patches anyway, then there's clearly no point in continuing to make our life harder by using their stuff. And can't we just start creating the winetest executable at winehq somewhere? -- Cheers, Paul.
Re: [PATCH 3/7] services: Start a local RPC server.
Robert Shearman [EMAIL PROTECTED] writes:
+handle_t __RPC_USER MACHINE_HANDLEW_bind(MACHINE_HANDLEW MachineName)
+{
+WCHAR transport[] = SVCCTL_TRANSPORT;
+WCHAR endpoint[] = SVCCTL_ENDPOINT;
+LPWSTR server_copy = NULL;
+RPC_WSTR binding_str;
+RPC_STATUS status;
+handle_t rpc_handle;
+
+/* unlike Windows we start services.exe on demand. We start it always as
+ * checking if this is our address can be tricky */
+if (!check_services_exe())
+return NULL;
I think it would be OK to assume that services.exe is started by
wineboot and is always running, since we'll have at least the mountmgr
service running all the time.
+/* Not the Windows event name - if needed the true one can be found in
Inside Windows */
+cpp_quote(#define SVCCTL_STARTED_EVENT (const
WCHAR[]){'_','_','w','i','n','e','_','S','v','c','c','t','l','S','t','a','r','t','e','d',0})
That's gcc-specific syntax, it would need some #ifdefs.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [Tools 5/6] winetest: Add statistics for the number of unit tests with errors or todos.
[...]
Would this do? :
diff --git a/winetest/gather b/winetest/gather
index 294ad06..fdacff5 100755
--- a/winetest/gather
+++ b/winetest/gather
@@ -362,7 +362,7 @@ EOF
pass;
my $count=!$report-{todos} ? $report-{errors} :
!$report-{errors} ? $report-{todos} :
- $group-{errors}+$group-{todos};
+ $report-{errors}+$report-{todos};
my $prcnt=!$report-{todos} ? percent($report-{errors}, $unit_count)
:
!$report-{errors} ? percent($report-{todos}, $unit_count)
:
Yes, this patch is correct. Please, submit it to wine-patches.
--
Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/
Cahn's Axiom: When all else fails, read the instructions.
Re: MinGW cross compilation fails for d3dx9_36/tests
On Fri, Mar 28, 2008 at 9:35 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: Agreed, the idea of using w32api is that we want to help improve mingw by finding problems in their headers and libraries, but if they are not going to accept our patches anyway, then there's clearly no point in continuing to make our life harder by using their stuff. Thank you! -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: [2/2] [try 2] Setupapi patch
Hi Alexander, Changelog: 1 - Creating device interface keys in registry as in Windows XP 2 - Creating DeviceInstance value in registry 3 - Creating SymbolicLink value in registry as in Windows XP 4 - SETUPDI_AddDeviceToSet: changing pointers on SP_DEVINFO_DATA after allocating new memory block for their array One fix per patch, please. --Juan
Re: MinGW cross compilation fails for d3dx9_36/tests
Alexandre Julliard wrote: John Klehm [EMAIL PROTECTED] writes: P.S. I logged some test results from my win2k machine, it seems they are at [5]. Seems like I missed some setting though as the date is not right. Advice on how to fix that would be delicious =) It's now using the git commit sha1 instead of a date when building from a git tree, that's a feature. I'm hoping we can standardize on that to make sure all test runs properly identify the exact source used. Wouldn't it be nicer to have something like: 0.9.58-06d429d6b6b6d63beaeda130a3bb261ef3b9fb41 Just a thought? The SHA's itself are not very pleasant for the eye. With the above you can at least group them visually. -- Cheers, Paul.
Re: Implement VBScript for Google Summer of Code
Hi Jim, I have this idea of implementing vbscript.dll for Google SoC. Any comment would be appreciated before I start working on my proposal. That sounds ambitious, but you're welcome to try! For a few years I used to hack VB, and I know the language and VBScript is just a cousin of VB. The runtime library is not big, and writing it shouldn't take too much time either. If you say so ;-) I think the hardest part would be to implement the COM interfaces that deal with scripting. And that's the area I know least about. The recently added jscript stubs are probably a decent place to start. Getting yourself familiar with COM is probably important to the success of your project. I'd recommend a copy of Don Box's Essential Com as the best way to get COM in a hurry. There are plenty of online references too, of course. One general point is that people often don't plan for the amount of time needed to get patches accepted--it's often more than people realize. You might start by trying to get a stub DLL for vbscript accepted, just to get the hang of the development process. Check out the git tree, build it, make some changes, commit to it, and send the patches in. You'll find instructions on how to do all that on the wiki. Looking forward to seeing your application. Good luck, --Juan
Re: MinGW cross compilation fails for d3dx9_36/tests
Paul Vriens [EMAIL PROTECTED] writes: Wouldn't it be nicer to have something like: 0.9.58-06d429d6b6b6d63beaeda130a3bb261ef3b9fb41 Just a thought? The SHA's itself are not very pleasant for the eye. With the above you can at least group them visually. Presentation issues should be separate from the actual id. Once all builds are using SHA1 we can do a lot of fancy stuff in how we display them. -- Alexandre Julliard [EMAIL PROTECTED]
Re: MinGW cross compilation fails for d3dx9_36/tests
Paul Vriens [EMAIL PROTECTED] writes: And can't we just start creating the winetest executable at winehq somewhere? We probably can, but how would this help? -- Alexandre Julliard [EMAIL PROTECTED]
Re: MinGW cross compilation fails for d3dx9_36/tests
Alexandre Julliard wrote: Paul Vriens [EMAIL PROTECTED] writes: And can't we just start creating the winetest executable at winehq somewhere? We probably can, but how would this help? It wouldn't help as we will face the same issues. It's just that it seems more logical to create this where multiple resources have access in case there are issues. We need a place where people can download the latest winetest executable and in the past it has been proven difficult to have it available all the time. Despite the excellent work that Paul Millar (and of course Hans and Stefan) is doing. So having this at winehq has nothing to do with fixing this particular issue. -- Cheers, Paul.
Re: [PATCH 3/7] services: Start a local RPC server.
Alexandre Julliard wrote:
Robert Shearman [EMAIL PROTECTED] writes:
+handle_t __RPC_USER MACHINE_HANDLEW_bind(MACHINE_HANDLEW MachineName)
+{
+WCHAR transport[] = SVCCTL_TRANSPORT;
+WCHAR endpoint[] = SVCCTL_ENDPOINT;
+LPWSTR server_copy = NULL;
+RPC_WSTR binding_str;
+RPC_STATUS status;
+handle_t rpc_handle;
+
+/* unlike Windows we start services.exe on demand. We start it always as
+ * checking if this is our address can be tricky */
+if (!check_services_exe())
+return NULL;
I think it would be OK to assume that services.exe is started by
wineboot and is always running, since we'll have at least the mountmgr
service running all the time.
I'm not sure that is a valid assumption, as we could have an option to
disable wineboot in the future due to performance reasons.
+/* Not the Windows event name - if needed the true one can be found in
Inside Windows */
+cpp_quote(#define SVCCTL_STARTED_EVENT (const
WCHAR[]){'_','_','w','i','n','e','_','S','v','c','c','t','l','S','t','a','r','t','e','d',0})
That's gcc-specific syntax, it would need some #ifdefs.
Well spotted. I'll fix that.
--
Rob Shearman
Re: amstream: IMediaStream::GetMultiMediaStream
Nikolay Sivov wrote:
@@ -109,9 +109,14 @@
{
IMediaStreamImpl *This = (IMediaStreamImpl *)iface;
-FIXME((%p/%p)-(%p) stub!\n, This, iface, ppMultiMediaStream);
+TRACE((%p/%p)-(%p)\n, This, iface, ppMultiMediaStream);
-return S_FALSE;
+if(!(*ppMultiMediaStream))
+return E_POINTER;
+
+*ppMultiMediaStream = This-Parent;
+
+return S_OK;
}
Although I haven't looked at the context, you also likely need to add a
reference to the returned COM object here.
--
Rob Shearman
Re: [PATCH 3/7] services: Start a local RPC server.
Robert Shearman [EMAIL PROTECTED] writes: I'm not sure that is a valid assumption, as we could have an option to disable wineboot in the future due to performance reasons. I don't think we want to support that. On the contrary, we want to move more of the startup processing that we currently do for every process into wineboot, so that it is done only once per session. This requires that we can guarantee that wineboot is always executed. We may of course make some of the more expensive parts of wineboot optional, but starting services.exe shouldn't be in the expensive category (and if it is that should be fixed). -- Alexandre Julliard [EMAIL PROTECTED]
Re: gdi32-related commit between 0.9.57-0.9.58broken .NET2/Systems.Windows.Forms
--- On Thu, 27/3/08, Dmitry Timoshkov [EMAIL PROTECTED] wrote: Vitaliy Margolen [EMAIL PROTECTED] wrote: Looks like a time to start blacklisting fonts then. If the font is invalid and does not work even on windows yet it is available in the system - that's the only thing Wine can do. Or just contact all distros to remove it. Or request packagers to refuse installing Wine if said font found in the system. Black listing the fonts is not an appropriate fix/workaround. There is already a fixed version of ukai.ttf, and a broken one was causing problems in a lot of native programs besides Wine. I think blacklisting is not a good approach - what one wants is really white-listing: given microsoft only ships a certain number of fonts, wine should provide emulation/substitutions of *only* those fonts fron known open-source alternatives, rather than expose the whole of fontconfig-available fonts to win32 applications. And applications should only expect to get those known MS fonts (or clones/substitutes). OTOH, ukai (or one of its Arphic derivative sibings) is fairly critical for most chinese-reading person :-). I am not sure There is a fixed version of ukai - from the codeweaver wiki and freedesktop's web site, I have the latest ukai release via redhat, and the wiki seems to suggests a non-debian mod older ukai to replace a debian-modified one. So my finger-pointing tendency would say that somehow a debian ukai modification which breaks gdiplus has got into freedesktop uptream... __ Sent from Yahoo! Mail. A Smarter Inbox http://uk.docs.yahoo.com/nowyoucan.html
SoC idea: enhance the Program Manager, winefile and friends
Hi All, From time to time the discussion comes up about having some sort of Window manager or explorer replacement for when running in Desktop mode. I don't know if a Win9x style desktop is really what we need for running in Desktop mode and after giving it a bit of thought, perhaps enhancing the program manager would be a better fit for us. Like perhaps if you start in Desktop mode then explorer would auto-magically start the program manager for you. I was also thinking that rather than using Windows 3.1 style group menus, we teach Program manager how to read shortcuts and directories in the start menu to use those as programs and program groups. Winefile could also use some loving as well and maybe we could come up with a better way to tie it in to the Program Manager. It seems to me that enhancing both of these programs should take a few months or work and fill out a SoC project nicely. Thoughts? -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: gdi32-related commit between 0.9.57-0.9.58broken .NET2/Systems.Windows.Forms
On Fri, Mar 28, 2008 at 11:12 AM, Hin-Tak Leung [EMAIL PROTECTED] wrote: I think blacklisting is not a good approach - what one wants is really white-listing: given microsoft only ships a certain number of fonts, wine should provide emulation/substitutions of *only* those fonts fron known open-source alternatives, rather than expose the whole of fontconfig-available fonts to win32 applications. And applications should only expect to get those known MS fonts (or clones/substitutes). Umm, I have friends who are font fanatics that have thousands of fonts installed on their system. If they can do that on Windows, they certainly should be able to do that on Linux. Are you suggesting we a) limit ourselves to only support what ships with Windows, and ignore all other fonts out there, or b) create a white list for every known font out there? OTOH, ukai (or one of its Arphic derivative sibings) is fairly critical for most chinese-reading person :-). I am not sure There is a fixed version of ukai - from the codeweaver wiki and freedesktop's web site, I have the latest ukai release via redhat, and the wiki seems to suggests a non-debian mod older ukai to replace a debian-modified one. So my finger-pointing tendency would say that somehow a debian ukai modification which breaks gdiplus has got into freedesktop uptream... AFAIK, the bad version of the ukai font is 20060928. It shiped with Ubuntu Feisty [1], Gutsy [2], and FC 8 [3]. Possibly with other distros as well, I have not done an exhaustive search. Just don't use that version and you should be fine. [1] http://packages.ubuntu.com/feisty/ttf-arphic-ukai [2] http://packages.ubuntu.com/gutsy/ttf-arphic-ukai [3] http://rpm.pbone.net/index.php3/stat/4/idpl/5312345/com/cjkunifonts-ukai-0.1.20060928-4.fc8.noarch.rpm.html
Re: MinGW cross compilation fails for d3dx9_36/tests
On 28/03/2008, Dmitry Timoshkov [EMAIL PROTECTED] wrote: John Klehm [EMAIL PROTECTED] wrote: The problem is that it is a mingw issue but they don't want any patches from wines win32 api in their mingw w32api. They believe that looking at the actual ms header files taints our headers legally speaking. Stefan, hans, and PaulM maintain a rather large set of patches against w32api. [1] So its a constant catchup game from when wines headers get new additions until someone sends paulm a patch updating the mingw w32api. Then perhaps we (Alexandre) should reconsider the stance about using Wine headers and import libraries in preference to mingw ones. I would have expected that when building for mingw, Wine would use the Wine headers and libraries. Otherwise, as mentioned above, if someone adds tests that rely on items that are not in the mingw headers then the tests will not be built for the conformance tests, as has been seen recently. Also, what happens with the widl generated headers? - Reece
Re: MinGW cross compilation fails for d3dx9_36/tests
On Fri, Mar 28, 2008 at 9:35 AM, Reece Dunn [EMAIL PROTECTED] wrote: I would have expected that when building for mingw, Wine would use the Wine headers and libraries. Otherwise, as mentioned above, if someone adds tests that rely on items that are not in the mingw headers then the tests will not be built for the conformance tests, as has been seen recently. Also, what happens with the widl generated headers? We have always depended on the w32api package for the tests and programs partly to make sure our own code is sane by having another coverage point like building with the MSVC headers when compiling on MSVC. Dmitry and I have disagreed with this for years though because the mingw w32api maintainers can be a real PITA about getting patches in and also because of the breakages that result when something is missing like you mention. Switching to a using the wine headers and import libs everywhere is long overdue and welcome! -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: MinGW cross compilation fails for d3dx9_36/tests
On Fri, Mar 28, 2008 at 1:53 PM, Steven Edwards [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 9:35 AM, Reece Dunn [EMAIL PROTECTED] wrote: I would have expected that when building for mingw, Wine would use the Wine headers and libraries. Otherwise, as mentioned above, if someone adds tests that rely on items that are not in the mingw headers then the tests will not be built for the conformance tests, as has been seen recently. Also, what happens with the widl generated headers? We have always depended on the w32api package for the tests and programs partly to make sure our own code is sane by having another coverage point like building with the MSVC headers when compiling on MSVC. Dmitry and I have disagreed with this for years though because the mingw w32api maintainers can be a real PITA about getting patches in and also because of the breakages that result when something is missing like you mention. Switching to a using the wine headers and import libs everywhere is long overdue and welcome! What is the process for making this switch? Do we need to contact Paul Millar? The lack of a new winetest is putting a hamper on our efforts to fix up the tests in Windows. -- James Hawkins
Re: Implement VBScript for Google Summer of Code
Hi Jim, 2008/3/27, Jim Chen [EMAIL PROTECTED]: Hi everyone, I have this idea of implementing vbscript.dll for Google SoC. Any comment would be appreciated before I start working on my proposal. The reason for implementing vbscript.dll is because right now there's nothing in the trunk about it. jscript.dll has a stub, but vbscript.dll doesn't, and it's an area that I think I can work on. VBScript is used by the Windows Installer, can be potentially be used for DirectMusic script (from http://wiki.winehq.org/DirectX-ToDo), and some applications use it. Just the core language/runtime (vbscript.dll) is implemented, no extra COM/OLE objects such as FSO (file system object), etc. (unless I have time). The language by itself is designed to be simple and easy, so an interpreter shouldn't be hard. I wrote a C-style script interpreter in Java this past year. For a few years I used to hack VB, and I know the language and VBScript is just a cousin of VB. The runtime library is not big, and writing it shouldn't take too much time either. I think the hardest part would be to implement the COM interfaces that deal with scripting. And that's the area I know least about. I don't know if you could do all of it in 3 months, what if it takes longer, would you still be interested in continuing work on it? COM isn't that hard, if you run into troubles with it a lot of wine developers know about it, and there are a lot of good com examples in the wine code. Cheers, Maarten.
Re: DLL exports... HELP?! (wine based win32 printer drivers for openprinting)
On Mi, 2008-03-26 at 14:47 +, Hin-Tak Leung wrote: Wow :-). I have almost wanted to suggest such a native wine-based printer driver as a linux foundation/openprinting GOSC project (I am one of the mentors under the openprinting umbrella https://www.linux-foundation.org/en/Google_Summer_of_Code). I am glad I didn't :-). I'm away for the weekend, but some quick notes: - The ddiwrapper-hack works only with a very small amount of self-contained drivers - Most Drivers today are plugins for the unidrv or the pscipt5 Driver (you can install pscript5 from Adobe since ~ 1/2 Year) - Drivers expect dlls, that are not present in wine-2005* (They will not load) - Rendering with full Drivers (Raster-Mode) need most Eng* Functions and Friends (This is the DIB-Engine). - Rendering with full Drivers (Postscript) need some Eng* Functions and Friends. Nothing in this Area is implemented / exported in current Wine: Driver will not load - Sending the rendered Data to the Printer need sometimes a vendor- specific Portmonitor / Languagemonitor (Not supported in current Wine) -- By by ... Detlef
Re: MinGW cross compilation fails for d3dx9_36/tests
On Fri, Mar 28, 2008 at 3:01 PM, James Hawkins [EMAIL PROTECTED] wrote: What is the process for making this switch? Do we need to contact Paul Millar? The lack of a new winetest is putting a hamper on our efforts to fix up the tests in Windows. There should just be a few rules that need to be changed as far as I know. Thats all that was needed for the programs case, I cannot Imagen why the tests would be any more complex. If Alexandre has not already done so, I'll look at it and submit patches tonight. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Implement VBScript for Google Summer of Code
Jim Chen wrote: Hi everyone, I have this idea of implementing vbscript.dll for Google SoC. Any comment would be appreciated before I start working on my proposal. It would be great to have vbscript.dll implemented in Wine and I hope that some day we will have it, but I think you underestimate amount of work on it. It's a much bigger task than the usual SoC projects, IMO. Please do some research before deciding to work on it. I've found Eric Lippert's blog very useful for information about active scripts http://blogs.msdn.com/ericlippert/default.aspx esp. the archive from 2004. If you'll decide to apply for this project, please describe it well enough so we know that you can accomplish it. Jacek
Re: mscoree: Add missing interfaces
Alistair Leslie-Hughes [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hi, Changelog: mscoree: Add missing interfaces Anything wrong with this patch? Best Regards Alistair Leslie-Hughes
Re: SoC idea: enhance the Program Manager, winefile and friends
From time to time the discussion comes up about having some sort of Window manager or explorer replacement for when running in Desktop mode. Personally, I think enhancing explorer to have its own GUI (rather than launching winefile) would be an interesting project. If nothing else, having a graphical way to explore the shell namespace might be handy for debugging shell issues. From there to an explorer for desktop mode might not be such a big leap. --Juan
Re: SoC idea: enhance the Program Manager, winefile and friends
Hasn't someone else somewhere in the world already written an explorer replacement and we could just get them to open source it so we can include it with Wine? No need to reinvent the wheel. -Brian On Fri, Mar 28, 2008 at 2:18 PM, Juan Lang [EMAIL PROTECTED] wrote: From time to time the discussion comes up about having some sort of Window manager or explorer replacement for when running in Desktop mode. Personally, I think enhancing explorer to have its own GUI (rather than launching winefile) would be an interesting project. If nothing else, having a graphical way to explore the shell namespace might be handy for debugging shell issues. From there to an explorer for desktop mode might not be such a big leap. --Juan
Re: SoC idea: enhance the Program Manager, winefile and friends
Hasn't someone else somewhere in the world already written an explorer replacement and we could just get them to open source it so we can include it with Wine? No need to reinvent the wheel. There's the ReactOS one, but it's written in C++. I don't know of any ANSI C ones, but maybe I haven't looked hard enough. --Juan
Re: SoC idea: enhance the Program Manager, winefile and friends
On Fri, Mar 28, 2008 at 3:40 PM, Juan Lang [EMAIL PROTECTED] wrote: Hasn't someone else somewhere in the world already written an explorer replacement and we could just get them to open source it so we can include it with Wine? No need to reinvent the wheel. There's the ReactOS one, but it's written in C++. I don't know of any ANSI C ones, but maybe I haven't looked hard enough. --Juan http://www.google.com/search?q=windows+explorer+replacementie=utf-8oe=utf-8aq=trls=org.mozilla:en-US:officialclient=firefox-a List of windows explorer replacements: http://gladiator-antivirus.com/forum/index.php?showtopic=50712pid=167091mode=threadedshow=st=; Here's direct links to a few I found: http://www.xyplorer.com/index.htm http://mustangpeak.net/ http://www.download32.com/directory-opus-i30453.html http://www.explorerxp.com/ http://www.discount-softwares.com/soft/Utility/File_Disk_Management/9079_universal_explorer.htm There's even an open source one (in visual basic though, bleh) http://sourceforge.net/projects/pc-viewer
Re: SoC idea: enhance the Program Manager, winefile and friends
http://www.google.com/search?q=windows+explorer+replacementie=utf-8oe=utf-8aq=trls=org.mozilla:en-US:officialclient=firefox-a Um.. yeah, I've heard of google, thanks. How many are written in ANSI C? Find me one of those, and I'll retract my suggestion as a SoC project. My suggestion is moot unless someone actually applies to do that though. --Juan
Re: wined3d: Improve detection of device palette change.
Am Freitag, 28. März 2008 20:34:11 schrieb Alexander Dorofeyev:
ENTER_GL();
+if (This-resource.format == WINED3DFMT_P8 || This-resource.format ==
WINED3DFMT_A8P8) {
+ for (i = 0; i This-baseTexture.levels; i++) {
+if(palette9_changed((IWineD3DSurfaceImpl *)This-surfaces[i])){
Why are you doing this inside ENTER_GL? I think LoadLocation locks on its own.
Re: MinGW cross compilation fails for d3dx9_36/tests
On Fri, Mar 28, 2008 at 2:22 PM, Steven Edwards [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 3:01 PM, James Hawkins [EMAIL PROTECTED] wrote: What is the process for making this switch? Do we need to contact Paul Millar? The lack of a new winetest is putting a hamper on our efforts to fix up the tests in Windows. There should just be a few rules that need to be changed as far as I know. Thats all that was needed for the programs case, I cannot Imagen why the tests would be any more complex. If Alexandre has not already done so, I'll look at it and submit patches tonight. Winetest with todays git [1] John [1] http://klehm.net/wine/20080328-winetest-438868f37796e387cd6f6db5da1f73a7017b6e00.exe
Re: wined3d: Improve detection of device palette change.
Hi.
I just put it nearby other somewhat related calls. This code doesn't really
need
ENTER_GL/LEAVE_GL, but there's a bigger problem that this ENTER_GL/LEAVE_GL in
PreLoad is around other routines too that mostly don't need it and leads to
ActivateContext being called inside it etc. I've already sent a patch to remove
ENTER_GL/LEAVE_GL in PreLoad, but it wasn't fully ok. I plan to fix and resend
the latter patch after issues are taken care of (a bit of lack of consistency
with holding / not-holding the lock in LoadLocation and its helper routines).
Stefan Dösinger wrote:
Am Freitag, 28. März 2008 20:34:11 schrieb Alexander Dorofeyev:
ENTER_GL();
+if (This-resource.format == WINED3DFMT_P8 || This-resource.format ==
WINED3DFMT_A8P8) {
+ for (i = 0; i This-baseTexture.levels; i++) {
+if(palette9_changed((IWineD3DSurfaceImpl *)This-surfaces[i])){
Why are you doing this inside ENTER_GL? I think LoadLocation locks on its own.
Re: winex11.drv: Don't add owned windows to the taskbar
Dmitry Timoshkov escribio': Alexander Dorofeyev [EMAIL PROTECTED] wrote: There's a regression in IDA Pro disassembler. Nothing is added to the taskbar at all, furthermore, when you are starting debugger, before there was a window appearing that asks pass control to the application or not. Now it's not appearing, and can't be found because there's nothing on the taskbar, which is pretty bad because the app doesn't respond to any other input at that moment. Minimizing the main window makes the app disappear altogether, so it's pretty unusable. The problem with IDA is that the button you see in the Windows task bar does not belong to the main IDA window, it belongs to a zero sized visible window with the same caption. Since it's zero sized Wine doesn't map it all. So, while formally it's a regression, technically it's not: main IDA window has never been added to the task bar before my patch. This all can be easily discovered with spy++ and a simple test app. This also affects many, if not all, VB6 applications (and possibly many Delphi applications). Personally, I consider this a rather serious regression and propose backing out of commit cb3ff54789c652b02d852f40db71cafd9fd67ca9 as a fix. BTW, this reminds me of bug 1598. If the explanation of the bug for IDA above is correct, then the buggy behavior of not assigning minimize/maximize buttons to the window that appears in the panel is sort of consistent with this regression. Maybe the behavior should be that visible windows owned by an invisible window should get mapped in the panel. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: wined3d: Improve detection of device palette change.
Am Freitag, 28. März 2008 22:37:32 schrieb Alexander Dorofeyev: Hi. I just put it nearby other somewhat related calls. This code doesn't really need ENTER_GL/LEAVE_GL, but there's a bigger problem that this ENTER_GL/LEAVE_GL in PreLoad is around other routines too that mostly don't need it and leads to ActivateContext being called inside it etc. I've already sent a patch to remove ENTER_GL/LEAVE_GL in PreLoad, but it wasn't fully ok. I plan to fix and resend the latter patch after issues are taken care of (a bit of lack of consistency with holding / not-holding the lock in LoadLocation and its helper routines). Ok, I am fine with this patch if the ENTER_GL/LEAVE_GL stuff needs a different fix anyway
[Fwd: gdi32: PlgBlt implementation (resend)]
What about this patch?
Changelog (since first patch):
- HAVE_FLOAT_H used for #include
- all declarations moved to the beginning
Index: dlls/gdi32/bitblt.c
===
RCS file: /home/wine/wine/dlls/gdi32/bitblt.c,v
retrieving revision 1.4
diff -u -r1.4 bitblt.c
--- dlls/gdi32/bitblt.c 18 Sep 2007 10:32:56 - 1.4
+++ dlls/gdi32/bitblt.c 26 Mar 2008 22:48:50 -
@@ -20,6 +20,11 @@
#include stdarg.h
+#include math.h
+#if defined(HAVE_FLOAT_H)
+#include float.h
+#endif
+
#include windef.h
#include winbase.h
#include wingdi.h
@@ -522,9 +527,75 @@
*
*/
BOOL WINAPI PlgBlt( HDC hdcDest, const POINT *lpPoint,
-HDC hdcSrc, INT nXDest, INT nYDest, INT nWidth,
+HDC hdcSrc, INT nXSrc, INT nYSrc, INT nWidth,
INT nHeight, HBITMAP hbmMask, INT xMask, INT yMask)
{
-FIXME(PlgBlt, stub\n);
-return 1;
+int oldgMode;
+/* parallelogram coords */
+POINT plg[3];
+/* rect coords */
+POINT rect[3];
+XFORM xf;
+XFORM SrcXf;
+XFORM oldDestXf;
+FLOAT det;
+
+/* save actual mode, set GM_ADVANCED */
+oldgMode = SetGraphicsMode(hdcDest,GM_ADVANCED);
+if (oldgMode == 0)
+return FALSE;
+
+memcpy(plg,lpPoint,sizeof(POINT)*3);
+rect[0].x = nXSrc;
+rect[0].y = nYSrc;
+rect[1].x = nXSrc + nWidth;
+rect[1].y = nYSrc;
+rect[2].x = nXSrc;
+rect[2].y = nYSrc + nHeight;
+/* calc XFORM matrix to transform hdcDest - hdcSrc (parallelogram to
rectangle) */
+/* determinant */
+det = (FLOAT)(rect[1].x*(rect[2].y - rect[0].y) - rect[2].x*(rect[1].y -
rect[0].y) - rect[0].x*(rect[2].y - rect[1].y));
+
+if (fabs(det) FLT_EPSILON)
+{
+SetGraphicsMode(hdcDest,oldgMode);
+return FALSE;
+}
+
+TRACE(hdcSrc=%p %d,%d,%dx%d - hdcDest=%p %d,%d,%d,%d,%d,%d\n,
+hdcSrc, nXSrc, nYSrc, nWidth, nHeight, hdcDest, plg[0].x, plg[0].y,
plg[1].x, plg[1].y, plg[2].x, plg[2].y);
+
+/* X components */
+xf.eM11 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y -
rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det;
+xf.eM21 = (rect[1].x*(plg[2].x - plg[0].x) - rect[2].x*(plg[1].x -
plg[0].x) - rect[0].x*(plg[2].x - plg[1].x)) / det;
+xf.eDx = (rect[0].x*(rect[1].y*plg[2].x - rect[2].y*plg[1].x) -
+ rect[1].x*(rect[0].y*plg[2].x - rect[2].y*plg[0].x) +
+ rect[2].x*(rect[0].y*plg[1].x - rect[1].y*plg[0].x)
+ ) / det;
+
+/* Y components */
+xf.eM12 = (plg[1].y*(rect[2].y - rect[0].y) - plg[2].y*(rect[1].y -
rect[0].y) - plg[0].y*(rect[2].y - rect[1].y)) / det;
+xf.eM22 = (plg[1].x*(rect[2].y - rect[0].y) - plg[2].x*(rect[1].y -
rect[0].y) - plg[0].x*(rect[2].y - rect[1].y)) / det;
+xf.eDy = (rect[0].x*(rect[1].y*plg[2].y - rect[2].y*plg[1].y) -
+ rect[1].x*(rect[0].y*plg[2].y - rect[2].y*plg[0].y) +
+ rect[2].x*(rect[0].y*plg[1].y - rect[1].y*plg[0].y)
+ ) / det;
+
+GetWorldTransform(hdcSrc,SrcXf);
+CombineTransform(xf,xf,SrcXf);
+
+/* save actual dest transform */
+GetWorldTransform(hdcDest,oldDestXf);
+
+SetWorldTransform(hdcDest,xf);
+/* now destination and source DCs use same coords */
+MaskBlt(hdcDest,nXSrc,nYSrc,nWidth,nHeight,
+hdcSrc, nXSrc,nYSrc,
+hbmMask,xMask,yMask,
+SRCCOPY);
+/* restore dest DC */
+SetWorldTransform(hdcDest,oldDestXf);
+SetGraphicsMode(hdcDest,oldgMode);
+
+return TRUE;
}
Re: Implement VBScript for Google Summer of Code
On Fri, Mar 28, 2008 at 3:08 PM, Maarten Lankhorst [EMAIL PROTECTED] wrote: Hi Jim, 2008/3/27, Jim Chen [EMAIL PROTECTED]: Hi everyone, I have this idea of implementing vbscript.dll for Google SoC. Any comment would be appreciated before I start working on my proposal. The reason for implementing vbscript.dll is because right now there's nothing in the trunk about it. jscript.dll has a stub, but vbscript.dll doesn't, and it's an area that I think I can work on. VBScript is used by the Windows Installer, can be potentially be used for DirectMusic script (from http://wiki.winehq.org/DirectX-ToDo), and some applications use it. Just the core language/runtime (vbscript.dll) is implemented, no extra COM/OLE objects such as FSO (file system object), etc. (unless I have time). The language by itself is designed to be simple and easy, so an interpreter shouldn't be hard. I wrote a C-style script interpreter in Java this past year. For a few years I used to hack VB, and I know the language and VBScript is just a cousin of VB. The runtime library is not big, and writing it shouldn't take too much time either. I think the hardest part would be to implement the COM interfaces that deal with scripting. And that's the area I know least about. I don't know if you could do all of it in 3 months, what if it takes longer, would you still be interested in continuing work on it? COM isn't that hard, if you run into troubles with it a lot of wine developers know about it, and there are a lot of good com examples in the wine code. Cheers, Maarten. Of course, if I end up doing it I will finish it till it's done. Isn't that one of GSoC's purposes, to stay involved even after the program ends? But obviously I still need to accomplish things during the program so that's why I'm still doing research on it, to see how much time I might need to get at least something done. I'm OK with the basic COM stuff. IUnknown doesn't scar e me :) But for more advanced stuff, I'm sure I'll need to ask around. Thanks! Jim
Re: Implement VBScript for Google Summer of Code
On Fri, Mar 28, 2008 at 4:11 PM, Jacek Caban [EMAIL PROTECTED] wrote: Jim Chen wrote: Hi everyone, I have this idea of implementing vbscript.dll for Google SoC. Any comment would be appreciated before I start working on my proposal. It would be great to have vbscript.dll implemented in Wine and I hope that some day we will have it, but I think you underestimate amount of work on it. It's a much bigger task than the usual SoC projects, IMO. Please do some research before deciding to work on it. I've found Eric Lippert's blog very useful for information about active scripts http://blogs.msdn.com/ericlippert/default.aspx esp. the archive from 2004. If you'll decide to apply for this project, please describe it well enough so we know that you can accomplish it. Jacek Wow thanks for the link! Surprisingly useful (for something from MS :D) I've been doing research and I understand it will be a huge effort. I've already applied to the windowless Rich Edit project, which will most likely be easier than this, but I think this one will be more exciting because it's more challenging :) I'm more than willing to continue after SoC if I end up working on it. I don't have to implement the newest version either, with support for classes, etc. If I just implement VBScript say up to 2.0 that's within reach, I think. Thanks again! Jim
Re: SoC idea: enhance the Program Manager, winefile and friends
Hey Juan! On Fri, Mar 28, 2008 at 4:18 PM, Juan Lang [EMAIL PROTECTED] wrote: Personally, I think enhancing explorer to have its own GUI (rather than launching winefile) would be an interesting project. If nothing else, having a graphical way to explore the shell namespace might be handy for debugging shell issues. From there to an explorer for desktop mode might not be such a big leap. Enhancing our explorer to be a full explorer replacement would be cool with me too, there were just a few reasons I suggested using Program Manager and Winefile rather than trying to extend explorer for the UI 1. Its kind of massive and I don't think we need all of that for desktop mode. I view desktop mode as kind of a corner case that only should be used like 5% of the time. 2. We have winefile and the Program Manager already and both are in really bad shape. They have for the most part bit-rotted in the tree for as long as I can remember. It would be nice to see them polished for Wine 1.0 3. This is just my taste but I don't really like having a Window style explorer bar running in a window. It would make Wine feel more like a VM like environment to me. Maybe we want that for Desktop mode to further try to discourage users from running it, like case 1. I'd like to see when Desktop mode is invoked, a working Program Manager launch that already has program groups for all of the installed Shortcuts plus existing Winelib applications we ship in the tree. Perhaps even a My Computer group minimized with support for the Shell Namespace builtin and or support for launching winefile with shellnamespace support. I know its a bit of a departure from the normal Windows UI and some may even say using the Program Manager like that is a throwback to Windows 3.1 but it just seems like it would flow better from a UI perspective. Plus it would leverage the code we already have in tree. All of that being said I don't know if I could mentor such a project anyway, just throwing out ideas. As with everything it really comes down to what Julliard wants. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: MinGW cross compilation fails for d3dx9_36/tests
On Fri, Mar 28, 2008 at 3:22 PM, Steven Edwards [EMAIL PROTECTED] wrote: There should just be a few rules that need to be changed as far as I know. Thats all that was needed for the programs case, I cannot Imagen why the tests would be any more complex. If Alexandre has not already done so, I'll look at it and submit patches tonight. The rules for building the import libs has changed quite a bit since the last time I looked at them and I am not quite sure about how to fix a couple of problems so I'll wait for Alexandre to comment. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
