Direct3D shader compiler infrastructure
Hello,
So, I am getting serious about a shader compiler and related things now, and
I've made a design proposal.
First of all, let us collect a few things we want regarding shader handling:
- D3DXCompileShader Friends
- D3DXAssembleShader Friends
- D3DXDisassembleShader Friends
- A way to deal with d3d9 and d3d10 shader language differences
All these items are related in some way, so I am proposing the following
design of a shader library:
The core part of the library is a wine internal shader language representing
D3D assembler shaders. Shaders in this language can be created from D3D
Bytecode(SlDisassembleShader), D3D ASM(SlAssembleShader) and from
HLSL(SlCompileShader). From the intermediate language, D3D bytecode can be
generated in various versions(SlGenBytecode), as well as D3D Text
asm(SlGenAsm). Unlike regular D3D asm languages, this language does not have
a version token, it is a superset of all asm language versions. It does have
a pixel / vertex / geometry shader flag though.
The motivation behind an intermediate language is to avoid writing many
different code generators, which is a big part of the HLSL compiler. We also
need a WineD3D intermediate language to share our shader generator between
d3d9 and d3d10, and use it for both kinds of shaders. The requirements for
both intermediate asm languages are the same. This motivates making the
language the same to reuse code.
With those functions, the D3DX functions are pretty streightforward:
D3DXAssembleShader:
bytecode = SlGenBytecode(SlAssembleShader(char *asm_text));
D3DXCompileShader:
bytecode = SlGenBytecode(SlCompileShader(char *hlsl_text));
D3DXDisassembleShader
asm_text = SlGenAsm(SlDisassembleShader(DWORD *bytecode));
WineD3D can be changed to use this shader language as shader input. In this
case, d3d8, d3d9 and d3d10 run their shader bytecode through
SlDisassembleShader, and pass the returned pointer to WineD3D. This in turn
calls SlCopyShader to make a copy it owns, and d3d8/9/10 free their copy
using SlDestroyShader.
With WineD3D working on the same language, we have to share the language
definition between the shader library and WineD3D, or put the shader compiler
into WineD3D as well. I do not like the 2nd way, as it puts things together
that don't have to be in one lib, and wastes runtime memory. A 3rd way I have
to consider was a SlReadShader() function with callbacks which takes over the
current role of shader_generate_main() in WineD3D. I am not quite convinced
by this either.
Attached are a few files for reference:
shaderlib.gif: A diagram explaining the roles of the languages(No, it is not
UML 2.0)
uses.gif: Illustrating various uses of the shader library
shader-lang: A very early pseudocode definition of the language
The intermediate asm language follows the same principles as D3D bytecode. A
shader contains any number of instructions, each instruction has one
destination register and any number of source registers. The instructions
have an opcode, writemask, modifiers. A register has a type, an index,
information about relative addressing, source modifiers, and a swizzle.
Appart of the instructions, the shader contains a header with informations
about the shader. Declarations, input/output semantics, special registers
used, etc. This replaces the shader_get_registers_used() pass in WineD3D. It
is done by the shader library, and it also generates the declarations for 1.x
pixel shaders. (We still have to find out which texture type to read from in
wined3d).
Thanks,
Stefan
attachment: shaderlib.gifstruct varying {
int reg;
/* Could be replaced with a string for dx10 */
DWORD usage;
DWORD usageidx;
}
struct asm_shader_header {
enum shader_type; /* vertex, pixel, geom */
struct constantF *constF; /* Local constants */
struct constantI *constI;
struct constantB *constB;
struct varying *input; /* Input varyings ps/vs */
struct varying *output; /* Output varyings vs */
BOOL vPos, vFace; /* special regs */
struct instruction *instr; /* shader instructions */
}
struct instruction {
DWORD opcode;
DWORD writemask;
DWORD dstmod;
struct register dst;
struct register *srcs;
}
struct register {
DWORD type;
DWORD idx;
struct *rel_reg;
DWORD srcmod;
}
attachment: uses.gif
Re: Direct3D shader compiler infrastructure
On 31/03/2008, Stefan Dösinger [EMAIL PROTECTED] wrote: With WineD3D working on the same language, we have to share the language definition between the shader library and WineD3D, or put the shader compiler into WineD3D as well. I do not like the 2nd way, as it puts things together that don't have to be in one lib, and wastes runtime memory. A 3rd way I have to consider was a SlReadShader() function with callbacks which takes over the current role of shader_generate_main() in WineD3D. I am not quite convinced by this either. Looks reasonable enough in general. I guess it would make sense to create some kind of shader utilities library that can be used from both wined3d and d3d9x. You could in principle even move GLSL/ARB code generation in there, although that isn't required of course.
Re: midl question
Hi Rob, What work would need to be done to get widl to support __stdcall? Best Regards Alistair Leslie-Hughes
Re: user32: Implement BroadcastSystemMessage, try 5.1
Vitaliy Margolen [EMAIL PROTECTED] writes: I remember sending the patch for this exact thing a while back, which you of course refused under the same pretense - showing a real life app that depends on it. So if tests are not a real life app that shows a difference between Wine and windows - then why do we bother with Wine at all? At least should change the moto to might run some apps with loads of problems and never be 100% compatible. One for sure will find an app that in one way or another depends on undocumented windows behavior. So if a test can be written to show a difference between Wine and windows. Then this difference should be fixed in Wine. It all comes down to where we want to spend our efforts. It's very easy to write a million last error tests, and then we'd have to spend months fixing Wine by adding save/restore of last error all over the place, for no benefit at all. Our time is much better spent fixing things that actually matter, and not making the code uglier for things that don't. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Proposal: versioning .wine directory
On Mon, Mar 31, 2008 at 2:44 AM, Alexandre Julliard [EMAIL PROTECTED] wrote: I think we should stop telling people to blow away their .wine, and have them run wineprefixcreate instead. Then if wineprefixcreate doesn't do the update correctly we need to figure out why and fix it. Once we are confident that it can do the update safely we can have it run automatically when it detects an upgrade. Roger.
Re: Proposal: versioning .wine directory
James Hawkins [EMAIL PROTECTED] writes: If we have a stable wine prefix in 1.0, I don't see what could possibly be added in 1.2 that would break that. The idea is that, even if you add a new dll that needs to be registered in, say, 1.0.5, you still don't need to remove your wine prefix or reinstall any apps. That should already be the case, there's nothing magical about 1.0 that would suddenly cause that to happen. And if there are cases where it doesn't work we have to fix them before 1.0 is out. I think we should stop telling people to blow away their .wine, and have them run wineprefixcreate instead. Then if wineprefixcreate doesn't do the update correctly we need to figure out why and fix it. Once we are confident that it can do the update safely we can have it run automatically when it detects an upgrade. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [1/2] WineD3D: Support clipplanes with GLSL shaders
Stefan Dösinger [EMAIL PROTECTED] writes: From 1cb24469eb0f53f7e67dea2c7659ad070b86f21d Mon Sep 17 00:00:00 2001 From: Stefan Doesinger [EMAIL PROTECTED] Date: Fri, 28 Mar 2008 16:11:06 +0100 Subject: [PATCH] WineD3D: Support clipplanes with GLSL shaders This patch removes the shader clipplane disabling code from the common/fixed function state table and enables GLSL shaders to write to the clipcoord output attribute. The ARB specific clipplane disabling is handled in the ARB shader backend. It doesn't work for me: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c touch visual.ok visual.c:4738: Test failed: vs_3_0 returned color 0x0011, expected 0x00203366 visual.c:4743: Test failed: vs_1_1 returned color 0x0011, expected 0x00808080 visual.c:4748: Test failed: vs_2_0 returned color 0x0011, expected 0x visual.c:4929: Test failed: ps_3_0 returned color 0x00193300, expected 0x0080ffe5 make[2]: *** [visual.ok] Error 4 -- Alexandre Julliard [EMAIL PROTECTED]
Re: Direct3D shader compiler infrastructure
Am Montag, 31. März 2008 08:54:18 schrieb H. Verbeet: On 31/03/2008, Stefan Dösinger [EMAIL PROTECTED] wrote: With WineD3D working on the same language, we have to share the language definition between the shader library and WineD3D, or put the shader compiler into WineD3D as well. I do not like the 2nd way, as it puts things together that don't have to be in one lib, and wastes runtime memory. A 3rd way I have to consider was a SlReadShader() function with callbacks which takes over the current role of shader_generate_main() in WineD3D. I am not quite convinced by this either. Looks reasonable enough in general. I guess it would make sense to create some kind of shader utilities library that can be used from both wined3d and d3d9x. Right, that is my plan. Although I am not sure yet in which way wined3d would use it. It might be best off by just parsing the asm tree itself. You could in principle even move GLSL/ARB code generation in there, although that isn't required of course. Not really, because the GLSL/ARB code generator doesn't compile shaders, it configures the GL pipeline. As such, it depends on many other things like the textures that are bound, the vertex declaration, etc.
Firefox 3 beta 4 working, only a couple bugs...
I tried Firefox 3 beta 4 just now, and there were a few bugs that stood out in the first few minutes: 12305 Firefox 3 beta 4 font problem: colon displayed as 0038 unicode glyph-missing glyph 12306 Firefox 3 beta shows one-pixel-high black line when rendering some images 12307 firefox 3 beta 4 crash on some web pages Youtube seemed slow and hangy on the first video I tried, http://www.youtube.com/watch?v=jwMj3PJDxuo although it was fine in native firefox at the same time; perhaps the Windows version of the flash plugin is less resistant to network errors -- or Wine doesn't support some network feature that only matters during bad internet weather. That same video was fine later, as was a different video http://www.youtube.com/watch?v=OGxdgNJ_lZM (both worth watching, btw). It also output quite a few messages like fixme:ntdll:NtLockFile I/O completion on lock not implemented yet fixme:font:ExtTextOutW flags ETO_NUMERICSLOCAL | ETO_NUMERICSLATIN | ETO_PDY unimplemented Firefox 3 rc1 will be out in May, and release will be in early June, according to http://blog.wired.com/monkeybites/2008/03/mozilla-final-v.html Given that a lot of people have in the past used windows Firefox in wine to run native plugins, maybe we should get firefox 3 working well. Probably only five or six main issues. - Dan
Re: Direct3D shader compiler infrastructure
On 31/03/2008, Stefan Dösinger [EMAIL PROTECTED] wrote: Am Montag, 31. März 2008 08:54:18 schrieb H. Verbeet: Looks reasonable enough in general. I guess it would make sense to create some kind of shader utilities library that can be used from both wined3d and d3d9x. Right, that is my plan. Although I am not sure yet in which way wined3d would use it. It might be best off by just parsing the asm tree itself. Our current intermediate representation is essentially a list of SHADER_OPCODE and SHADER_OPCODE_ARG elements. We probably want to move the bytecode parsing into the shader library and then generalize the intermediate representation a bit. It would also mean separating parsing and code generation a bit more than it currently is. You could in principle even move GLSL/ARB code generation in there, although that isn't required of course. Not really, because the GLSL/ARB code generator doesn't compile shaders, it configures the GL pipeline. As such, it depends on many other things like the textures that are bound, the vertex declaration, etc. It doesn't compile the shaders, but it certainly generates shader source. I'm not sure what it does in terms of configuring GL state? Wrt state like vertex declarations, bound textures etc, there's no reason we can't pass that to the code generator (and it's probably a good idea to pass that state a bit more explicitly anyway). At this point there isn't a real reason to move shader code generation into this library, but it should certainly be possible.
Re: Direct3D shader compiler infrastructure
Am Montag, 31. März 2008 13:17:49 schrieb H. Verbeet: Our current intermediate representation is essentially a list of SHADER_OPCODE and SHADER_OPCODE_ARG elements. We probably want to move the bytecode parsing into the shader library and then generalize the intermediate representation a bit. It would also mean separating parsing and code generation a bit more than it currently is. Yes, this is my idea. It doesn't compile the shaders, but it certainly generates shader source. I'm not sure what it does in terms of configuring GL state? Wrt state like vertex declarations, bound textures etc, there's no reason we can't pass that to the code generator (and it's probably a good idea to pass that state a bit more explicitly anyway). At this point there isn't a real reason to move shader code generation into this library, but it should certainly be possible. You're right, we could just pass the GL state to the shader lib. Generating a shader with ATI_fragment_shader or NV_texture_shader requires opengl calls though, so I don't think it is desireable to move that to the shader utility lib. How do we call this library? wineshader.dll?
Re: Direct3D shader compiler infrastructure
Am Montag, 31. März 2008 13:17:49 schrieb H. Verbeet: Our current intermediate representation is essentially a list of SHADER_OPCODE and SHADER_OPCODE_ARG elements. We probably want to move the bytecode parsing into the shader library and then generalize the intermediate representation a bit. It would also mean separating parsing and code generation a bit more than it currently is. Yes, this is my idea. It doesn't compile the shaders, but it certainly generates shader source. I'm not sure what it does in terms of configuring GL state? Wrt state like vertex declarations, bound textures etc, there's no reason we can't pass that to the code generator (and it's probably a good idea to pass that state a bit more explicitly anyway). At this point there isn't a real reason to move shader code generation into this library, but it should certainly be possible. You're right, we could just pass the GL state to the shader lib. Generating a shader with ATI_fragment_shader or NV_texture_shader requires opengl calls though, so I don't think it is desireable to move that to the shader utility lib. How do we call this library? wineshader.dll?
Re: Direct3D shader compiler infrastructure
On 31/03/2008, Stefan Dösinger [EMAIL PROTECTED] wrote: How do we call this library? wineshader.dll? Sounds ok to me.
Some considerations about the Wine FUSE project for GSoC
Hi folks, after another chat about Wine's goals in respect to FUSE file systems on IRC, I just wanted to point the students who applied for this project already (I've Bcced them) at the goals Wine has for this GSoC project. For Wine, the goal is to create prototype FUSE file systems so we can figure out if this approach is useful to Wine at all. There is no immediate goal to include the file systems into Wine in the near future, we first want to know if they're what we need. I think it's important to be clear and outspoken about this so nobody starts working on this under the wrong assumptions. Cheers, 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: user32: Implement BroadcastSystemMessage, try 5.1
Alexandre Julliard wrote: Vitaliy Margolen [EMAIL PROTECTED] writes: I remember sending the patch for this exact thing a while back, which you of course refused under the same pretense - showing a real life app that depends on it. So if tests are not a real life app that shows a difference between Wine and windows - then why do we bother with Wine at all? At least should change the moto to might run some apps with loads of problems and never be 100% compatible. One for sure will find an app that in one way or another depends on undocumented windows behavior. So if a test can be written to show a difference between Wine and windows. Then this difference should be fixed in Wine. It all comes down to where we want to spend our efforts. It's very easy to write a million last error tests, and then we'd have to spend months fixing Wine by adding save/restore of last error all over the place, for no benefit at all. Our time is much better spent fixing things that actually matter, and not making the code uglier for things that don't. But that's the thing. How can you definitively say that there isn't a program that affected by this? And this sort of difference might affect number of programs in a ways that really hard to catch. Vitaliy.
Re: midl question
Alistair Leslie-Hughes wrote: Hi Rob, What work would need to be done to get widl to support __stdcall? The issue is that widl doesn't support functions in typedefs. Further issues are that widl doesn't support writing out the function typedef once parsed and widl doesn't store the calling convention for the function and so it currently can't be written out correctly. -- Rob Shearman
Re: user32: Implement BroadcastSystemMessage, try 5.1
Vitaliy Margolen [EMAIL PROTECTED] writes: But that's the thing. How can you definitively say that there isn't a program that affected by this? Of course you can never be certain, but after having debugged a number of apps, and checked the behavior of APIs across Windows versions, there are things that you know do matter, and things that don't; and the last error behavior on success is definitely in the latter category. Yes, I'm sure someone someday can find a case where some specific app depends on some specific function to handle last error in a different way; but there's no reason to believe that BroadcastSystemMessage is more likely to trigger that bug than any other of the 10,000 functions that touch last error. So we either wait until we find an app that depends on this and fix the one offending function, or we spend months adding ugly code to every single API; adding the ugly code to only a handful of randomly chosen functions doesn't make any sense. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Some considerations about the Wine FUSE project for GSoC
Kai Blin wrote: Hi folks, after another chat about Wine's goals in respect to FUSE file systems on IRC, I just wanted to point the students who applied for this project already (I've Bcced them) at the goals Wine has for this GSoC project. For Wine, the goal is to create prototype FUSE file systems so we can figure out if this approach is useful to Wine at all. There is no immediate goal to include the file systems into Wine in the near future, we first want to know if they're what we need. First, I haven't yet applied for the project mainly because i will probably not be able to work full time on a GSoC project due to real life issues (part time job, family related things etc). On the other hand I doubt that it will require ~3 months to implement, I have done my prototype over more or less a weekend. I miss the technical discussion on how the problem should be solved. I think the idea of keeping the original filename in an extended attribute and storing everything in lower case is a pretty good one. Andrew Tridgell also listed it on one of his slides from WineConf05 [1]. I prototyped something and thought this way I would at least get some feedback (after all Talk is cheap. Show me the code. is common practice in the open source world). But this wasn't really the case, so i am still wondering what should be done differently? Regards, Marc [1]http://us5.samba.org/samba/ftp/slides/tridge_wineconf05.pdf (page 18) -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Re: [PATCH 2/2] winex11drv: Distinguish left and right keys for shift, ctrl and alt. (try 5)
Vitaliy [EMAIL PROTECTED] writes: Resending. Try 5: Split out change to user32 as a separate patch. Try 4: This time with lots of tests that exposed number of other problems that were fixed. I could not separate this patch into separate pieces - they all linked together and fixing one problem meant fixing or breaking something else. The message tests don't work: ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so input.c touch input.ok input.c:755: Test failed: a2/2: the msg sequence is not complete: expected - actual 000f make: *** [input.ok] Error 1 You most likely need to ignore all non-key messages. -- Alexandre Julliard [EMAIL PROTECTED]
Re: GdipGraphicsClear function implementation and tests
Gynvael Coldwind [EMAIL PROTECTED] writes: +/* get width and height + */ +width = GetDeviceCaps(graphics-hdc, HORZRES); +height = GetDeviceCaps(graphics-hdc, VERTRES); This won't do what you want. You should probably use something like GetClipBox() here. -- Alexandre Julliard [EMAIL PROTECTED]
Re: shell32: implement SHGetFolderPathAndSubDirA/W [2nd resend]
Stefan Leichter [EMAIL PROTECTED] writes:
+if (pszSubPath (length = MultiByteToWideChar(CP_ACP, 0, pszSubPath,
-1, NULL, 0))) {
+pszSubPathW = HeapAlloc(GetProcessHeap(), 0, length * sizeof(WCHAR));
+if(!pszSubPathW)
+return HRESULT_FROM_WIN32(ERROR_NOT_ENOUGH_MEMORY);
You are leaking memory on error. Also I don't think it makes sense to
test the return value of MultiByteToWideChar, it shouldn't fail in this
case (or if you test it, then you need to handle the error properly, not
use an empty path instead).
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Some considerations about the Wine FUSE project for GSoC
On Monday 31 March 2008 15:30:17 Marc Andre Tanner wrote: First, I haven't yet applied for the project mainly because i will probably not be able to work full time on a GSoC project due to real life issues (part time job, family related things etc). On the other hand I doubt that it will require ~3 months to implement, I have done my prototype over more or less a weekend. That's why there's more than one FUSE file systems on the list ;) I miss the technical discussion on how the problem should be solved. I think the idea of keeping the original filename in an extended attribute and storing everything in lower case is a pretty good one. Andrew Tridgell also listed it on one of his slides from WineConf05 [1]. The tricky part is convincing Alexandre Julliard, as always when working on Wine. I prototyped something and thought this way I would at least get some feedback (after all Talk is cheap. Show me the code. is common practice in the open source world). But this wasn't really the case, so i am still wondering what should be done differently? Whoops, I didn't see that url. Sorry, but things were a bit busy recently. I'll give that a whirl later today. Cheers, 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: winex11.drv: Don't add owned windows to the taskbar
Dmitry Timoshkov escribió: Alex Villacís Lasso [EMAIL PROTECTED] wrote: 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. 1598 is closed as fixed, and I have no idea how missing minimize/maximize buttons are related to owned windows, and why you think that it's somehow related to the visibility of an owner. What you need to be fixed is making a zero sized window with WS_VISIBLE style set mapped, but X11/WMs doesn't handle that gracefully. Bug 1598 (even if closed and fixed) is relevant because it was also triggered by having an invisible owner window, as my own analysis in comment #16 suggested. This bug (1598) also made the window button disappear from the taskbar, with the same application that now exhibited the regression. I was just preparing a patch to fix this very issue over the weekend, but it seems Jacek Caban beat me to it. I am currently recompiling my tree to test the patch. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: setupapi: prevent page faults in SetupDiDeleteDeviceInterfaceRegKey
[EMAIL PROTECTED] wrote: Message: 4 Date: Sun, 30 Mar 2008 19:13:46 -0600 From: Vitaliy Margolen [EMAIL PROTECTED] Subject: Re: setupapi: prevent page faults in SetupDiDeleteDeviceInterfaceRegKey To: wine-devel@winehq.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Christopher wrote: Changelog: Check that the handle and pointer passed to SetupDiDeleteDeviceInterfaceRegKey are valid to read from. This patch continues to address bug #12242 -if (!DeviceInterfaceData || +if (!DeviceInterfaceData || IsBadReadPtr(DeviceInterfaceData, sizeof(SP_DEVICE_INTERFACE_DATA)) || Don't ever use IsBadReadPtr and IsBadWritePtr functions. They are bad and even MS stopped using them. You have to use TRY-EXCEPT block around an access to the memory. For example see implementation of lstrcpyA (kernel32/string.c: 359). +ok(!ret GetLastError() == ERROR_INVALID_HANDLE, Expected SetupDiDeleteDeviceInterfaceRegKey to return FALSE, got %s, \ +with error code: 6, got %d\n, ret ? TRUE : FALSE, GetLastError()); This is bad way to split strings in c. Do something like this: ok(!ret GetLastError() == ERROR_INVALID_HANDLE, Expected SetupDiDeleteDeviceInterfaceRegKey to return FALSE, got %s, with error code: 6, got %d\n, ret ? TRUE : FALSE, GetLastError()); Vitaliy. Thanks for the comments! I found that Alexander Morozov's patches fix the same issue my patch was aimed at. After his are committed, I'll fix and resubmit mine if it's needed. Christopher Berner
News about iPod Sync and iTunes?
Hi are there any news / patrches on the iPod sync with iTunes? Thanks Rainer
translation
do u need an italian translator for your wiki/documentation? i can do it properly. u doin very nice job. thanks from a satisfied user. bye -- ¤ acM ¤ Lorenzo M
Control-panel app. Works with mingw, need help with winegcc
Okay, this is as far as apparently I can make it on my own. This is the *basic* control panel applet. I used Dev-c++ (it's C though). It compiles with mingw and works flawlessly - you know, exports what it should export etc. etc. etc. The result, copied onto c:\windows\system32 shows up in the control panel and launches Notepad. However, I can't for the life of me get it to compile with winegcc (skip the usual throw out inlude windows.h and insert cpl.h... THEN it gets hairier). Help? skeleton.tar.gz Description: application/tgz
Re: News about iPod Sync and iTunes?
On Mon, Mar 31, 2008 at 5:03 AM, Rainer M Krug [EMAIL PROTECTED] wrote: Hi are there any news / patrches on the iPod sync with iTunes? Thanks Rainer No need to send multiple mails. If anyone knows something about this they will reply in their own time. Spamming the list doesn't help.
Re: translation
On Mon, Mar 31, 2008 at 12:05 PM, Lorenzo M [EMAIL PROTECTED] wrote: do u need an italian translator for your wiki/documentation? i can do it properly. Please check out http://wiki.winehq.org/Translating -- James Hawkins
re: Control-panel app. Works with mingw, need help with winegcc
pure_evil wrote:
Here's source for a .cpl that compiles fine with dev-c++.
How can I make it work with winegcc?
I had to do this to make winegcc happy:
--- skeleton/skeleton.c 2008-03-31 09:00:55.0 -0700
+++ skeleton.ok/skeleton.c 2008-03-31 11:34:24.128617000 -0700
@@ -24,12 +24,12 @@
#include skeleton.h
-LONG APIENTRY Applet1(HWND hwnd, UINT uMsg, LONG wParam, LONG lParam);
+LONG APIENTRY Applet1(HWND hwnd, UINT uMsg, LPARAM wParam, LPARAM lParam);
HINSTANCE hApplet = 0;
APPLET Applets[1] = { {CPLICON, CPLNAME, CPLDESC, Applet1} };
-LONG APIENTRY Applet1(HWND hwnd, UINT uMsg, LONG wParam, LONG lParam)
+LONG APIENTRY Applet1(HWND hwnd, UINT uMsg, LPARAM wParam, LPARAM lParam)
{return 1; }
LONG CALLBACK
but then I was able to generate a DLL that worked with control like this:
winegcc -mwindows skeleton.c -c -I ../wine-git/include
winegcc -shared skeleton.dll.specskeleton.o -o
skeleton.dll.so -lkernel32 -lntdll -lshell32 -L
../wine-git/libs/wine
wine control skeleton.dll.so
Worked first try. (Good thing, too, since I was just copying what wine already
does to build its dlls, and I wouldn't have known what to do if it failed.)
Does that work for you?
- Dan
Re: user32: Implement BroadcastSystemMessage, try 5.1
Hello Alexandre, 2008/3/31, Alexandre Julliard [EMAIL PROTECTED]: Vitaliy Margolen [EMAIL PROTECTED] writes: But that's the thing. How can you definitively say that there isn't a program that affected by this? Of course you can never be certain, but after having debugged a number of apps, and checked the behavior of APIs across Windows versions, there are things that you know do matter, and things that don't; and the last error behavior on success is definitely in the latter category. Yes, I'm sure someone someday can find a case where some specific app depends on some specific function to handle last error in a different way; but there's no reason to believe that BroadcastSystemMessage is more likely to trigger that bug than any other of the 10,000 functions that touch last error. So we either wait until we find an app that depends on this and fix the one offending function, or we spend months adding ugly code to every single API; adding the ugly code to only a handful of randomly chosen functions doesn't make any sense. Ok, I'll remove the last error tests where they don't matter then once I clean up my git tree a little, there's too much stuff lying around at the moment. :-) Cheers, Maarten.
Re: Control-panel app. Works with mingw, need help with winegcc
Worked first try. (Good thing, too, since I was just copying what wine already does to build its dlls, and I wouldn't have known what to do if it failed.) Does that work for you? - Dan Steven Edwards beat you to it, he sent me a patch ;) It works! It's alive! @all sorry folks 'bout the can't-be-done from days past; It can and has been done! A big thank you for Steven, you're my hero! Now, to get on with the executables :D
re: translation
do u need an italian translator for your wiki/documentation? Maybe, but we could use one even more for our user interfaces; see http://pf128.krakow.sdi.tpnet.pl/wine-transl/lang.php?lang=010%3A00 - Dan
re: News about iPod Sync and iTunes?
wine-0.9.59 might be able to sync old-style iPods, but iPod Touch / iPhone is a horse of a different color because it acts like a usb device rather than a mass storage device. It'll be a long time before we support this.
Re: Greek translation patch
2008/3/31 Dj Apal [GR] [EMAIL PROTECTED]: Hello all. I'm Apostolos Alexiadis and I had created some time ago the greek patch for comctl32. I have made some changes to the previous file and also added 2 new localization files for comdlg and hhctrl.ocx. If there is something worng with the patch, please let me know TIA http://winehq.org/site/sending_patches specifically, Submit one fix or group of related changes per patch. -- James Hawkins
Re: Some considerations about the Wine FUSE project for GSoC
On Mon, Mar 31, 2008 at 04:08:00PM +0200, Kai Blin wrote: On Monday 31 March 2008 15:30:17 Marc Andre Tanner wrote: I prototyped something and thought this way I would at least get some feedback (after all Talk is cheap. Show me the code. is common practice in the open source world). But this wasn't really the case, so i am still wondering what should be done differently? Whoops, I didn't see that url. Sorry, but things were a bit busy recently. I'll give that a whirl later today. I just pushed some primarily unicode based case mapping code implemented with help of http://www.icu-project.org/ to the git repository. I am not yet sure whether the transformation works as i think it should, but at least it translates some german umlauts correctly. On Debian system the required package is called libicu-dev. Fetch the latest code from: git://repo.or.cz/ciopfs.git Regards, Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0
Hey all, introducing myself and my GSoC idea...
My name is Alex. I'm an 18 year old Freshman at the University of South Florida. I'm an electrical engineer, but I've been coding since I was 13. I love low-level stuff, like assembly and ugly C, machine code, etc. I like to be able to smell the processor I'm so close to the metal. I made a proposal on GSoC to improve support for the Native API, an undocumented API in Windows. I'd really like to code for the Wine Project, since I like Windows, I like Linux, and I especially like low-level scrounging. I'm usually available by MSN, and generally fairly friendly. Send me an IM, or reply here to critique my proposal. It's entitled Proposal to improve Wine's support of the Native API. I'm registered as [EMAIL PROTECTED] Will someone look it over and tell me what they think? Also, suggested reading would be nice, especially if it pertains to the project idea and Wine's code base! Thanks for reading.
Re: Hey all, introducing myself and my GSoC idea...
On Mon, Mar 31, 2008 at 7:30 PM, a a [EMAIL PROTECTED] wrote: I made a proposal on GSoC to improve support for the Native API, an undocumented API in Windows. I'd really like to code for the Wine Project, since I like Windows, I like Linux, and I especially like low-level scrounging. I'm usually available by MSN, and generally fairly friendly. Send me an IM, or reply here to critique my proposal. It's entitled Proposal to improve Wine's support of the Native API. I'm registered as [EMAIL PROTECTED] Find a suite of third party applications and drivers that depend on the undocumented APIs otherwise your not going to get very far with getting your code in. -- 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
Valgrind errors up the yin-yang in CloseServiceHandle
I don't have the full results yet, but here's a clue as to today's warn+heap regression referred to in http://bugs.winehq.org/show_bug.cgi?id=12246 that affects every program: ==12026== Invalid read of size 4 ==12026==at 0x4BDAECD: RPCRT4_CloseBinding (rpc_binding.c:301) ==12026==by 0x4BE0DB3: I_RpcFreeBuffer (rpc_message.c:1116) ==12026==by 0x4BC0BB2: NdrFreeBuffer (ndr_clientserver.c:173) ==12026==by 0x49375E6: svcctl_CloseServiceHandle (svcctl_c.c:119) ==12026==by 0x492F024: CloseServiceHandle (service.c:1008) ... ==12026== Address 0x7f000ec0 is not stack'd, malloc'd or (recently) free'd ==12019== Invalid read of size 4 ==12019==at 0x46E7F47: RtlEnterCriticalSection (critsection.c:482) ==12019==by 0x4986763: RpcAssoc_ReleaseIdleConnection (rpc_assoc.c:408) ==12019==by 0x4987F32: RPCRT4_CloseBinding (rpc_binding.c:308) ==12019==by 0x498DDB3: I_RpcFreeBuffer (rpc_message.c:1116) ==12019==by 0x496DBB2: NdrFreeBuffer (ndr_clientserver.c:173) ==12019==by 0x493E5E6: svcctl_CloseServiceHandle (svcctl_c.c:119) ==12019==by 0x4936024: CloseServiceHandle (service.c:1008) ==12019==by 0x48F4206: main (wineboot.c:586) ==12019== Address 0x7f000da4 is not stack'd, malloc'd or (recently) free'd ==12019== Invalid read of size 4 ==12019==at 0x4986764: RpcAssoc_ReleaseIdleConnection (rpc_assoc.c:409) ==12019==by 0x4987F32: RPCRT4_CloseBinding (rpc_binding.c:308) ==12019==by 0x498DDB3: I_RpcFreeBuffer (rpc_message.c:1116) ==12019==by 0x496DBB2: NdrFreeBuffer (ndr_clientserver.c:173) ==12019==by 0x493E5E6: svcctl_CloseServiceHandle (svcctl_c.c:119) ==12019==by 0x4936024: CloseServiceHandle (service.c:1008) ==12019==by 0x48F4206: main (wineboot.c:586) ==12019== Address 0x7f000d8c is not stack'd, malloc'd or (recently) free'd
Re: Hey all, introducing myself and my GSoC idea...
Find a suite of third party applications and drivers that depend on the undocumented APIs otherwise your not going to get very far with getting your code in. Why is that? There are varying amounts of undocumented. Not documented on MSDN doesn't mean that no documentation exists. For instance, there's Gary Nebbett's Windows NT/2000 Native API Reference. Personally, I've thought that playing around with the native LPC API might be interesting. I'm sure there are other areas of the native API that are sparsely documented, and for which some test cases might prove useful. --Juan
Re: Hey all, introducing myself and my GSoC idea...
On Mon, Mar 31, 2008 at 8:11 PM, Juan Lang [EMAIL PROTECTED] wrote: Find a suite of third party applications and drivers that depend on the undocumented APIs otherwise your not going to get very far with getting your code in. Why is that? There are varying amounts of undocumented. Not documented on MSDN doesn't mean that no documentation exists. For instance, there's Gary Nebbett's Windows NT/2000 Native API Reference. Personally, I've thought that playing around with the native LPC API might be interesting. I'm sure there are other areas of the native API that are sparsely documented, and for which some test cases might prove useful. But is the API in question useful for the Wine project as far as fixing apps? I don't think we should devote SOC resources to a project that doesn't progress Wine beyond just implementing more APIs. -- James Hawkins
Re: Hey all, introducing myself and my GSoC idea...
But is the API in question useful for the Wine project as far as fixing apps? I don't think we should devote SOC resources to a project that doesn't progress Wine beyond just implementing more APIs. That's a good point. Alex, you'd probably want to specify which APIs in particular you're thinking of testing and implementing, and why they'd be useful for the Wine project. An app that uses them would be the easiest way to address their usefulness. And notice that in both my emails I said testing. Good test cases, in the form of regression tests added to Wine's test suite, are probably more important than the implementation would be. This is especially true of undocumented or poorly documented functions. Good luck, --Juan
Re: Proposal: versioning .wine directory
Dan Kegel wrote: On the wine-users list, we're getting a lot of users who have old or even ancient .wine directories, and whose problems go away with a fresh .wine directory Perhaps we should have wineprefixcreate stamp the version of wine the .wine directory was created with, make wine-1.0 refuse to run with pre-1.0 .wine directories, and require that future versions of wine run properly with .wine directories created by any earlier stable release of wine. It wouldn't be hard, at least at first, and it might save a lot of support inquiries. What say? I like it, since I already do something like this! How about a more surreptitious way of marking versions? Maybe a reg key or other file. This way, users might not be tempted to rename their ~/.wine and also keep the 1.0 transition smoother for scripts, say.
Re: Proposal: versioning .wine directory
On Mon, Mar 31, 2008 at 11:40 PM, TheBlunderbuss [EMAIL PROTECTED] wrote: I like it, since I already do something like this! How about a more surreptitious way of marking versions? Maybe a reg key or other file. This way, users might not be tempted to rename their ~/.wine and also keep the 1.0 transition smoother for scripts, say. Embedding the full version number maybe including the git ID of the source used as a string value in the Wine key should be enough. -- 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: user32: Implement GetWindowModuleFileName with tests (try 2)
Alexandre Julliard [EMAIL PROTECTED] wrote:
Maarten Lankhorst [EMAIL PROTECTED] writes:
@@ -3121,9 +3133,21 @@ UINT WINAPI GetWindowModuleFileNameA( HWND hwnd,
LPSTR lpszFileName, UINT cchFil
*/
UINT WINAPI GetWindowModuleFileNameW( HWND hwnd, LPWSTR lpszFileName, UINT
cchFileNameMax)
{
-FIXME(GetWindowModuleFileNameW(hwnd %p, lpszFileName %p,
cchFileNameMax %u) stub!\n,
- hwnd, lpszFileName, cchFileNameMax);
-return 0;
+HINSTANCE hInst;
+UINT ret;
+TRACE(hwnd %p, lpszFileName %p, cchFileNameMax %u\n, hwnd,
lpszFileName, cchFileNameMax);
+
+hInst = (HINSTANCE)GetWindowLongPtrW(hwnd, GWLP_HINSTANCE);
+if (!hInst)
+{
+if (hwnd == GetDesktopWindow() || !IsWindow(hwnd))
+return 0;
+hInst = GetModuleHandleW(0);
+}
+
+ret = GetModuleFileNameW(hInst, lpszFileName, cchFileNameMax);
+TRACE(-- %d %s\n, ret, debugstr_wn(lpszFileName, ret));
+return ret;
This won't work across processes.
Looks like GetWindowModuleFileName is not supposed to work for other
process windows, at least in the following snippet both GetWindowLongPtr
and GetWindowModuleFileName return 0 but don't change the last error value
under XP although FindWindow returns a valid window handle:
hwnd = FindWindow(Shell_TrayWnd, NULL);
SetLastError(0xdeadbeef);
ret = GetWindowModuleFileNameA(hwnd, buf, sizeof(buf));
printf(hwnd %p, ret %u, buf \%s\, error %u\n, hwnd, ret, buf,
GetLastError());
SetLastError(0xdeadbeef);
hinst = (HINSTANCE)GetWindowLongPtr(hwnd, GWLP_HINSTANCE);
printf(hwnd %p, hinst %u, error %u\n, hwnd, ret, GetLastError());
GetWindowLong(hwnd, GWL_STYLE) returns a valid style. Both APIs behave the same
way for the desktop window.
So the above implementation of GetWindowModuleFileName looks correct except
a special case for the desktop window (GetWindowLong() should be fixed instead).
--
Dmitry.
Re: user32: Implement GetWindowModuleFileName with tests (try 2)
Dmitry Timoshkov [EMAIL PROTECTED] wrote: This won't work across processes. Looks like GetWindowModuleFileName is not supposed to work for other process windows, at least in the following snippet both GetWindowLongPtr and GetWindowModuleFileName return 0 but don't change the last error value under XP although FindWindow returns a valid window handle: AF in the bug 10002 pointed out to http://support.microsoft.com/kb/228469 which explains that. -- Dmitry.
