- wine-devel - winehq.org

Re: Please remove / block user from bugzilla
by James Mckenzie 14 Jul '10

14 Jul '10

Austin English <austinenglish(a)gmail.com> wrote: >Sent: Jul 13, 2010 10:57 PM >To: Vitaliy Margolen <wine-devel(a)kievinfo.com> >Cc: Wine Develop <wine-devel(a)winehq.org>, matthewdchisholm(a)gmail.com >Subject: Re: Please remove / block user from bugzilla > >On Tue, Jul 13, 2010 at 11:12 PM, Vitaliy Margolen ><wine-devel(a)kievinfo.com> wrote: >> Please remove Matt Chisholm <matthewdchisholm(a)gmail.com> from bugazilla >> and/or block him from posting. Also please remove this post: >> http://bugs.winehq.org/show_bug.cgi?id=6971#c370 >> >> Vitaliy. > >(Repeating my comment from the bug): > >While I agree that comment doesn't belong on this bug, I see no reason >why his account should be removed. A warning is in order, not a ban. > +1. A friendly reminder that bugzilla is for bug reports is in order. BTW, that kind of post is allowed in some project's bug reporting areas. James McKenzie

1 0

Please remove / block user from bugzilla
by Vitaliy Margolen 14 Jul '10

14 Jul '10

Please remove Matt Chisholm <matthewdchisholm(a)gmail.com> from bugazilla and/or block him from posting. Also please remove this post: http://bugs.winehq.org/show_bug.cgi?id=6971#c370 Vitaliy.

2 1

[RFC] gameux.dll partial implementation
by Mariusz Pluciński 13 Jul '10

13 Jul '10

Hi The library I was working on last weeks - gameux.dll - is now partially complete. IGameExplorer and IGameExplorer2 interfaces are working and stores data in Windows-compatible format (attached tests confirm it). Last two interfaces - IGameStatistics and IGameStatisticsMgr has initial work done, but, as their task is only read and save data files, it's not much work to complete them. Please review my code and give some feedback about it. Thanks in advance.

2 4

Re: kernel32: Stubs for GetLogicalProcessorInformation(Ex) (try 2)
by Paul Chitescu 13 Jul '10

13 Jul '10

On Tuesday 13 July 2010 05:52:23 pm Paul Chitescu wrote: > Changelog: > kernel32: Stubs for GetLogicalProcessorInformation(Ex) > > These calls are implemented by XP SP3 or higher. > > This patch allows starting the MTG - Duel of the Planeswalkers demo on Steam > (crashes much later after starting the game on a missing shader or so). > > This version: > - fixed a typo in comments and changelog > "Fixes bug #23392"

1 0

New static analysis tool recommended by Mozilla: sixgill.org
by Scott Ritchie 13 Jul '10

13 Jul '10

I was watching this presentation on Mozilla's static analysis tools: http://www.galois.com/blog/2010/07/09/galois-tech-talk-video-large-scale-st… He is very fond of a new tool made by a recent PHD that was capable of handling Mozilla's massive codebase: sixgill.org I noticed it's not listed at http://wiki.winehq.org/StaticAnalysis, so maybe there's some benefit to using it as well. Thanks, Scott Ritchie

2 2

Re: README: update for 1.2
by Frédéric Delanoy 13 Jul '10

13 Jul '10

In this hunk, - wine notepad.exe /parameter1 -parameter2 parameter3 - (calling program with parameters) + wine notepad.exe readme.txt (calling program with parameters) shouldn't the /parameter1 and -parameter2 remain? i.e. are '/' and '-' interchangeable? Frédéric

3 2

Re: kernel32: Partially update the Dutch translation
by Henri Verbeet 13 Jul '10

13 Jul '10

On 13 July 2010 00:22, Sven Baars <sven.wine(a)gmail.com> wrote: > -Te veel open bestanden > +Teveel open bestanden Actually, I think the original was more correct. AFAIK "teveel" is a noun. > MessageId=102 > SymbolicName=ERROR_SEM_IS_SET > Language=NLD > -Semaphore is set > +Semafoor is een set I guess it depends on the context of the message, but it would make more sense to me if that's the verb "set" instead of the noun. I.e., as in "is in use" instead of "is a set".

2 1

[TRY 2] wined3d/directx.c: Corrected Nvidia 8400 and 8500 reporting
by Seth Shelnutt 13 Jul '10

13 Jul '10

This patches moved the Nvidia 8400 and 8500 reporting to it's own if statement and own return value. This will enable CUDA programs that check the renderer and compare it to a list of cuda capable devices to run on these cards. The 8300, which they currently are reported as, is not a CUDA capable device and thus is the reason for programs such as Folding@Home to fail in wine when using these cards. Thanks, Seth Shelnutt

1 0

wine explorer /desktop=Title,0x0 app.exe for fullscreen?
by Joerg-Cyril.Hoehle＠t-systems.com 13 Jul '10

13 Jul '10

Hi, on MacOS, I've setup winecfg with a default virtual desktop because full screen apps generally don't work. However, all windowing apps (e.g. notepad, regedit) would benefit from not using this desktop window. They nicely open resizable windows when run in full screen. The FAQ recommends wine explorer /desktop=Title,800x600 for running apps inside windows when fullscreen is the default setting. What I need is the exact opposite. Looking at the source, I found out that the converse works using wine explorer /desktop=Title,0x0 regedit.exe opens a regedit window without a virtual desktop one. Can that behaviour be blessed officially and documented? Or is it accidental? Regards, Jörg Höhle

4 4

Re: shlwapi/tests: Fix GLE for SHFormatDateTimeA
by testbot＠testbot.winehq.org 13 Jul '10

13 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3297 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:593: Test failed: GetShellSecurityDescriptor should fail ordinal.c:616: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1766: Test failed: got 26 ordinal.c:1816: Test failed: got 26 ordinal.c:1824: Test failed: got 26 ordinal.c:1832: Test failed: got 37, length 38 ordinal.c:1843: Test failed: got 40 === W7PROX64 (32 bit ordinal) === ordinal.c:1760: Test failed: got 9 ordinal.c:1781: Test failed: got 6 ordinal.c:1794: Test failed: got 9 ordinal.c:1802: Test failed: got 9 ordinal.c:1832: Test failed: got 32, length 33 ordinal.c:1843: Test failed: got 35 ordinal.c:1854: Test failed: got 19 ordinal.c:1865: Test failed: got 22

1 0

Having some trouble implementing D3DXComputeNormals... any hints/advice?
by Misha Koshelev 12 Jul '10

12 Jul '10

Dear All: Hope you are having a nice Sunday. I have decided that, as all the D3DXCreate... functions return vertex normals in addition to vertices themselves, it is more efficient to implement D3DXComputeNormals and use this function rather than calculate normals individually for each shape (or create an internal function that does the same thing). As you can see from this patch: http://github.com/misha680/wine/commit/0e975e7360f403eb123055b6ff996137e0b2… the normals computed by D3DXComputeNormals are almost equal to those originally returned by D3DXCreateCylinder for complex enough values of the radii, length, slices, and stacks (these values are within 10^-6 of each other). I have taken the following description from MSDN: "A normal for a vertex is generated by averaging the normals of all faces that share that vertex. If adjacency is provided, replicated vertices are ignored and 'smoothed' over. If adjacency is not provided, replicated vertices will have normals averaged in from only the faces explicitly referencing them." and implemented it in a test case (attached - code, compilation script, and compiled executable via MingW). For a very simplified cylinder (radii 1.0f, length 0.0f, 3 slices, 2 stacks) all seems well, and my normals match perfectly to those created by D3DXComputeNormals. However, for a more complicated case: static const FLOAT radius = 1.0f; static const FLOAT length = 1.0f; static const UINT slices = 10; static const UINT stacks = 20; You can see something quite perplexing. Specifically, below you can see all 3 triangles that contain vertex #11 (11, 21, and 12 are vertex indices, below you will see the actual vertex X,Y,Z values, and finally the computed normal for the specific triangle). Below, you can see under "Averaged Normals", first the normal computed by averaging and normalizing the normals for each of the triangles, and then the original normal computed by D3DXComputeNormals. Notice that they are quite (significantly) different. This does not happen for a lot of vertices, but for quite a few (say 5-10%). Index Buffer: 11,21,12, {0,1,-0.5}, {0,1,-0.45}, {0.587785,0.809017,-0.5}, {0.00954915,0.0293893,0}, 20,30,11, {-0.587785,0.809017,-0.5}, {-0.587785,0.809017,-0.45}, {0,1,-0.5}, {-0.00954915,0.0293893,0}, 11,30,21, {0,1,-0.5}, {-0.587785,0.809017,-0.45}, {0,1,-0.45}, {-0.00954915,0.0293893,0}, Averaged Normals: 11 {-0.107677,0.994186,0} {-1.99491e-008,1,0}, I have used the equivalent statement for D3DXComputeNormals: if (!SUCCEEDED(D3DXComputeTangentFrameEx(mesh, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DX_DEFAULT, 0, D3DDECLUSAGE_NORMAL, 0, D3DXTANGENT_GENERATE_IN_PLACE | D3DXTANGENT_CALCULATE_NORMALS, NULL, -1.01f, -0.01f, -1.01f, NULL, NULL))) and tried to vary the parameters listed below, but honestly am a bit stumped... I will investigate further, but if perhaps I am missing something simple, would be great to know! Thanks Misha p.s. Fyi these are the relevant parameters for D3DXComputeTangentFrameEx from http://msdn.microsoft.com/en-us/library/bb172745%28v=VS.85%29.aspx Thank you! Misha fPartialEdgeThreshold [in] FLOAT Specifies the maximum cosine of the angle at which two partial derivatives are deemed to be incompatible with each other. If the dot product of the direction of the two partial derivatives in adjacent triangles is less than or equal to this threshold, then the vertices shared between these triangles will be split. fSingularPointThreshold [in] FLOAT Specifies the maximum magnitude of a partial derivative at which a vertex will be deemed singular. As multiple triangles are incident on a point that have nearby tangent frames, but altogether cancel each other out (such as at the top of a sphere), the magnitude of the partial derivative will decrease. If the magnitude is less than or equal to this threshold, then the vertex will be split for every triangle that contains it. fNormalEdgeThreshold [in] FLOAT Similar to fPartialEdgeThreshold, specifies the maximum cosine of the angle between two normals that is a threshold beyond which vertices shared between triangles will be split. If the dot product of the two normals is less than the threshold, the shared vertices will be split, forming a hard edge between neighboring triangles. If the dot product is more than the threshold, neighboring triangles will have their normals interpolated.

2 5

xrender.c is does not find fontconfig.h on OS X Tiger
by Mike Kronenberg 12 Jul '10

12 Jul '10

Dear List OS X Tiger does has not have fontconfig, so I'm building it in ~/buildwine/usr to keep it out of /usr. I include the headers and libs from ~/buildwine/usr with CPPFLAGS and CFLAGS. This worked fine until 1.2-rc1 and 1.2-rc2. Compiling xrender.c now exits with an error that FC_WEIGHT_THIN etc is not defined. configure leaves me with SONAME_LIBFONTCONFIG='libfontconfig.1.dylib' FONTCONFIGINCL='' in the config.log. No luck even if I export FONTCONFIGINCL="-I//$HOME/buildwine/usr/include/fontconfig -I//$HOME/buildwine/usr/include' which resulted in a correct FONTCONFIGINCL, but the compiling still failed. All the other custom compiled deps are working as usual. Any hint what I might missing? txs Mike

2 2

Re: wined3d/directx.c: Corrected Nvidia 8400 and 8500 reporting
by Roderick Colenbrander 12 Jul '10

12 Jul '10

Hi Seth, It is not a good idea to advertise a 8400 and a 8500 as a 8600GT. All Geforce8 GPUs have the same features (except, some have different purevideo capabilities). As mentioned before even CUDA is allowed on all GPUs but only if they have 256MB or more. Likely the app you are using either disallows this GPU based on the wrong number of video memory Wine reports or it just disallows poor GPUs because it is not worth the effort to use them for CUDA computations because they don't have enough computation power. The Geforce 8600GT is (depending on the configuration) upto 4x faster (if you just look at shaders + clock speeds), so it is really not a good idea to mark the 8400/8500 as a 8600GT. This could really cause issues for games which use the PCI id to select a performance profile at startup. It would be better to add a separate 8500GT entry with 256MB. I'm not sure if we want to merge it with the 8400 though since the 8500 has 256-1024 (depending on the model) and the 8400 has 128-512MB. A lot of modern games like to have around 256MB. I guess it is best to keep the 8400 tied to the 8300. Roderick On Sun, Jul 11, 2010 at 7:04 PM, Seth Shelnutt <shelnutt2(a)gmail.com> wrote: > Moves the Nvidia Geforce 8400 and 8500 to be reported as 8600GT as they have > feature parity. This is needed for CUDA applications to support these two > cards. They are currently reported as an 8300 which is not CUDA capable. > > Thanks, > > Seth Shelnutt > > > >

2 2

Old documentation changelogs to be kept?
by Frédéric Delanoy 12 Jul '10

12 Jul '10

In the documentation directory, there are ChangeLog.ALPHA, ChangeLog.BETA and ChangeLog.OLD. Are these files still useful (most recent entry is dated 2008-06-16)? Or are they simply kept as a log of the good old pre-git days? Frédéric

1 0

Manifests, Microsoft.VC90.CRT and vc_redist
by Peter Urbanec 12 Jul '10

12 Jul '10

I'm trying to get my head around the mess generated by SxS, isolated apps, embedded manifests, local deployment and all the other "solutions" to DLL hell. It's hard enough to make it work on Windows, but making it work well under wine is another challenge. In a nutshell, I'd like to ship a custom wine64 RPM package that can co-exist with distribution provided wine32 RPMs. I also want to make a couple of companion RPMs, which provide x64 apps that depend on my wine64 RPM. I don't want to require an installation of the x64 packages under Wine. i.e. I want to avoid the requirement to run vcredist_x64.exe for each user. The most obvious solution to this seems to be to include the DLLs from "Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT" in the same dir as the x64 application executable, known as "application local deployment". Now, this is where I get confused. The VC redist files provide DLLs with version 9.0.30729.1, whereas the manifest embedded in the application has version 9.0.21022.8. When the 9.0.30729.1 VC redist files are installed in the windows dir, the associated policies will redirect requests for 9.0.21022.8 to use 9.0.30729.1, but this does not seem to work when the DLLs are deployed in the app directory. Wine itself provides msvcr90.dll.so, which as far as I can tell doesn't play the manifest games or provide any particular version number. Should I be using msvcr90.dll from VC redist? Should I be using msvcr90.dll.so provided by wine? If so, how do I tell wine to ignore manifests and just load the DLLs found in the app dir? Thanks for any insights you could provide.

3 3

Re: [PATCH 2/2] uninstaller: Update the Czech translation.
by Michael Stefaniuc 12 Jul '10

12 Jul '10

Forgot to remove the "[PATCH 2/2]". There is no dependency for this patch. bye michael Michael Stefaniuc wrote: > Translation by Radek Vokal. > --- > programs/uninstaller/Cs.rc | 9 ++++----- > 1 files changed, 4 insertions(+), 5 deletions(-) > > diff --git a/programs/uninstaller/Cs.rc b/programs/uninstaller/Cs.rc > index ed73cd3..f6ee8cc 100644 > --- a/programs/uninstaller/Cs.rc > +++ b/programs/uninstaller/Cs.rc > @@ -1,5 +1,4 @@ > -/* Hey, Emacs, open this file with -*- coding: cp1250 -*- > - * > +/* > * Uninstaller (Czech Resources) > * > * > @@ -22,9 +21,9 @@ > > LANGUAGE LANG_CZECH, SUBLANG_NEUTRAL > > -/* Czech strings in CP1250 */ > - > +#pragma code_page(65001) > > STRINGTABLE DISCARDABLE { > - IDS_APPNAME, "Deinstalátor" > + IDS_APPNAME, "DeinstalÃ¡tor" > + IDS_UNINSTALLFAILED, "SpuÅ¡tÄ›nÃ pÅ™Ãkazu %s selhalo, moÅ¾nÃ¡ pÅ™ÃÄÃna je chybÄ›jÃcÃ aplikace.\nPÅ™ejete si odstranit instalaÄnÃ zÃ¡znam z registru?" > }

1 0

Re: user32: Add a test showing that SetForegroundWindow() on a visible child of invisible parent does activate the parent an
by testbot＠testbot.winehq.org 12 Jul '10

12 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3291 Your paranoid android. === W98SE (32 bit win) === win.c:2950: Test failed: hwnd 000004C4 message 0112 win.c:2952: Test failed: message 0112 available win.c:2959: Test failed: hwnd 000004C4 message 0100 win.c:2961: Test failed: message 0100 available win.c:2973: Test failed: message 000f available win.c:2985: Test failed: message 000f available win.c:2994: Test failed: message 000f available win.c:3003: Test failed: message 000f available === W2KPROSP4 (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000900A6 fg 000600AE in hook HCBT_SETFOCUS === WXPPROSP3 (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000700F0 fg 000A0148 in hook HCBT_SETFOCUS === W2K3R2SESP2 (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000500D8 fg 000B00BE in hook HCBT_SETFOCUS === WVISTAADM (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000D0108 fg 000E0106 in hook HCBT_SETFOCUS === W2K8SE (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 000500FE fg 00040152 in hook HCBT_SETFOCUS === W7PRO (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0005015A fg 00090132 in hook HCBT_SETFOCUS === W7PROX64 (32 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0005016E fg 000401B0 in hook HCBT_SETFOCUS === W7PROX64 (64 bit win) === win.c:823: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0000000000050170 fg 00000000000301B0 in hook HCBT_SETFOCUS

1 0

Re: user32: Make sure that main window state is consistent during the tests.
by testbot＠testbot.winehq.org 12 Jul '10

12 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3290 Your paranoid android. === W98SE (32 bit win) === Timeout === WVISTAADM (32 bit win) === win.c:2271: Test failed: 000F0200: expected prev 000D01D8, got 003301D2 win.c:2272: Test failed: 000D01D8: expected next 000F0200, got 003301D2 win.c:2198: Test failed: 00BF01D0: expected next 00040208, got 000E01E0 win.c:2271: Test failed: 003401D2: expected prev 00110200, got 000F01E0 win.c:2272: Test failed: 00110200: expected next 003401D2, got 000F01E0 === W2K8SE (32 bit win) === win.c:2271: Test failed: 000E0110: expected prev 000B0116, got 009000FC win.c:2272: Test failed: 000B0116: expected next 000E0110, got 009000FC win.c:2198: Test failed: 0052010E: expected next 000500F4, got 000C0114 win.c:2271: Test failed: 009100FC: expected prev 00100110, got 000D0114 win.c:2272: Test failed: 00100110: expected next 009100FC, got 000D0114

2 1

Re: winhlp32: Remove an untranslated resource from multiple translations.
by Dmitry Timoshkov 12 Jul '10

12 Jul '10

Michael Stefaniuc <mstefani(a)redhat.de> wrote: > This affects the Bg, Cs, Da, Eo, Fi, Hu, Sk, Tr and Wa translations. It's better to have it, even not translated. String resources should be fully filled up. Why do remove this one and leave the others? -- Dmitry.

2 1

Request: please add your expertise to the release announcement!
by Scott Ritchie 12 Jul '10

12 Jul '10

Alexandre has said -rc7 is likely to be the last rc before release, which means we're quickly running out of time to get a good release announcement. Please add whatever you think might be interesting to the wiki page. It's ok if it's not a complete sentence at this point, I can clean that stuff up myself -- what the page really needs is content. http://wiki.winehq.org/Wine1.2Announcement In particular, we need examples of new platinum-quality apps and new neat technical features you're proud of. Thanks, Scott Ritchie

2 1

Re: List of Video cards in directx.c
by Seth Shelnutt 12 Jul '10

12 Jul '10

On Sun, Jul 11, 2010 at 4:21 PM, Roderick Colenbrander < thunderbird2k(a)gmail.com> wrote: > > The PCI id is something else. For instance run 'lspci -x': > 01:00.1 Audio device: ATI Technologies Inc RV620 Audio device [Radeon > HD 34xx Series] > 00: 02 10 28 aa 07 01 10 40 00 00 03 04 10 00 80 00 > .. > > This line shows a part of the PCI configuration header. The first two > bytes contain the PCI vendor id (0x1002 = ATI; you have to swap the > bytes) and byte 3 and 4 contain the PCI device id (0xaa28 = radeon > 3450). Each device has such information and it is used by the > operating system to detect which hardware is around. > > A lot of games use the PCI id, since it can be easier to parse than > the renderer strings. > > That makes sense. I had based my thinking on the following comment, A Direct3D device object contains the PCI id (vendor + device) of the videocard which is used for rendering. I had assumed vendor + device meant the strings. > We have to keep the current static database. Extending it with video > memory reporting is likely the best way to go. So now and then it just > means that we have to refine it a little. > > Roderick > Thinking things over I think you are right. Trying to add any kind of dynamic support at this stage is not worth it. Even the memory reporting is very recent and new. Maybe in a couple years more support will have materialized from opengl or the drivers to help with this issue. For now though I just submitted a patch to deal with the issue of a 8500/8400 being reported as a 8300. I moved the detection to be reported as an 8600. I thought about creating a new 8500 in the database but I realized that an 8600 is of feature parity and has the same video memory minimum. Thanks, Seth Shelnutt

1 0

Re: shlwapi: Partially implement SHGetShellKey (try5)
by testbot＠testbot.winehq.org 11 Jul '10

11 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3283 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:595: Test failed: GetShellSecurityDescriptor should fail ordinal.c:618: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1761: Test failed: got 13 ordinal.c:1782: Test failed: got 10 ordinal.c:1795: Test failed: got 13 ordinal.c:1803: Test failed: got 13 ordinal.c:1833: Test failed: got 37, length 38 ordinal.c:1844: Test failed: got 40 ordinal.c:1855: Test failed: got 23 ordinal.c:1866: Test failed: got 26 === W7PROX64 (32 bit ordinal) === ordinal.c:1774: Test failed: got 12 ordinal.c:1810: Test failed: got 12 ordinal.c:1855: Test failed: got 20 ordinal.c:1866: Test failed: got 23 === W7PROX64 (64 bit ordinal) === ordinal.c:1761: Test failed: got 10 ordinal.c:1767: Test failed: got 23 ordinal.c:1782: Test failed: got 7 ordinal.c:1795: Test failed: got 10 ordinal.c:1803: Test failed: got 10 ordinal.c:1817: Test failed: got 23 ordinal.c:1825: Test failed: got 23 ordinal.c:1833: Test failed: got 32, length 33 ordinal.c:1844: Test failed: got 35 ordinal.c:1855: Test failed: got 20 ordinal.c:1866: Test failed: got 23

1 0

List of Video cards in directx.c
by Seth Shelnutt 11 Jul '10

11 Jul '10

I'm not sure if this is appropriate for a code freeze or not but I think it is. We just ran into an issue with the folding gpu client in wine with someone. Turns out it's because wine reports the card as a 8300 not an 8500. Looking at directx.c I see that that is probably because an 8500 is not listed. I've got a patch to add the single line for 8500 but I was wondering, would it not be beneficial to add a list of all graphic cards dating back to a certain point? There are even less ATI cards listed than Nvidia. All that is required is going to say wikipedia or Nvidia/Ati.com and just go through the list of the cards. Thanks, Seth Shelnutt

5 6

sorry one more question: assert statements in tests
by Misha Koshelev 10 Jul '10

10 Jul '10

I am implementing my tests as follows: * patch 1: general test for a D3DX function (D3DXCreateBox for example, testing specific vertices and indices for _specific_ dimensions). * patch 2: separate into function that works with arbitrary dimensions for the box, etc. I restrict to the dimensions from patch 1 using assert statements. * patch 3: expand to allow arbitrary parameters to the function, e.g., arbitrary dimensions, removing the assert statements. For example, see patch 2 = http://github.com/misha680/wine/commit/6291ca28593c78761ccef3137b1014bae87d… patch 3 = http://github.com/misha680/wine/commit/7b09cfb661bf1d03fd80195c0cd2b7b3bb9f… Is assert the right way to do this? If not, what is? Thank you Misha

2 5

Inserting commits fyi... I think this might do the trick
by Misha Koshelev 10 Jul '10

10 Jul '10

Thank you all for your comments. I still seem to be losing commits. However I have found a reference that seems like it might do the trick and wanted to share with others. Specifically, the key is to mark edit in interactive rebase on the commit one desires to split. Next one does a git reset HEAD^ to revert the commit. Then, one can create one or more commits without the --amend parameter. Finally one does git rebase --continue Sorry if this is already known to all of you but I have been chasing disappearing commits for a few days now and this seems like quite useful knowledge. Misha http://book.git-scm.com/4_interactive_rebasing.html

1 0

git rebase to _insert_ commits?
by Misha Koshelev 10 Jul '10

10 Jul '10

Dear All: I am still learning git and it seems that my solution does not quite work. Specifically, my idea was to use: git rebase -i upstream/master Mark the commit _after_ which I'd like to insert a commit with edit. Then, when I am at that commit, I do: git commit --amend -a save commit Then, _before_ doing git rebase --continue, I edit files and again do: git commit -a -n Finally I do: git rebase --continue The problem is that this seems to squish further commits, and leads to problems which I am now trying to untangle. However, as I still cannot insert a commit, I am not sure how to proceed, except by creating a whole new repository. Any ideas/hints? Thank you Misha

2 2

Re: wined3d: Add GL_NV_point_sprite extension.
by Henri Verbeet 10 Jul '10

10 Jul '10

2010/7/10 Rico Schüller <kgbricola(a)web.de>: > + if ((!context->gl_info->supported[WINED3D_GL_VERSION_2_0] > + || (!glPointParameteri && context->gl_info->supported[WINED3D_GL_VERSION_2_0] > + && !context->gl_info->supported[NV_POINT_SPRITE]) ) The second "context->gl_info->supported[WINED3D_GL_VERSION_2_0]" is redundant.

1 0

please don't shoot from the hip ;)
by Misha Koshelev 10 Jul '10

10 Jul '10

Hi Guys: I really appreciate all the responses to my work on this bug http://bugs.winehq.org/show_bug.cgi?id=22918 Especially the fact that you guys are looking at this code is very very important to me, as it will have to be eventually reviewed to be submitted to Wine. However, I am a little frustrated as the comments I received were things already discussed on wine-devel. I find myself in quite the lucky position that I can work on Wine for some time. I do this with no economic compensation of any kind (as I guess most of you as well - except Codeweavers people grin ;) - oh and full disclosure with the exception of a book on DirectX and hopefully a trip to WineConf ;) ). However, I'd like to spend the time actually coding, not referencing wine-devel. In any case, I'd appreciate it if you have a comment on my code/patches, esp if it might have already been discussed on wine-devel, please don't "shoot from the hip" and check wine-devel first... Anyway enough venting. Off to work. Again I appreciate the attention to my patches. Misha

3 2

nightly kernel testbot up
by Austin English 10 Jul '10

10 Jul '10

Howdy, I wrote a quick script to test the latest wine and linux kernel, to hopefully prevent more regressions like the WoW login bug. The test machine is in a virtualbox vm, so of course graphics tests won't be useful, but the rest should be... There are already a few results up (in the future, it'll be one per day, but I had to debug). tag is 'ae-lucid-nighkernel': http://test.winehq.org/data/1cd170fd2e0e7df5083e7c66f8422783c57ed256/wine_a… there are a few test failures that look interesting: kernel32:debugger kernel32:process kernel32:thread kernel32:toolhelp kernel32:virtual ntdll:exception ntdll:info psapi:psapi_main rpcrt4:rpc rpcrt4:server For the curious, script is at http://winezeug.googlecode.com/svn/trunk/build_script/auto-update-winetest.… -- -Austin

1 1

Re: git rebase to _insert_ commits?
by Mike Kaplinskiy 10 Jul '10

10 Jul '10

You can move commits around in an interactive rebase. Just create an empty commit, move it into place with rebase and edit it. Sorry for top post, mobile gmail doesn't let you bottom post. On Jul 9, 2010 8:56 PM, "Misha Koshelev" <misha680(a)gmail.com> wrote: Dear All: I am still learning git and it seems that my solution does not quite work. Specifically, my idea was to use: git rebase -i upstream/master Mark the commit _after_ which I'd like to insert a commit with edit. Then, when I am at that commit, I do: git commit --amend -a save commit Then, _before_ doing git rebase --continue, I edit files and again do: git commit -a -n Finally I do: git rebase --continue The problem is that this seems to squish further commits, and leads to problems which I am now trying to untangle. However, as I still cannot insert a commit, I am not sure how to proceed, except by creating a whole new repository. Any ideas/hints? Thank you Misha

2 2

re: [PATCH] Fix EndDialog behaviour for OrCad.
by Dan Kegel 09 Jul '10

09 Jul '10

Thanks for sending that patch. It seems your editor stripped whitespace from the ends of lines, causing three whitespace-only hunks on the end of your patch. Please don't do that; Wine deveopers frown on unrelated whitespace changes. You might have better luck getting your change in if you include a test. Even then, we're in code freeze, your fix might have to wait until 1.2 is released.

3 5

Can Relay miss some calls in initialization stage?
by Hayan Lee 09 Jul '10

09 Jul '10

Hi, all I'm working on relay layer in WINE. When I turn on WINEDEBUG=+relay, relay looks to miss some calls. When is the relay layer loaded? Before dll loaded or after? If WINE does something in its initialization step, relay can catch those or not? Thanks in advance. Hayan

3 3

Portuguese (Brazil) translation of Wine at 100%
by Paul Vriens 09 Jul '10

09 Jul '10

Hi, Many thanks to Gustavo who brought the Portuguese (Brazil) translation to a 100%. The list of 100% translations is slowly growing, we now have 7 (not counting the ones that are mostly inherited from the neutral ones)!! -- Cheers, Paul.

4 4

WINED3DUSAGE_MASK?
by Misha Koshelev 09 Jul '10

09 Jul '10

Dear All: Sorry to bother - I just ran into something quite curious in terms of a Wine-specific feature that is certainly not matched in Windows XP and was wondering what its purpose was... Also, should I use todo_wine to test for this, or is there a better way since this seems something that obviously we're not trying to "make conform" in Wine but rather something that seems to be an intended feature (please correct me if I am incorrect). Specifically, this is a usage flag for index buffer creation that seems to have been introduced here: commit 3529560cd7a4f752596e80d4084e9527b348eb22 Author: Stefan Dösinger <stefandoesinger(a)gmx.at> Date: Thu Oct 5 17:56:54 2006 +0200 wined3d: Add WINED3DUSAGE_OVERLAY. diff --git a/dlls/d3d9/indexbuffer.c b/dlls/d3d9/indexbuffer.c index fc85357..269552a 100644 --- a/dlls/d3d9/indexbuffer.c +++ b/dlls/d3d9/indexbuffer.c @@ -175,7 +175,7 @@ HRESULT WINAPI IDirect3DDevice9Impl_CreateIndexBuffer(LPDIRECT3DDEVICE9 iface, object->lpVtbl = &Direct3DIndexBuffer9_Vtbl; object->ref = 1; TRACE("Calling wined3d create index buffer\n"); - hrc = IWineD3DDevice_CreateIndexBuffer(This->WineD3DDevice, Length, Usage, Format, (WINED3DPOOL) Pool, &object->wineD3DIndexBuffer, pSharedHandle, (IUnknown *)object); + hrc = IWineD3DDevice_CreateIndexBuffer(This->WineD3DDevice, Length, Usage & WINED3DUSAGE_MASK, Format, (WINED3DPOOL) Pool, &object->wineD3DIndexBuffer, pSharedHandle, (IUnknown *)object); if (hrc != D3D_OK) { /* free up object */ Thank you Misha

2 2

Re: [1/8] msi/tests: Run the automation tests in silent mode to avoid a dialog.
by testbot＠testbot.winehq.org 09 Jul '10

09 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3251 Your paranoid android. === W7PROX64 (64 bit automation) === automation.c:2487: Test failed: Expected imaname, got automation.c:2504: Test failed: Expected imaname, got

2 1

Re: kernel32: Loosen trailing \ requirement on GetVolumeInformationAW.
by Alexandre Julliard 09 Jul '10

09 Jul '10

<Joerg-Cyril.Hoehle(a)t-systems.com> writes: > The tests prove that not all calls without a trailing slash must fail. > So until we know more precisely the exact conditions, I feel it's > better to revert to the old behaviour that allowed the copy > protection scheme to work. That's only moving the bug around. We have tests for the current behavior, any further improvement must keep the existing tests working. -- Alexandre Julliard julliard(a)winehq.org

2 4

TestBot: new VMs and components
by Greg Geldorp 08 Jul '10

08 Jul '10

Upon request, I've added a couple of VMs for your testing pleasure: WXPPROARSP3 - Windows XP Pro Arabic SP3 WXPPROJASP3 - Windows XP Pro Japanese SP3 WXPPRORUSP3 - Windows XP Pro Russian SP3 WXPPROZHSP3 - Windows XP Pro Chinese simplified SP3 I must say, installing these VMs with their non-Western scripts was quite a challenge :-). I'm also in the process of adding some components to all applicable VMs: Microsoft Visual C++ 2005 Runtime Microsoft Visual C++ 2008 Runtime DirectX End-User Runtimes (June 2010) It will take some time before these components are available everywhere. If you'd like to see more components added please let me know. Ge.

1 0

Re: shell32: Add stub for SHGetPropertyStoreFromParsingName
by Hans Leidekker 08 Jul '10

08 Jul '10

On Thu, 2010-07-08 at 21:19 +0200, André Hentschel wrote: > +@ stdcall SHGetPropertyStoreFromParsingName(str ptr long ptr ptr) The first parameter should be wstr.

2 1

Re: [1/2] gdiplus: Fixed GdipFillClosedCurve2 and GdipFillClosedCurve2I in the case that count == 1 (should do nothing).
by James Mckenzie 08 Jul '10

08 Jul '10

Wade: Does this fix a known bug? We are indeed in code freeze and this is a big patch... James McKenzie -----Original Message----- >From: Wade Gobel <wgobel(a)codeweavers.com> >Sent: Jul 8, 2010 7:27 AM >To: wine-patches <wine-patches(a)winehq.org> >Subject: [1/2] gdiplus: Fixed GdipFillClosedCurve2 and GdipFillClosedCurve2I in the case that count == 1 (should do nothing). >

2 1

Re: write: Add Gaelic resource
by Jimmy O'Regan 08 Jul '10

08 Jul '10

On 8 July 2010 14:52, Ken Sharp <kennybobs(a)o2.co.uk> wrote: > My Irish (Irish, not "Gaelic") has been steadily deteriorating since I left school, but it's painfully clear that you don't speak a word of the language. + IDS_FAILED, "Ag tosú Wordpad Theip" Should be something like 'Theip ar Wordpad a thosú'; what you've written comes across like "Is starting Wordpad. Fail!" And it's not just this patch. This line from MAPI is just word soup: "R-phost a sheoladh mar a theip ní gá duit a cliant ríomhphoist MAPI shuiteáil" 'Email to send because to fail you don't need her MAPI email client install" -- <Leftmost> jimregan, that's because deep inside you, you are evil. <Leftmost> Also not-so-deep inside you.

2 2

Re: ntdll: Stub system service requests in i386 mode (Int 2E, SYSENTER, SYSCALL) (try 3)
by Vitaliy Margolen 08 Jul '10

08 Jul '10

On 07/06/2010 03:15 PM, Paul Chitescu wrote: > Changelog: > ntdll: Stub system service requests in i386 mode (Int 2E, SYSENTER, SYSCALL) > > + WINE_FIXME( "(0x%02X, %p): stub\n", index, param_block ); > + WINE_TRACE( "INT 2E at 08%x\n", context->Eip ); Any particular reason you using these and not FIXME/TRACE ? Vitaliy.

2 1

Re: [1/2] gdiplus: Fixed GdipFillClosedCurve2 and GdipFillClosedCurve2I in the case that count == 1 (should do nothing).
by Nikolay Sivov 08 Jul '10

08 Jul '10

On 7/8/2010 18:27, Wade Gobel wrote: > --- > dlls/gdiplus/graphics.c | 8 ++- > dlls/gdiplus/tests/graphics.c | 135 > +++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 142 insertions(+), 1 deletions(-) Hi, Wade. Patches are broken by your mail client. You could attach or setup your client to preserve message text as you pasted it.

1 0

Re: [PATCH 1/2] d3dx9: Fix indentation in D3DXDeclaratorFromFVFTest. (try 4)
by Misha Koshelev 08 Jul '10

08 Jul '10

> Misha Koshelev <misha680 at gmail.com> wrote: > > > >Ok per Dan's comments back to <last as this looks nicer. > > > Misha: > > Alexandre rejects 'white space' changes, that is changes that fix indentation, remove extraneous or trailing spaces and tabs unless there is another change needed. If there is a needed change in this file, go ahead and fixup white space around the change. Otherwise, hold onto this change in case you need to use it in the future. > > Your other change was accepted by Alexandre and was committed. > > James McKenzie Thanks James and I appreciate the style advice. Hope I didn't start anything too bitter about coding styles ;) Remember we're all on the same page - making a great product even greater! (Ok enough silly cheery attitude now). Misha

2 2

Re: [2/2] gdiplus: Implemented GdipFillClosedCurve and GdipFillClosedCurveI.
by testbot＠testbot.winehq.org 08 Jul '10

08 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3232 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: [1/2] gdiplus: Fixed GdipFillClosedCurve2 and GdipFillClosedCurve2I in the case that count == 1 (should do nothing).
by testbot＠testbot.winehq.org 08 Jul '10

08 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3231 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

How far to push behavioural compatibility with native?
by Joerg-Cyril.Hoehle＠t-systems.com 08 Jul '10

08 Jul '10

Hi, Unlike mciwave, the native mciseq MIDI player does not know the MCI_RESUME command. It instead returns MCIERR_UNSUPPORTED_FUNCTION. Tests with notification suggest that MCI_PAUSE actually aborts the player, much like MCI_STOP. It's a different behaviour than mciwave. (You can always "resume" a paused player using MCI_PLAY without arguments. MCI_RESUME is superfluous, except that "resume all" is different from "play all".) OTOH, Wine implements MCI_RESUME and MCI_PAUSE functionality for the MIDI sequencer as one would expect it to work (and mciwave does), according to the MCI specification. As I'm currently thinking about how to rewrite the players to avoid various race conditions (e.g. bug #22978), I'm left wondering whether I should drop the extra functionality that was written for Wine and replace it with something which behaves as closely as possible like the native player, or whether it's nice to have something more evolved in Wine, e.g. working PAUSE and RESUME commands (and some apps issue PAUSE ALL or RESUME ALL commands). What do you think? A) Bug compatibility => Behavioural compatibility => drop existing code and try to mimic native's behaviour as closely as possible. B) PAUSE and RESUME is a useful extension not present in native, keep it as long as no app is affected by this difference in behaviour. Regards, Jörg Höhle

3 2

Re: kernel32/tests: Skip fewer tests on Win9x.
by testbot＠testbot.winehq.org 08 Jul '10

08 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3224 Your paranoid android. === WINEBUILD (build) === Patch failed

1 0

Re: d3d9: add few tests for GetAdtapterDisplayModeEx (try 2)
by testbot＠testbot.winehq.org 08 Jul '10

08 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3223 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: d3d9: add a few tests for GetAdapterDisplayModeEx
by Louis Lenders 07 Jul '10

07 Jul '10

On 7 July 2010 23:39, Louis Lenders <xerox_xerox2000 at yahoo.co.uk> wrote: > + todo_wine ok(mode_ex.ScanLineOrdering == D3DSCANLINEORDERING_PROGRESSIVE, >"ScanLineOrdering is %d instead of %d\n", mode_ex.ScanLineOrdering, >D3DSCANLINEORDERING_PROGRESSIVE); > + todo_wine ok(rotation == D3DDISPLAYROTATION_IDENTITY, "rotation is %d >instead of %d\n", rotation, D3DDISPLAYROTATION_IDENTITY); >These obviously depend on the actual setup of the machine running the >test. yeah, you have a suggestion how to change the test, or should i just leave them out of the test? >It also seems likely that you're supposed to initialize >mode_ex.Size before making the GetAdapterDisplayModeEx() call. I did that in the test: test shows that it fails if mode_ex.Size is null, when it is set to sizeof(D3DDISPLAYMODEEX) it returns D3D_OK

2 1

Re: d3d9: add a few tests for GetAdapterDisplayModeEx
by Henri Verbeet 07 Jul '10

07 Jul '10

On 7 July 2010 23:39, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > + todo_wine ok(mode_ex.ScanLineOrdering == D3DSCANLINEORDERING_PROGRESSIVE, "ScanLineOrdering is %d instead of %d\n", mode_ex.ScanLineOrdering, D3DSCANLINEORDERING_PROGRESSIVE); > + todo_wine ok(rotation == D3DDISPLAYROTATION_IDENTITY, "rotation is %d instead of %d\n", rotation, D3DDISPLAYROTATION_IDENTITY); These obviously depend on the actual setup of the machine running the test. It also seems likely that you're supposed to initialize mode_ex.Size before making the GetAdapterDisplayModeEx() call.

1 0

fyi d3dx work
by Misha Koshelev 07 Jul '10

07 Jul '10

I did end up going with a github repo as I've finally figured out git pretty well (thanks a lot to you guys!) It is here: http://github.com/misha680/wine/commits/master In any case, feel free to peruse if interested. Hopefully when 1.2 is done I can start submitting to wine. Henri especially has been quite helpful with COM interface advice for DirectX, and I appreciate this very much. Misha

1 0

Re: [PATCH 2/2] d3dx9: Test penultimate declaration element in D3DXDeclaratorFromFVFTest.
by James Mckenzie 07 Jul '10

07 Jul '10

Alexandre Julliard <julliard(a)winehq.org> wrote: >James McKenzie <jjmckenzie51(a)earthlink.net> writes: > >> Misha Koshelev wrote: >>> --- >>> dlls/d3dx9_36/tests/mesh.c | 6 +++--- >>> 1 files changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c >>> index a2fb6d8..2952e23 100644 >>> --- a/dlls/d3dx9_36/tests/mesh.c >>> +++ b/dlls/d3dx9_36/tests/mesh.c >>> @@ -262,7 +262,7 @@ static void D3DXDeclaratorFromFVFTest(void) >>> if (hr == D3D_OK) >>> { >>> - for (i=0; i<4; i++) >>> + for (i=0; i<5; i++) >>> >> I don't know about everyone else here, but I prefer to use less than >> or equal to, which I think is what was intended here. This >> positively states the upper bound, which is what I was taught in >> programming classes a long time ago (when ANSI C was still 89...) >> >> Thus this would be >> >> for (i=0; i<=4; i++) > >There's no reason that this would be any better. Please don't give >advice based on folklore you heard in programming classes. > That 'folklore' is called a best practice for programming in 'c'. Maybe things have changed since 1995, but I don't think this is one of them. However, each programmer has their own programming 'style'. They are neither right/wrong, but some are actually better than others. I could really 'bitch' about some of the tests, but this is not the place to do so, nor would it advance this project. I was trying to hand out advice, which YOU obviously think is wrong. Sorry, but I have book to back me up, it is called "Programming in ANSI C" and is dated in 1994. James McKenzie

1 0

Re: [PATCH 1/2] d3dx9: Fix indentation in D3DXDeclaratorFromFVFTest. (try 4)
by James Mckenzie 07 Jul '10

07 Jul '10

Misha Koshelev <misha680(a)gmail.com> wrote: > >Ok per Dan's comments back to <last as this looks nicer. > Misha: Alexandre rejects 'white space' changes, that is changes that fix indentation, remove extraneous or trailing spaces and tabs unless there is another change needed. If there is a needed change in this file, go ahead and fixup white space around the change. Otherwise, hold onto this change in case you need to use it in the future. Your other change was accepted by Alexandre and was committed. James McKenzie

1 0

Re: kernel32 translation
by Gustavo 07 Jul '10

07 Jul '10

Em 7 de julho de 2010 05:36, Michael Stefaniuc <mstefani(a)redhat.com> escreveu: > Hello Gustavo, > > Gustavo wrote: >> I'm approaching 100% of translation of wine to Brazilian Portuguese :D > Cool, great job! > >> As can be seen in wine statistics, the MESSAGE #1 from dlls/kernel32 in >> Brazilian Portuguese is actually translated in European Portuguese. As I >> can see, only the "default sublanguages" languages have that file >> translated, so it is supposed to stay that way, isn't it? > Not really. LANG_PORTUGUESE, SUBLANG_PORTUGUESE is the NEUTRAL form not > DEFAULT. DEFAULT sublang for Portuguese is SUBLANG_PORTUGUESE_BRAZILIAN. > You can see it on > http://source.winehq.org/transl/resfile.php?lang=016%3A01&resfile=dlls%2Fke… > "resource MESSAGE #1: Translation inherited from Portuguese (Neutral)" > > If the pt_BR translation of those messages is different you can copy > winerr_ptg.mc to winerr_ptb.mc and adapt it for > SUBLANG_PORTUGUESE_BRAZILIAN. The magic number for pt_BR is: > LanguageNames=(PTB=0x0116:winerr) Ok, I understand, but wouldn't it be 0x0416? That's what it says in locale_rc.rc: #include "nls/ptb.nls" /* 0x0416 LANG_PORTUGUESE, SUBLANG_PORTUGUESE_BRAZILIAN */

3 5

Re: [PATCH 1/2] d3dx9: Fix indentation in D3DXDeclaratorFromFVFTest. (try 3)
by Frédéric Delanoy 07 Jul '10

07 Jul '10

On Wed, Jul 7, 2010 at 15:55, Misha Koshelev <misha680(a)gmail.com> wrote: > Ok, sorry, fixed per Henri's _and_ James' comments. > > Misha > > p.s. If I can ask for a _huge_ favor, I read wine-devel online and I guess I miss some of the messages. If you guys wouldn't mind > cc'ing me on my patches just in case much appreciated. Thx. > --- > dlls/d3dx9_36/tests/mesh.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c > index 8e4e26d..a2fb6d8 100644 > --- a/dlls/d3dx9_36/tests/mesh.c > +++ b/dlls/d3dx9_36/tests/mesh.c > @@ -269,7 +269,7 @@ static void D3DXDeclaratorFromFVFTest(void) > ok(decl[i].Method == exp1[i].Method, "Returned method %d, expected %d\n", decl[i].Method, exp1[i].Method); > ok(decl[i].Usage == exp1[i].Usage, "Returned usage %d, expected %d\n", decl[i].Usage, exp1[i].Usage); > ok(decl[i].UsageIndex == exp1[i].UsageIndex, "Returned usage index %d, expected %d\n", decl[i].UsageIndex, exp1[i].UsageIndex); > - ok(decl[i].Offset == exp1[i].Offset, "Returned offset %d, expected %d\n", decl[1].Offset, exp1[i].Offset); > + ok(decl[i].Offset == exp1[i].Offset, "Returned offset %d, expected %d\n", decl[1].Offset, exp1[i].Offset); > } > ok(decl[5].Stream == 0xFF, "Returned too long vertex declaration\n"); /* end element */ > } > -- > 1.7.1 Formatting-only patches are not accepted by AJ. See http://wiki.winehq.org/DeveloperFaq#head-1e5a50563dbdb221702cbde246b23f5de0… Frédéric

1 0

Re: shlwapi/tests: set last error like Win7
by Alexandre Julliard 07 Jul '10

07 Jul '10

André Hentschel <nerv(a)dawncrow.de> writes: > This only applies to SHFormatDateTimeA, not to SHFormatDateTimeW... There's no reason to do this. 0 is not a valid last error anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] d3dx9: Fix indentation in D3DXDeclaratorFromFVFTest. (try 4)
by Marcus Meissner 07 Jul '10

07 Jul '10

On Wed, Jul 07, 2010 at 10:28:17AM -0500, Misha Koshelev wrote: > Ok per Dan's comments back to <last as this looks nicer. > > This is my last try on these patches unless I hear from Alexandre. > > Misha > --- > dlls/d3dx9_36/tests/mesh.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c > index 8e4e26d..a2fb6d8 100644 > --- a/dlls/d3dx9_36/tests/mesh.c > +++ b/dlls/d3dx9_36/tests/mesh.c > @@ -269,7 +269,7 @@ static void D3DXDeclaratorFromFVFTest(void) > ok(decl[i].Method == exp1[i].Method, "Returned method %d, expected %d\n", decl[i].Method, exp1[i].Method); > ok(decl[i].Usage == exp1[i].Usage, "Returned usage %d, expected %d\n", decl[i].Usage, exp1[i].Usage); > ok(decl[i].UsageIndex == exp1[i].UsageIndex, "Returned usage index %d, expected %d\n", decl[i].UsageIndex, exp1[i].UsageIndex); > - ok(decl[i].Offset == exp1[i].Offset, "Returned offset %d, expected %d\n", decl[1].Offset, exp1[i].Offset); > + ok(decl[i].Offset == exp1[i].Offset, "Returned offset %d, expected %d\n", decl[1].Offset, exp1[i].Offset); In general whitespace changes have nearly no chance of acceptance. Especially in this late RC phase of 1.2. Fix whitespace issues in code you change, leave it alone otherwise. Ciao, Marcus

1 0

Re: sane.ds: Change "ns" to "ms" in resource files
by Alexandre Julliard 07 Jul '10

07 Jul '10

Ken Sharp <kennybobs(a)o2.co.uk> writes: > Apparently the English resource file should show "ms" (microseconds) > instead of "ns". This error has been copied too all the .rc files. "ms" doesn't mean microseconds. -- Alexandre Julliard julliard(a)winehq.org

4 6

bug or feature: libd3dx9.cross.a
by Misha Koshelev 07 Jul '10

07 Jul '10

Dear All: I have run into another slight issue and, as this may affect others, was wondering whether or not I am (i) doing something wrong or (ii) this is something that should be corrected (in that case I am happy to submit a patch but need a bit of guidance as to where this could be fixed as I could not immediately find it). Specifically, if I do, from the main Wine source directory: cd dlls/d3dx9_36/ make clean; make I get all files _except_ libd3dx9.cross.a, resulting in a dangling symlink in the dlls directory and a mysterious failure when doing: cd dlls/d3dx9_36/tests rm *.exe; make crosstest ../../../tools/winegcc/winegcc -b i586-mingw32msvc -B../../../tools/winebuild --sysroot=../../.. --lib-suffix=.cross.a asm.cross.o core.cross.o effect.cross.o line.cross.o math.cross.o mesh.cross.o shader.cross.o surface.cross.o rsrc.res testlist.cross.o -o d3dx9_36_crosstest.exe -ld3dx9 -ld3d9 -luser32 -lgdi32 -lkernel32 -L./lib32 /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/bin/ld: cannot find -ld3dx9 collect2: ld returned 1 exit status winegcc: i586-mingw32msvc-gcc failed make: *** [d3dx9_36_crosstest.exe] Error 2 However, if I simply do cd dlls/d3dx9_36/ make libd3dx9.cross.a All is well. Is this a bug or feature? It seems un-user friendly for new developers trying to add functions to DLLs. Any good way to fix? Thx Misha

1 0

Re: [PATCH 2/2] d3dx9: Test penultimate declaration element in D3DXDeclaratorFromFVFTest.
by James McKenzie 07 Jul '10

07 Jul '10

Misha Koshelev wrote: > --- > dlls/d3dx9_36/tests/mesh.c | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/dlls/d3dx9_36/tests/mesh.c b/dlls/d3dx9_36/tests/mesh.c > index a2fb6d8..2952e23 100644 > --- a/dlls/d3dx9_36/tests/mesh.c > +++ b/dlls/d3dx9_36/tests/mesh.c > @@ -262,7 +262,7 @@ static void D3DXDeclaratorFromFVFTest(void) > > if (hr == D3D_OK) > { > - for (i=0; i<4; i++) > + for (i=0; i<5; i++) > I don't know about everyone else here, but I prefer to use less than or equal to, which I think is what was intended here. This positively states the upper bound, which is what I was taught in programming classes a long time ago (when ANSI C was still 89...) Thus this would be for (i=0; i<=4; i++) James McKenzie

2 1

one more git trick - how to add (try x) automatically?
by Misha Koshelev 07 Jul '10

07 Jul '10

Any hints. Since I'll probably be trying more than once for patches, good to know. Thank you! Misha

1 0

Should include files be bug for bug compatible?
by Dylan Smith 07 Jul '10

07 Jul '10

In richedit.h CHARFORMAT2[AW] is padded differently on the Windows PSDK depending on whether it is included for a c or c++ source file. Should the include file be fixed, or does bug for bug compatibility mean that a correct CHARFORMAT2 structure should be declared in a private include file? I tried compiling the following test program using the PSDK: /* source code */ #include <stdio.h> #include <windows.h> #include <richedit.h> int main() { printf("sizeof(CHARFORMAT2W) %d\n", sizeof(CHARFORMAT2W)); printf("FIELD_OFFSET(CHARFORMAT2W, wWeight) %d\n", FIELD_OFFSET(CHARFORMAT2W, wWeight)); printf("FIELD_OFFSET(CHARFORMAT2W, sSpacing) %d\n", FIELD_OFFSET(CHARFORMAT2W, sSpacing)); return 0; } /* end of code */ The compiled c version gives the following output: sizeof(CHARFORMAT2W) 116 FIELD_OFFSET(CHARFORMAT2W, wWeight) 90 FIELD_OFFSET(CHARFORMAT2W, sSpacing) 92 The c++ version gives the following output: sizeof(CHARFORMAT2W) 116 FIELD_OFFSET(CHARFORMAT2W, wWeight) 92 FIELD_OFFSET(CHARFORMAT2W, sSpacing) 94 Those are the only two fields that are affected, so the inconsistency has gone unnoticed until now. According to the About Rich Edit Controls page (http://msdn.microsoft.com/en-us/library/bb787873(VS.85).aspx) Windows has used a C++ code base since richedit 2.0, and so all the richedit DLLs should follow the c++ version of CHARFORMAT2 since riched32.dll is just a wrapper around riched20.dll for richedit 1.0 emulation. Wine's include file will compile like the c version, which caused some weird behaviour that I noticed when improving the EM_SETCHARFORMAT tests.

2 1

d3d9/tests: Add test for surface format conversion
by Bjørnar Hansen 07 Jul '10

07 Jul '10

On Mon, Jul 5, 2010 at 21:37, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > The DirectX9 SDK "Blobs" sample needs it. It creates a R32F surface, stretches > to a R16F and then uses it for drawing. Later on I realized that DirectX9 > cards(at least my GF7400) don't support R16F, so the sample uses the original > R32F surface for rendering. DirectX10 cards support R16F however, it would be > interesting to see how this sample reacts to that. > On a Windows XP machine with a ATI HD 4870 graphics card, D3DERR_INVALIDCALL was returned so I assumed it was an invalid call... On Mon, Jul 5, 2010 at 21:23, Henri Verbeet <hverbeet(a)gmail.com> wrote: > You're supposed to call IDirect3D9_CheckDeviceFormatConversion() to > determine which conversions are supported. > Currently, that method always returns OK. Seems pointless to use it, but I've implemented it in my revised patch. Looking at [1], should we test for all combinations of source/target formats? The frameranger demo [2] triggers conversions from D3DFMT_A16B16G16R16F to D3DFMT_A8R8G8B8, which is, according to the Microsoft reference, not a valid conversion. I created a test for this, and it successfully executes on Windows XP. What's with that? [1] http://doc.51windows.net/Directx9_SDK/?url=/directx9_sdk/graphics/reference… [2] http://www.pouet.net/prod.php?which=53647

2 3

Re: mapi32: Add Gaelic resource (try4)
by Paul Vriens 07 Jul '10

07 Jul '10

On 07/06/2010 08:45 PM, Ken Sharp wrote: > Works fine here, but I've changed the encoding of the patch to see if > that helps. > Hi Ken, This one is even worse: ../../../wine-git/dlls/mapi32/Ga.rc:32:87: Error: Invalid character in string 'R-phost a sheoladh mar a theip n� g� duit a cliant r�omhphoist MAPI shuite�il.' for codepage 65001 make[1]: *** [Ga.res] Error 1 make[1]: Leaving directory `/wine/wine64/dlls/mapi32' make: *** [dlls/mapi32] Error 2 You've changed the encoding of the file but left in the pragma. The problem with applying was not with Ga.rc but with the changes to Makefile.in -- Cheers, Paul.

4 5

Re: [PATCH] ntdll: Fix QueryVirtual information on builtin DLLs
by Alexandre Julliard 07 Jul '10

07 Jul '10

Marcus Meissner <marcus(a)jet.franken.de> writes: > @@ -1404,9 +1406,20 @@ static void load_builtin_callback( void *module, const char *filename ) > builtin_load_info->status = STATUS_INVALID_IMAGE_FORMAT; > return; > } > - virtual_create_system_view( module, nt->OptionalHeader.SizeOfImage, > - VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED | > - VPROT_READ | VPROT_WRITECOPY | VPROT_EXEC ); > + sec = (IMAGE_SECTION_HEADER*)((char*)&nt->OptionalHeader+nt->FileHeader.SizeOfOptionalHeader); > + /* This view creation is for the sake of NtQueryVirtualMemory, the data is mapped already by dlopen. */ > + for (i=0;i<nt->FileHeader.NumberOfSections;i++) { > + DWORD flags = VPROT_SYSTEM | VPROT_IMAGE | VPROT_COMMITTED; > + > + if (sec[i].Characteristics & IMAGE_SCN_MEM_EXECUTE) flags |= VPROT_EXEC; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_READ) flags |= VPROT_READ; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_WRITE) flags |= VPROT_WRITE; > + if (sec[i].Characteristics & IMAGE_SCN_MEM_SHARED) flags |= VPROT_WRITECOPY; > + /* The section handling is incomplete for real PE binaries/dlls, but is sufficient > + * for the builtin ones generated by Wine */ > + virtual_create_system_view( (char*)module + sec[i].VirtualAddress, sec[i].Misc.VirtualSize, flags ); > + > + } You can't do that, it needs to be a single view. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH] riched20: Process WM_GETMINMAXINFO which arrives before WM_NCCREATE.
by Dmitry Timoshkov 07 Jul '10

07 Jul '10

Austin Lund <austin.lund(a)gmail.com> wrote: > --- a/dlls/riched20/editor.c > +++ b/dlls/riched20/editor.c > @@ -4406,7 +4406,7 @@ static LRESULT RichEditWndProc_common(HWND hWnd, UINT msg, WPARAM wParam, > texthost = ME_CreateTextHost(hWnd, pcs, FALSE); > return texthost != NULL; > } > - else if (msg != WM_NCDESTROY) > + else if ((msg != WM_NCDESTROY) && (msg != WM_GETMINMAXINFO)) > { > ERR("called with invalid hWnd %p - application bug?\n", hWnd); > return 0; This code is completely broken. An app can decide to not even pass these messages to a subclassed richedit control. -- Dmitry.

3 5

kernel32 translation
by Gustavo 07 Jul '10

07 Jul '10

Hello, I'm approaching 100% of translation of wine to Brazilian Portuguese :D As can be seen in wine statistics, the MESSAGE #1 from dlls/kernel32 in Brazilian Portuguese is actually translated in European Portuguese. As I can see, only the "default sublanguages" languages have that file translated, so it is supposed to stay that way, isn't it? Cheers, Gustavo.

2 1

Re: fusion: Implement IAssemblyNameImpl_GetDisplayName more completely
by Nikolay Sivov 07 Jul '10

07 Jul '10

On 7/7/2010 03:04, Owen Rudge wrote: > This should have been sent with my earlier fusion patch. It provides a > more complete implementation of IAssemblyNameImpl_GetDisplayName, and > is also required to fix the slow DirectX installer bug (22774). > > --- > dlls/fusion/Makefile.in | 2 +- > dlls/fusion/asmname.c | 134 > +++++++++++++++++++++++++++++++++++++++---- > dlls/fusion/tests/asmname.c | 96 +++++++++++++++++++++++++++++-- > 3 files changed, 215 insertions(+), 17 deletions(-) Hi, Owen. Won't be a sprintfW enough for that?

1 0

Re: ntdll: Tests for i386 system service requests (Int 2E and SYSENTER) (try 2)
by testbot＠testbot.winehq.org 07 Jul '10

07 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3197 Your paranoid android. === W7PROX64 (32 bit exception) === Timeout

1 0

one more legal/protocol question
by Misha Koshelev 07 Jul '10

07 Jul '10

Dear All: I may be mistaken, but it appears that the constants used for D3DX Mesh Options: http://msdn.microsoft.com/en-us/library/bb205746%28v=VS.85%29.aspx are not yet present in Wine. For example, in the main Wine source directory the command: find . -name \*.h -exec grep D3DXMESH_32BIT {} \; does not return any results. I would like to add these constants. My question: Can I simply 1) look at the relevant DirectX 9 Microsoft .h files and add the constants (rewriting of course not copy paste) from there? or 2) do I have to do something more complicated? Thank you Misha

3 3

Re: fusion: Implement IAssemblyNameImpl_GetDisplayName more completely
by testbot＠testbot.winehq.org 07 Jul '10

07 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3196 Your paranoid android. === W2K3R2SESP2 (32 bit asmname) === asmname.c:738: Test failed: Expected "wine, processorArchitecture=x86", got "wine" asmname.c:739: Test failed: Expected 32, got 5 asmname.c:751: Test failed: Expected "wine, processorArchitecture=AMD64", got "wine" asmname.c:752: Test failed: Expected 34, got 5 asmname.c:764: Test failed: Expected "wine, processorArchitecture=IA64", got "wine" asmname.c:765: Test failed: Expected 33, got 5 asmname.c:777: Test failed: Expected "wine, processorArchitecture=MSIL", got "wine" asmname.c:778: Test failed: Expected 33, got 5

1 0

Re: ntdll: Tests for i386 system service requests (Int 2E and SYSENTER)
by testbot＠testbot.winehq.org 07 Jul '10

07 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3194 Your paranoid android. === WNT4WSSP6 (32 bit exception) === No test summary line found === W7PROX64 (32 bit exception) === Timeout

1 0

Update - no wine repo on github
by Misha Koshelev 07 Jul '10

07 Jul '10

Fyi I am just going to keep my latest patches here: http://www.mkosh.com/wine-d3dx9.zip I have struggled for an hour trying to remove a remote commit on github, and that's an hour I'd rather spend implementing D3DX functions. Anyway sorry for the mailbox clutter :) Misha

2 6

Re: [2/2] shell32/tests: CommandLineToArgvW("") shouldn't truncate returned exe path.
by testbot＠testbot.winehq.org 07 Jul '10

07 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3190 Your paranoid android. === W7PROX64 (64 bit shlexec) === shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt7045.tmp\test file.sde", null, null) failed: rc=29 err=2

1 0

Re: shlwapi/tests: set last error like Win7
by testbot＠testbot.winehq.org 07 Jul '10

07 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3187 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:593: Test failed: GetShellSecurityDescriptor should fail ordinal.c:616: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1766: Test failed: got 28 ordinal.c:1816: Test failed: got 28 ordinal.c:1824: Test failed: got 28 ordinal.c:1832: Test failed: got 39, length 40 ordinal.c:1843: Test failed: got 42 === W7PROX64 (32 bit ordinal) === ordinal.c:1760: Test failed: got 9 ordinal.c:1766: Test failed: got 24 ordinal.c:1781: Test failed: got 6 ordinal.c:1794: Test failed: got 9 ordinal.c:1802: Test failed: got 9 ordinal.c:1816: Test failed: got 24 ordinal.c:1824: Test failed: got 24 ordinal.c:1854: Test failed: got 18 ordinal.c:1865: Test failed: got 21

1 0

ok sorry dumb question... running make test with native DLLs
by Misha Koshelev 06 Jul '10

06 Jul '10

I am now trying to debug the exact parameters D3DXCreateBox uses in its call to D3DXCreateMesh to create its mesh. I would like to run make test with a native DLL. I have tried both: * using winecfg to set native overrides * WINEDLLOVERRIDES="d3dx9_36=n" make test but neither seems to do the trick. Any hints appreciated. Thank you Misha

3 5

kernel32: Update Welsh resource
by Ken Sharp 06 Jul '10

06 Jul '10

Could someone take a look at this for me? http://source.winehq.org/patches/data/63232 It applies fine here but http://source.winehq.org/patches/ says it fails. I can't see what's wrong. :( Thanks.

3 3

Re: [PATCH 2/2] d3dx9: Test penultimate declaration element in D3DXDeclaratorFromFVFTest.
by Henri Verbeet 06 Jul '10

06 Jul '10

Should probably use the size of the expected declaration anyway.

1 0

Re: [2/5] d3d9: Skip YUV tests when encountering a broken driver
by Alexandre Julliard 06 Jul '10

06 Jul '10

Stefan Dösinger <stefan(a)codeweavers.com> writes: > Using win_skip this time It fails here: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:7975: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests visual.c:10076: Test failed: Windows driver confuses U and V channels, skipping test make[1]: *** [visual.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [4/5] d3d9: Accept the d3d10 fog+sRGB behavior as broken
by Henri Verbeet 06 Jul '10

06 Jul '10

On 6 July 2010 14:53, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + * DirectX9 cards return 0.5, DirectX10 cards return 0.73. Some games(Half Life 2 based ones > + * specifically) need the DX9 behavior. DX10 Windows drivers apparently have a quirk for HL2. Wine > + * emulates the DX9 behavior, this tests accepts the DX10 behavior with broken(). It's really HL2 that's broken then, I don't think it would be unreasonable for wined3d to adapt the newer behaviour on appropriate cards in the future.

2 4

Re: WineD3D: Only perform sRGB write correction on formats that advertise it
by Henri Verbeet 06 Jul '10

06 Jul '10

IMO this should be deferred.

2 1

Re: sane.ds: Add Welsh resource
by Huw Davies 06 Jul '10

06 Jul '10

On Mon, Jul 05, 2010 at 06:51:36PM +0100, Ken Sharp wrote: > +{ > + 0 "" > + 1 "px" > + 2 "b" /* What is "b" ? */ > + 3 "mm" > + 4 "dpi" /* dotiau fesul modfedd */ > + 5 "%" > + 6 "ns" /* What is "ns" ? */ > +} See the SANE_UNIT_ defines in /usr/include/sane/sane.h 'b' is bits and 'ns' should be microseconds, so it looks like the English resource is incorrect too. Huw. PS Happy to see the Welsh translations coming in!

2 1

Re: mapi32: Add Gaelic resource (try2)
by Paul Vriens 06 Jul '10

06 Jul '10

On 07/05/2010 07:38 PM, Ken Sharp wrote: > > Hi Ken, Next to fixing the apply failure you should also add the "#pragma code_page(65001)" statement to avoid these warnings: Warning: string "R-phost a sheoladh mar a theip ní gá duit a cliant ríomhphoist MAPI shuiteáil." seems to be UTF-8 but codepage 1252 is in use. Warning: string "Seol Ríomhphost" seems to be UTF-8 but codepage 1252 is in use. -- Cheers, Paul.

2 1

base addresses of kernel32
by Илья Басин 06 Jul '10

06 Jul '10

One widely used dll injection technique is copying the dll path to the target process memory and calling CreateRemoteThread() using the address of LoadLibraryA as lpStartAddress. This relies on the fact that all processes have the same base address of kernel32.dll (and some other system dlls). On Wine only ntdll is always loaded to the same base address, so it's potentially possible to do the same for kernel32, right?

6 9

Re: shlwapi: Partially implement SHGetShellKey (try4)
by testbot＠testbot.winehq.org 06 Jul '10

06 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3178 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:594: Test failed: GetShellSecurityDescriptor should fail ordinal.c:617: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1766: Test failed: got 26 ordinal.c:1816: Test failed: got 26 ordinal.c:1824: Test failed: got 26 ordinal.c:1832: Test failed: got 37, length 38 ordinal.c:1843: Test failed: got 40 === W7PROX64 (64 bit ordinal) === ordinal.c:1760: Test failed: got 10 ordinal.c:1781: Test failed: got 7 ordinal.c:1794: Test failed: got 10 ordinal.c:1802: Test failed: got 10 ordinal.c:1832: Test failed: got 32, length 33 ordinal.c:1843: Test failed: got 35 ordinal.c:1854: Test failed: got 19 ordinal.c:1865: Test failed: got 22

2 1

back from Russia... learning d3dx9
by Misha Koshelev 06 Jul '10

06 Jul '10

Hi All: Just wanted to let y'all know you seem to have great progress towards wine 1.2. I am eagerly awaiting its release so that I can start submitting more patches. Meanwhile, I am learning background material for D3DX9. Along with the wonderful book Dan recommended: http://www.d3dcoder.net/d3d9c.aspx I have also found a very useful tutorial: http://www.directxtutorial.com/ Additionally, if anyone is curious as to how to compile DirectX 9.0 applications using MingW, I have found the following command to be useful: i586-mingw32msvc-g++ test.cpp -o test.exe -fcheck-new -Idxsdk/DXSDK/Include -ld3d9 dxsdk/DXSDK/Lib/x86/d3dx9.lib This assumes that one downloads the DirectX SDK June 2010 version from: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=302… You will have a file named: DXSDK_June10.exe To extract: cd placewhereyoursourcefilesare mkdir dxsdk cd dxsdk cabextract /pathtofile/DXSDK_June10.exe In any case, good luck with getting closer to 1.2 release! Misha p.s. As was the case when I previously worked on wine, I am setting up a copy of Windows 98 for crosstest checks. I am not sure this is strictly necessary (I use XP 64 VMWared as my main crosstest version) - or that DirectX 9 will even work in this version (although it says so per web site), but in any case better safe than sorry.

3 4

Re: [PATCH] riched20: Process WM_GETMINMAXINFO which arrives before WM_NCCREATE.
by James Mckenzie 06 Jul '10

06 Jul '10

Austin Lund <austin.lund(a)gmail.com> wrote: >Subject: [PATCH] riched20: Process WM_GETMINMAXINFO which arrives before WM_NCCREATE. > > Austin: Does this solve a regression bug? If not this will have to wait until Wine 1.2 is released. Also, a conformance test that demonstrates this is what Windows does helps a great deal. James McKenzie

1 0

Re: shlwapi: Partially implement SHGetShellKey (try3)
by testbot＠testbot.winehq.org 06 Jul '10

06 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3171 Your paranoid android. === W2KPROSP4 (32 bit ordinal) === ordinal.c:599: Test failed: GetShellSecurityDescriptor should fail ordinal.c:622: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1771: Test failed: got 26 ordinal.c:1821: Test failed: got 26 ordinal.c:1829: Test failed: got 26 ordinal.c:1837: Test failed: got 37, length 38 ordinal.c:1848: Test failed: got 40 === W7PROX64 (64 bit ordinal) === ordinal.c:1765: Test failed: got 10 ordinal.c:1786: Test failed: got 7 ordinal.c:1799: Test failed: got 10 ordinal.c:1807: Test failed: got 10 ordinal.c:1837: Test failed: got 32, length 33 ordinal.c:1848: Test failed: got 35 ordinal.c:1859: Test failed: got 19 ordinal.c:1870: Test failed: got 22

1 0

Have we finalized the gecko version for 1.2?
by Scott Ritchie 06 Jul '10

06 Jul '10

I'm wondering if I'll need to update the gecko packages too. Thanks, Scott Ritchie

2 1

Re: mapi32: Add Gaelic resource (try2)
by Paul Vriens 06 Jul '10

06 Jul '10

On 07/05/2010 07:38 PM, Ken Sharp wrote: > > Hi Ken, This is what I get when applying the patch: patching file dlls/mapi32/Ga.rc patching file dlls/mapi32/Makefile.in Hunk #1 FAILED at 19. 1 out of 1 hunk FAILED -- saving rejects to file dlls/mapi32/Makefile.in.rej Is your Git up-to-date (I'm not seeing Hu.rc in your patchfile for example and that was added 2 weeks ago). -- Cheers, Paul.

1 0

Re: d3d9/tests: Add test for surface format conversion
by Henri Verbeet 06 Jul '10

06 Jul '10

On 5 July 2010 20:47, Bjørnar Hansen <tilbjornar(a)gmail.com> wrote: > This adds a test of the surface format conversion implemented in > wined3d/surface_base.c. > You're supposed to call IDirect3D9_CheckDeviceFormatConversion() to determine which conversions are supported.

3 4

re: back from Russia... learning d3dx9
by Dan Kegel 06 Jul '10

06 Jul '10

Misha wrote: > This assumes that one downloads the DirectX SDK June 2010 version from: > http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=302… I have a winetricks verb dxsdk_nov2006 (I wanted to get a pure directx 9 version), does that do as well for you? If not, send a patch for winetricks to add the new sdk...

1 1

Re: xinput1_3: Quiet a noisy fixme
by Roderick Colenbrander 05 Jul '10

05 Jul '10

Yeah, this is the correct fix for this horribly broken API (did quite a bit of xinput hacking recently). There is no call to query what joysticks are available since the API was designed to allow you to plug in a joystick while you are playing a game. Games just use XInputGetState (which retrieves the state of axis/buttons) all the time to poll whether a user plugged in a joystick. We might want to have something similar in XInputGetKeystroke / XInputGetCapabilities later on if games still use them (not all calls are exported in all xinput versions). Roderick On Mon, Jul 5, 2010 at 3:42 PM, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > this one gets spawned a few times per second thus flooding the console, running the Resident Evil BenchMark > > > > > > >

1 0

Re: [2/5] d3d9: The depth clamp test fails on Nvidia Windows drivers
by Stefan Dösinger 05 Jul '10

05 Jul '10

I tried a lot of things, and I couldn't get these tests working on this box(gf9600,win7 x86). d3drs_clipping doesn't do what the test expects, in either d3d version. If anyone knows what's wrong feel free to bring up a better solution. I also can't get pop3d working on this system to see if the game that needed the original clipping hack. renders properly. If I had to guess the Nv driver probably runs things through some d3d9->d3d10 mapper provided by ms. That could explain why nv d3d10 setups fail but d3d9 ones work. Wrt ddraw/d3d8, I'd prefer to get the d3d9 testsuite working on my box first. Currently I get thousands of test failures, making development of new bugfixes pretty much impossible. I'll take care of ddraw/d3d8 too, but first i want to regain the ability to write new tests. Henri Verbeet <hverbeet(a)gmail.com> schrieb: >I'm not sure blindly marking these as broken is the way to go. Either >way, ddraw and d3d8 have the same failure. >

2 2

re: Yagmark and localized Windows
by Dan Kegel 05 Jul '10

05 Jul '10

I'd love to have yagmark be more internationalized. I did try to use button codes rather than english strings in wisotool, but sometimes it wasn't possible, and sometimes I didn't try hard enough. Not sure if I tried at all in yagmark yet. According to http://www.autohotkey.com/docs/commands/SetTitleMatchMode.htm Autohotkey supports regular expressions, so for the matching strings that can't be changed to button codes, we could list a bunch of alternatives, e.g. Save As|Enregistrer Sous Then the remaining mess is when we have to send a keystroke, we might need a switch statement to decide which keystroke to send based on the language. For the purposes of benchmarking wine, just setting LANG=en_US.UTF-8 solves the problem, but that doesn't help when you're trying to benchmark Windows. - Dan

5 9

Re: shlwapi: Partially implement SHGetShellKey (try2)
by testbot＠testbot.winehq.org 05 Jul '10

05 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3159 Your paranoid android. === W98SE (32 bit ordinal) === Timeout === W2KPROSP4 (32 bit ordinal) === ordinal.c:594: Test failed: GetShellSecurityDescriptor should fail ordinal.c:617: Test failed: returned value is not valid SD No test summary line found === W7PRO (32 bit ordinal) === ordinal.c:1760: Test failed: got 12 ordinal.c:1781: Test failed: got 9 ordinal.c:1794: Test failed: got 12 ordinal.c:1802: Test failed: got 12 ordinal.c:1832: Test failed: got 36, length 37 ordinal.c:1843: Test failed: got 39 ordinal.c:1854: Test failed: got 21 ordinal.c:1865: Test failed: got 24 === W7PROX64 (64 bit ordinal) === ordinal.c:1760: Test failed: got 10 ordinal.c:1766: Test failed: got 23 ordinal.c:1781: Test failed: got 7 ordinal.c:1794: Test failed: got 10 ordinal.c:1802: Test failed: got 10 ordinal.c:1816: Test failed: got 23 ordinal.c:1824: Test failed: got 23 ordinal.c:1854: Test failed: got 19 ordinal.c:1865: Test failed: got 22

1 0

Re: shlwapi: Partially implement SHGetShellKey
by testbot＠testbot.winehq.org 05 Jul '10

05 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3158 Your paranoid android. === W98SE (32 bit ordinal) === ordinal.c:2391: Test failed: got 00000000 ordinal.c:2395: Test failed: got 1010 ordinal.c:2396: Test failed: got 00000000 Timeout === W2KPROSP4 (32 bit ordinal) === ordinal.c:594: Test failed: GetShellSecurityDescriptor should fail ordinal.c:617: Test failed: returned value is not valid SD No test summary line found === W2K8SE (32 bit ordinal) === ordinal.c:2391: Test failed: got 00000000 ordinal.c:2395: Test failed: got 6 ordinal.c:2396: Test failed: got 00000000 === W7PRO (32 bit ordinal) === ordinal.c:1760: Test failed: got 12 ordinal.c:1781: Test failed: got 9 ordinal.c:1794: Test failed: got 12 ordinal.c:1802: Test failed: got 12 ordinal.c:1832: Test failed: got 36, length 37 ordinal.c:1843: Test failed: got 39 ordinal.c:1854: Test failed: got 21 ordinal.c:1865: Test failed: got 24 ordinal.c:2391: Test failed: got 00000000 ordinal.c:2395: Test failed: got 6 ordinal.c:2396: Test failed: got 00000000 === W7PROX64 (32 bit ordinal) === ordinal.c:2391: Test failed: got 00000000 ordinal.c:2395: Test failed: got 6 ordinal.c:2396: Test failed: got 00000000 === W7PROX64 (64 bit ordinal) === ordinal.c:1760: Test failed: got 10 ordinal.c:1766: Test failed: got 23 ordinal.c:1781: Test failed: got 7 ordinal.c:1794: Test failed: got 10 ordinal.c:1802: Test failed: got 10 ordinal.c:1816: Test failed: got 23 ordinal.c:1824: Test failed: got 23 ordinal.c:1854: Test failed: got 19 ordinal.c:1865: Test failed: got 22 ordinal.c:2391: Test failed: got 0000000000000000 ordinal.c:2395: Test failed: got 6 ordinal.c:2396: Test failed: got 0000000000000000

1 0

Re: RFC: Wine API Documentation Proposal
by Peter Davies 05 Jul '10

05 Jul '10

> I don't know about the 'respectability' of SF, but I'm more concerned with the content and who gets to change it. There are folks that may decide to enter incorrect or even bogus information. I would like it if all added information that is not already present in the Wine API be vetted. That means one person enters it and another disassociated person verifies before it goes live. Code already in the API should be considered automatically vetted. I think the speed and freedom provided by wiki is more important than vetting. Most problems would be due to vandalism (easily reverted), people will keep an eye on Recent Changes. If the problem is overwhelming, we will make editing privileges require a grant by an admin on a shall issue basis. Bogus information is a non-issue, people with sufficient knowledge to enter convincing information are not going to be the sort to enter bogus information. Wikipedia has a high level of accuracy despite its openness. Peter

2 1

Re: [4/5] d3d9: Skip YUV tests when encountering a broken driver
by Henri Verbeet 05 Jul '10

05 Jul '10

On 3 July 2010 23:59, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + ok(broken(TRUE), "U and V channels swapped on Non-Windows driver\n"); > + skip("Windows driver confuses U and V channels, skipping test\n"); You should use win_skip().

1 0

Re: [2/5] d3d9: The depth clamp test fails on Nvidia Windows drivers
by Henri Verbeet 05 Jul '10

05 Jul '10

I'm not sure blindly marking these as broken is the way to go. Either way, ddraw and d3d8 have the same failure.

1 0

Re: [1/5] d3d9: Ignore a Windows 7 failure in the d3d9 depth clamp test
by Henri Verbeet 05 Jul '10

05 Jul '10

You might as well just set the initial value to 1.0. Note that this seems to succeed on at least some setups though: http://test.winehq.org/data/4d3aec55ea41cb0f47a9da82de1665ad1b16f3de/win7_W… Also, does this work for the d3d8 version of the test?

1 0

re: Missing romanian characters in some fonts + winetricks feature request
by Dan Kegel 05 Jul '10

05 Jul '10

The right place for winetricks feature requests is the winezeug issue tracker. I've filed http://code.google.com/p/winezeug/issues/detail?id=134 for the eu font update request.

2 2

Re: kernel32.dll: implementation of GetVolumePathNamesForVolumeNameA/W
by Dmitry Timoshkov 05 Jul '10

05 Jul '10

Tuomo Mattila <tuomom(a)ee.oulu.fi> wrote: > +BOOL WINAPI GetVolumePathNamesForVolumeNameA(LPCSTR volumename, LPSTR volumepathname, DWORD buflen, PDWORD returnlen) > +{ > + > + BOOL ret = FALSE; > + WCHAR* volumenameW = 0; > + LPWSTR volumepathnameW = 0; > + > + if (volumename == 0 || volumepathname == 0 || returnlen == 0) > + { > + SetLastError(RPC_X_NULL_REF_POINTER); > + return FALSE; > + } It's a common practice to use NULL for pointers, and not 0. Something tells me that RPC_xxxx error code has nothing to do here, do you have a test case for that? > + memset(volumepathname, 0, buflen); Is there any reason that you zero out the whole 'volumepathname' here? > + volumepathnameW = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, buflen*sizeof(WCHAR)); > + if (volumepathnameW == 0) return FALSE; Same for 'volumepathnameW' here. > + if ((volumenameW = FILE_name_AtoW(volumename, TRUE)) == 0) return FALSE; > + > + ret = GetVolumePathNamesForVolumeNameW(volumenameW, volumepathnameW, buflen, returnlen); > + if (*returnlen > 0) > + FILE_name_WtoA(volumepathnameW, (*returnlen), volumepathname, (*returnlen)); There is no need to put '*returnlen' in braces. Besides, '*returnlen' may differ for multibyte and unicode strings. -- Dmitry.

1 0

Re: libs/wine: get_decomposition is not used in that file
by Dmitry Timoshkov 05 Jul '10

05 Jul '10

André Hentschel <nerv(a)dawncrow.de> wrote: > --- a/libs/wine/sortkey.c > +++ b/libs/wine/sortkey.c > @@ -19,7 +19,6 @@ > */ > #include "wine/unicode.h" > > -extern int get_decomposition(WCHAR src, WCHAR *dst, unsigned int dstlen); > extern const unsigned int collation_table[]; There is a commented out reference to get_decomposition() in that file, so you need to remove it as well. But better make it used, and figure out why it was commented out in the first place. -- Dmitry.

1 0

FAQ on Nautilus needed?
by David Gerard 05 Jul '10

05 Jul '10

http://wiki.winehq.org/FAQ#head-d3f53179ea4e0d7c90cf330e50030b1e14b63811 10.3. Nautilus can delete your home directory when you empty the trash! This affected GNOME 2.21.90-91. This is a rather old version of GNOME. Hass this problem come up in recent times? Is there any current *nix that uses GNOME 2.21.90 or 2.21.91? - d.q

2 1

re: base addresses of kernel32
by Dan Kegel 04 Jul '10

04 Jul '10

>> the Makefile has: >> EXTRADLLFLAGS = -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b800000 > >Is there a good reason for this? Otherwise, this opens a security >vulnerability in Wine that does not exist in Windows.... This is the way Windows worked before Vista. (Does Vista actually randomize where even ntdll is?) BTW our CreateRemoteThread conformance test checks whether the module has been loaded at a different address, and skips if it has...

3 2

Please review: Patch for non-Linux serial set_baud_rate()
by Ken Thomases 04 Jul '10

04 Jul '10

Hi, I happened to stumble across some code which didn't look quite right in dlls/ntdll/serial.c. However, I have no expertise in serial comms or termios. Also, I have no means to test the change I propose. On the other hand, the change seems clearly right and conforms to what I learn from man pages, etc. So, I'm hoping somebody who is more familiar with this functionality can review the attached patch before I formally submit it. Another approach that seems better from my reading of the man pages is to switch to using cfsetspeed() [or cfsetospeed() and cfsetispeed()] instead of having separate branches based on defined(CBAUD). But maybe that has portability problems worse than the current approach. Thanks, Ken

2 2

TRACE () documentation
by James McKenzie 04 Jul '10

04 Jul '10

All: Is there documentation anywhere on how to use the TRACE command? I am trying to print out the contents of a UNICODE string using this commnd. Thank you. James McKenzie

4 8

Re: kernel32: Enhance EndUpdateResource
by testbot＠testbot.winehq.org 04 Jul '10

04 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3105 Your paranoid android. === WNT4WSSP6 (32 bit resource) === No test summary line found

1 0

Missing romanian characters in some fonts + winetricks feature request
by Octavian Voicu 04 Jul '10

04 Jul '10

Hello, Most fonts are missing some characters (S and T with a comma below, as opposed to those with a cedilla; see [1] for a discussion) needed to correctly represent some letters in the Romanian alphabet. Initially, Windows XP did not include support for these characters, but it released an update to fix this once Romania joined the EU. The update [2] contains the fonts Times New Roman, Arial, Trebuchet, Verdana. Winetricks should include a new trick to download this update and install the 16 font files from the package. It would be nice to have something like "corefonts w/ EU update" which would install the fixed fonts + the other core fonts that are not included in this update. There is a small problem caused by the casing of the filenames in this update (Times New Roman, Arial, Verdana filenames have a different casing than the ones on SF.net), so they should be renamed to match the original corefonts names. Also, corefonts should not override the updated EU fonts if it detects them. There is the general problem that most system fonts wine uses are missing these characters, and some characters render incorrectly in dialogs. Most notably, the find/replace dialogs in comdlg32 with ro_RO.utf8 locale are completely broken font-wise: ă and î look bad, ț shows as a question mark. "MS Shell Dlg" font is usually used in dialogs, but it doesn't show up in the font selection dialog, so I'm not sure what font is actually used. Try pasting the following text in notepad/wordpad and try various fonts to see for yourself: ă Ă - a with breve â Â - a with circumflex î Î - i with circumflex ș Ș - s with comma ț Ț - t with comma ş Ş - s with cedilla (obsolete for RO) ţ Ţ - t with cedilla (obsolete for RO) Not sure how this issue could be fixed. Are the fonts we currently use open source, can we edit them? Octavian [1] http://en.wikipedia.org/wiki/Romanian_alphabet#Comma-below_.28.C8.99_and_.C… <http://en.wikipedia.org/wiki/Romanian_alphabet#Comma-below_.28.C8.99_and_.C…> [2] http://www.microsoft.com/downloads/details.aspx?FamilyID=0ec6f335-c3de-44c5… <http://www.microsoft.com/downloads/details.aspx?FamilyID=0ec6f335-c3de-44c5…>

1 0

None
by paulo lesgaz 04 Jul '10

04 Jul '10

Hello As soon as I use Winedbg, the debugger stops at this exception: First chance exception: page fault on write access to 0x00ad0000 in 32-bit code (0x7e96fc9d). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7e96fc9d ESP:0033f7a0 EBP:0033f818 EFLAGS:00010a02( R- --O I - - - ) EAX:80808081 EBX:7ea1a518 ECX:00000000 EDX:00000067 ESI:000000ac EDI:00ad0000 Stack dump: 0x0033f7a0: 0000031c 00000000 00000000 00000010 0x0033f7b0: 00000010 00000000 00000000 00000010 0x0033f7c0: 00000010 7e524eb0 0012bc20 00000000 0x0033f7d0: 00cc0020 00000308 00330001 7e8c0001 0x0033f7e0: 0033f7f8 0000031c 0012c490 00000328 0x0033f7f0: 00000000 00000000 00000010 00000010 Backtrace: =>0 0x7e96fc9d create_alpha_bitmap+0x1cd(color=<is not available>, mask=<is not available>, src_info=0x12bc20, color_bits=0x7e524eb0) [/home/david/wine/dlls/user32/cursoricon.c:771] in user32 (0x0033f8a8) 1 0x7e97077f CURSORICON_CreateIconFromBMI+0x74e(bmi=<is not available>, hotspot={x=0x0008, y=0x0008}, bIcon=0x0001, dwVersion=0x30000, width=0x0010, height=0x0010, cFlag=0x8000) [/home/david/wine/dlls/user32/cursoricon.c:837] in user32 (0x0033f908) 2 0x7e970895 CreateIconFromResourceEx+0xd4(bits="(", cbSize=0x0468, bIcon=0x0001, dwVersion=0x30000, width=0x0010, height=0x0010, cFlag=0x8000) [/home/david/wine/dlls/user32/cursoricon.c:1159] in user32 (0x0033f9c8) 3 0x7e9735e0 CURSORICON_Load+0x6bf(hInstance=0x7e410000, name=<is not available>, width=0x0010, height=0x0010, depth=0x0020, fCursor=0, loadflags=0x8000) [/home/david/wine/dlls/user32/cursoricon.c:1292] in user32 (0x0033fac8) 4 0x7e973b70 LoadImageW+0x1af(hinst=0x7e410000, name=*** invalid address 0x1 ***, type=0x0001, desiredx=0x0010, desiredy=0x0010, loadflags=0x8000) [/home/david/wine/dlls/user32/cursoricon.c:2392] in user32 (0x0033fbb8) 5 0x7e97494e LoadImageA+0x19d(hinst=0x7e410000, name=*** invalid address 0x1 ***, type=0x0001, desiredx=0x0010, desiredy=0x0010, loadflags=0x8000) [/home/david/wine/dlls/user32/cursoricon.c:2333] in user32 (0x0033fc08) 6 0x7e42d8e6 SIC_Initialize+0x1a5() [/home/david/wine/dlls/shell32/iconcache.c:417] in shell32 (0x0033fc48) 7 0x7e4371b2 DllMain+0xb1(hinstDLL=0x7e410000, fdwReason=0x0001, fImpLoad=0x1) [/home/david/wine/dlls/shell32/shell32_main.c:1166] in shell32 (0x0033fc68) 8 0x7ef89d15 call_dll_entry_point+0x14() in ntdll (0x0033fda8) 9 0x7ef8cda3 MODULE_InitDLL+0xe2(wm=0x111858, reason=<is not available>, lpReserved=0x1) [/home/david/wine/dlls/ntdll/loader.c:982] in ntdll (0x0033fe08) 10 0x7ef8d6e0 process_attach+0xbf(wm=0x111858, lpReserved=<is not available>) [/home/david/wine/dlls/ntdll/loader.c:1071] in ntdll (0x0033fe68) 11 0x7ef8d6b2 process_attach+0x91(wm=0x1117a8, lpReserved=<is not available>) [/home/david/wine/dlls/ntdll/loader.c:1063] in ntdll (0x0033fec8) 12 0x7ef8d6b2 process_attach+0x91(wm=0x110a50, lpReserved=<is not available>) [/home/david/wine/dlls/ntdll/loader.c:1063] in ntdll (0x0033ff28) 13 0x7ef8d6b2 process_attach+0x91(wm=0x110690, lpReserved=<is not available>) [/home/david/wine/dlls/ntdll/loader.c:1063] in ntdll (0x0033ff88) 14 0x7ef8d6b2 process_attach+0x91(wm=0x1107b8, lpReserved=<is not available>) [/home/david/wine/dlls/ntdll/loader.c:1063] in ntdll (0x0033ffe8) 15 0x7ef8d8e3 attach_process_dlls+0x52(wm=0x1107b8) [/home/david/wine/dlls/ntdll/loader.c:2541] in ntdll (0x00000000) 0x7e96fc9d create_alpha_bitmap+0x1cd [/home/david/wine/dlls/user32/cursoricon.c:771] in user32: movb %dl,0x0(%edi,%ecx,4) 771 ptr[0] = ptr[0] * alpha / 255; Any way to bypass it? Thanks in advance David

3 2

The annoying FAQ of detecting Wine
by David Gerard 03 Jul '10

03 Jul '10

Unfortunately, this is a FAQ, so I've added it. I based the answer on the last time this came around on wine-users; I'm not a developer, so please sanity-check what I wrote! Hopefully this will be useful in dealing with the actual problems people think they can solve by doing this. http://wiki.winehq.org/FAQ#head-9c045f5ff1df8a1afef91e1152ca7f6a9684f116 8.6. I write a Windows app. How can it detect if it's running under Wine? This is a bad idea. The goal of Wine is that an application will be unable to tell it's running under Wine rather than Windows. So any method to detect running under Wine is unsupported and may break without warning in the future. Wine should not be treated as a "version" of Windows - functionality or performance-tuning is likely to be different between any two development versions. Rather than detecting Wine: * Detect if functionality exists and use it when available. * File a bug if something works in Windows that does not work in Wine. * Ask for help on the developers' list. That said: if you really want to detect Wine, try, e.g., running a native binary or syscall (AppArmor or SELinux may block this), reading the environment, accessing a function (e.g ntdll.get_wine_version() ) or registry key only found in Wine. Any of these may break at any time. Asking the user directly if they are running the app under Wine will be more reliable than trying to automatically detect it. - d.

1 0

FAQ just updated and copyedited
by David Gerard 03 Jul '10

03 Jul '10

Just went through the FAQ, copyediting, tweaking and bringing things into the present: http://wiki.winehq.org/FAQ?action=diff&rev2=347&rev1=346 Please sanity-check :-) - d.

1 0

Why some gdi32 calls aren't caught in relay while some are caught?
by Hayan Lee 03 Jul '10

03 Jul '10

Hi, all I found that WINEDEBUG=+relay works by dlls/ntdll/relay.c and I'm trying to catch function call of dlls. Wine doc says relay supports user32, ntdll, etc, but not gdi32. However when I run wine, some gdi32 calls are caught, e.g, CreateBitmap() But some aren't caught, e.g, CreateBitmapIndirect() --------------------------------------------------------------------------------------------------------- $ WINEDEBU+relay wine notepad.exe trace:bitmap:CreateBitmapIndirect 8x8, 2 colors returning 0x220 [relay_call:12] 000d:Ret gdi32.CreateBitmap() retval=00000220 ret=68849be9 --------------------------------------------------------------------------------------------------------- Both are gdi32 export function. Do you know why? I want to catch all gdi32 function calls. Thanks in advance. Hayan

3 2

Re: shell32/tests: CommandLineToArgvW("") shouldn't truncate returned exe path
by testbot＠testbot.winehq.org 03 Jul '10

03 Jul '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3073 Your paranoid android. === W2K3R2SESP2 (32 bit shlexec) === shlexec.c:195: Test failed: WaitForSingleObject returned 258 shlexec.c:1417: Test failed: argvA3 expected 'Open', got '(null)' shlexec.c:1420: Test failed: argvA4 expected 'C:\WINDOWS\Temp\wt11.tmp\test file.shlexec', got '(null)' shlexec.c:1426: Test failed: argcA expected 4, but got 5 shlexec.c:1427: Test failed: argvA3 expected 'Lnk', got 'Open' shlexec.c:1516: Test failed: argcA expected 4, but got 5 shlexec.c:1517: Test failed: argvA3 expected 'Exec', got 'Lnk' === W7PROX64 (64 bit shlexec) === shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2 shlexec.c:1738: Test failed: ShellExecuteEx(null, "C:\Users\winetest\AppData\Local\Temp\wt2676.tmp\test file.sde", null, null) failed: rc=29 err=2

1 0

Re: patch for fixing the tab change bug
by Austin English 02 Jul '10

02 Jul '10

On Thu, Jul 1, 2010 at 5:20 PM, Matthias Kupfer <matthias.kupfer(a)informatik.tu-chemnitz.de> wrote: > Hi, > > after changing the selected tab, it's impossible to change to another tab with > mouse. This patch fixes this issue, because the SetCurFocus changes selection > (if conditions apply). This patch has caused a regression, please see http://bugs.winehq.org/show_bug.cgi?id=23479. -- -Austin

2 1

Changing sizes of templates in comdlg32
by Gustavo 02 Jul '10

02 Jul '10

I've found the following warning the the file comdlg32: /* * WARNING: DO NOT CHANGE THE SIZE OF THE STANDARD DIALOG TEMPLATES. */ Does that mean that I can't correct the size of the buttons or strings that are wrong in the Portuguese template file? Or is that only a warning for the English file? The "Find" and "Replace" dialogs are specially ugly in Portuguese, I would appreciate to be able to change that.

4 4

Addition of En resources to non-En resources
by Frédéric Delanoy 02 Jul '10

02 Jul '10

Sometimes, when a developer adds a string to En resource file, (s)he adds it as well to all other non-En resource files. Isn't that unnecessary? http://wiki.winehq.org/SublangNeutral says the search order is 1. LANG_NEUTRAL, SUBLANG_NEUTRAL 2. LANG_FRENCH, SUBLANG_FRENCH_BELGIAN 3. LANG_FRENCH, SUBLANG_NEUTRAL 4. LANG_ENGLISH, SUBLANG_ENGLISH_US Would a patch removing En resources in non En rc files be accepted? This would allow for more accurate translation stats. Or doesn't a fallback mechanism always apply? Frédéric

8 25

Re: (Resent) Documentation - Reference to MSDN?
by James Mckenzie 02 Jul '10

02 Jul '10

Alexandre Julliard <julliard(a)winehq.org> wrote: > >Erich Hoover <ehoover(a)mines.edu> writes: > >> Alright, well then I won't do it. Is the existing documentation going >> to be stripped at some point? It seems to me like we would benefit >> from more-detailed function descriptions in the auto-generated API >> documentation. I think it would save a lot of time for new developers >> to get their feet wet if they were able to see directly in the source >> what the different functions are supposed to do (as best as we know) >> and exactly what applications will trigger known edge cases (or if >> there's a test for a given situation). > >That's what the source code and test cases are for. If you rely on the >function documentation you are in trouble anyway, nobody bothers to >update it when new behaviors are discovered. > >If you really want to write good API documentation, as opposed to the >current useless one-sentence-per-parameter description, you'd need >probably a text 10 times the size of the source code for each >function. That can't go in the source files. > How about some place on the Wiki along with an implementation status. That way we can also annotate items that are missing in MSDN (I just re-stumbled across something in my latest Richedit tests) as well. This would help greatly in our progress towards current and future implementations of the Windows API. And I agree, adding all of this to the source would make it unwieldy. James McKenzie

5 7

Re: [1/2] wined3d: unbound texture units should sample black instead of white.
by Stefan Dösinger 02 Jul '10

02 Jul '10

Am Donnerstag 01 Juli 2010 16:54:08 schrieb Fabian Bieler: > - glTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE, 1, 1, 0, GL_LUMINANCE, GL_UNSIGNED_BYTE, &white); > + glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, 1, 1, 0, GL_RGBA, GL_UNSIGNED_INT_8_8_8_8_REV, &black); This will only work if the shader samples 2D textures, or is a 1.x pixel shader. I am afraid you'll have to add bit for no texture being bound to a sampled sampler to the ps_compile_args structure and replace the TEX statement with reading a constant instead. Or explicitly bind dummy 2D, 3D, Cube and RECT textures to unused samplers. (and e.g. a dummy 2D, 3D and RECT sampler if a volume texture is used)

3 3

Re: [PATCH][kernel32.dll] quick and dirty implementation of GetVolumePathNamesForVolumeNameA (try 2)
by James Mckenzie 02 Jul '10

02 Jul '10

Tuomo Mattila <tuomom(a)ee.oulu.fi> wrote: Why not just do the check and then pass it as a Wide to the 'W' function? Simpler and less code to maintain/update? >+ >+ >+ FIXME("(%s, %p, %d, %p), stub!\n", debugstr_a(volumename), volumepathname, buflen, returnlen); If this is not a full implementation, you need to state so, otherwise this goes.... >+ >+ if (volumename == 0 || volumepathname == 0 || returnlen == 0) >+ { >+ SetLastError(RPC_X_NULL_REF_POINTER); >+ return FALSE; >+ } At this point you should convert to Wide/UNICODE and pass to the W function. Pass the return from the W call back to the caller. >+ >+ return TRUE; >+} >+ >+/*********************************************************************** > * GetVolumePathNamesForVolumeNameW (KERNEL32.@) > */ > BOOL WINAPI GetVolumePathNamesForVolumeNameW(LPCWSTR volumename, LPWSTR volumepathname, DWORD buflen, PDWORD returnlen) >-- >1.7.1 > > >

2 1

Documentation - Reference to MSDN?
by Max TenEyck Woodbury 02 Jul '10

02 Jul '10

I've been reading the Wine code and noticed that some of the external interfaces are practically undocumented. I did a web search on some of the names and found descriptions in MSDN. I realize that copying the information from MSDN directly into the code is a poor idea (like copyright violation) so I have a couple of questions: 1) Would including the URL of the MSDN article be useful/a good idea? 2) Would enumerating coded values and flags be allowed? 3) Where should data structures be documented?

3 2

(Resent) Documentation - Reference to MSDN?
by Max TenEyck Woodbury 01 Jul '10

01 Jul '10

I've been reading the Wine code and noticed that some of the external interfaces are practically undocumented. I did a web search on some of the names and found descriptions in MSDN. I realize that copying the information from MSDN directly into the code is a poor idea (like copyright violation) so I have a couple of questions: 1) Would including the URL of the MSDN article be useful/a good idea? 2) Would enumerating coded values and flags be allowed? 3) Where should data structures be documented?

9 17

Creating tests with additional binary modules
by Mariusz Pluciński 01 Jul '10

01 Jul '10

Hi, wine-devel I'm working on implementation of Windows Game Explorer interfaces for Wine. The work is in advanced stage now, but I have problem with implementation of conformance tests. Thing I want to test is loading and parsing so-called Game Definition Files. GDF are not separate files, but stored as resources in binary modules (usually in game's main executable). Using GE interfaces, programmer only needs to pass path to binary, and GE automatically loads and process embedded GDF(s). Checking results of routines execution is not problem for me. But thing I test is parser, so I need to pass various GDF files to routine. And, as GDFs are stored in binaries, I will need to create many binaries. They should be created in compile time and available for test's executable while running it. The problem is that I don't know how to do this using wine's mechanisms. How should Makefile.in file look to build additional executable files properly (they should be probably always native win32 executables, even if parameter "crosstest" wasn't specified)? How should I guarantee that these additional executables will be copied into winetest directory (to make them accessible while executing tests)? Thanks in advance Mariusz Pluciński

5 8

Re: Add support for arguments to -fprofile-* functions.
by André Hentschel 01 Jul '10

01 Jul '10

Hi, sorry, but your patch is a bit ugly... please look at the code below /* determine if tihs switch is followed by a separate argument */ in winegcc.c and understand what it does. specially with next_is_arg, is_linker_arg, .... Also the following is senseless: +int strstartswith(const char * str, const char * start) +{ + return strstr(str, start) == str; +} -- Best Regards, André Hentschel

3 4

Re: [PATCH][kernel32.dll] quick and dirty implementation of GetVolumePathNamesForVolumeNameA (try 2)
by André Hentschel 01 Jul '10

01 Jul '10

Using "quick and dirty" in the subject while code freeze is most likely not to be commited :) -- Best Regards, André Hentschel

1 0

updating spec files - which windows version to use?
by Austin English 01 Jul '10

01 Jul '10

Howdy, I was looking at http://bugs.winehq.org/show_bug.cgi?id=23421, and wanted to add a stub for it. Using winedump on a Windows 7 shlwapi.dll gives different exports than Windows XP SP3 shlwapi.dll. Which dll should the spec file be updated to match? I'm assuming the latest and greatest, since eventually applications will head that direction. An additional related question. Some of the functions that are ordinals in previous Windows versions are now exported (e.g., ParseUrlA/W seems to have been documented/exported since Vista). Should the spec file be adjusted to match the newer behavior? I'm assuming this will have to wait until after 1.2 to be applied... Thanks! Austin

2 1

Re: [tools/wine.desktop] Add czech translation
by Nikolay Sivov 30 Jun '10

30 Jun '10

On 7/1/2010 02:20, Scott Ritchie wrote: > Translation by Sven Augustin > @@ -20,7 +21,12 @@ Name[sr]=Wine - аДаИаЗаАб� Windows аПб�аОаГб�аАаМаА > Name[sr@latin]=Wine - dizaФ� Windows programa > Name[hr]=Wine - dizaФ� Windows programa > Exec=wine start /unix %f > +<<<<<<< HEAD > MimeType=application/x-ms-dos-executable;application/x-msi;application/x-win-lnk;application/x-ms-shortcut > +======= > +MimeType=application/x-ms-dos-executable;application/x-msi;application/x-win-lnk; > +>>>>>>> tools/wine.desktop: add Icon=wine to support systems with an icon theme > Icon=wine > NoDisplay=true > StartupNotify=true > + Conflicts?

2 1

Re: (Resent) Documentation - Reference to MSDN?
by James Mckenzie 30 Jun '10

30 Jun '10

Erich Hoover <ehoover(a)mines.edu> wrote: >Sent: Jun 30, 2010 12:43 PM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Alexandre Julliard <julliard(a)winehq.org>, Max TenEyck Woodbury <max(a)mtew.isa-geek.net>, wine-devel(a)winehq.org >Subject: Re: (Resent) Documentation - Reference to MSDN? > >On Wed, Jun 30, 2010 at 1:36 PM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >> ... >> How about some place on the Wiki along with an implementation status. That way we can also annotate items that are missing in MSDN (I just re-stumbled across something in my latest Richedit tests) as well. This would help greatly in our progress towards current and future implementations of the Windows API. >> >> And I agree, adding all of this to the source would make it unwieldy. >> > >So something like "http://wiki.winehq.org/WineAPI/<DLL>/<Function>" ? >If that's acceptable I would not mind a system like that, especially >if the links of documented functions are provided in the source. >Documenting these things is a lot of work, so I'm not about to run off >and do all that work if no-one is ever going to take advantage of it. > +1 Acceptable variables should be listed in an order other than the one on MSDN. We don't want a direct copy, but rather OUR findings using the old 'black box' method. James McKenzie

1 0

Re: add russian translation for winerrs messages [try2]
by Dmitry Timoshkov 30 Jun '10

30 Jun '10

Vitaly Lipatov <lav(a)etersoft.ru> wrote: > +LanguageNames=(RUS=0x19:winerr) > +CodePages=(FRA=65001:0) 'FRA'? This doesn't look correct. -- Dmitry.

3 3

Re: user32: Recurse into WS_EX_CONTROLPARENT controls in GetDlgItem
by Dmitry Timoshkov 30 Jun '10

30 Jun '10

André Hentschel <nerv(a)dawncrow.de> wrote: > This fixes bug 22862 which blocks bug 12804 (1.2) > We already do a similar recursion in DEFDLG_FindDefButton and GetNextDlgGroupItem > > I didnt found any other changes in the tests... i expected some more "Test succeeded inside todo block" You need to add explicit tests for GetDlgItem() inside of user32/tests. -- Dmitry.

1 0

Re: user32/tests: Use if(0) instead of a comment to make sure code still compiles
by testbot＠testbot.winehq.org 29 Jun '10

29 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3023 Your paranoid android. === W7PRO (32 bit msg) === msg.c:9516: Test failed: wrong qstatus 00110011 msg.c:9523: Test failed: wrong qstatus 00190008 msg.c:9529: Test failed: wrong qstatus 00390020 msg.c:9538: Test failed: wrong qstatus 00790040 msg.c:9559: Test failed: wrong qstatus 00390000 msg.c:9567: Test failed: wrong qstatus 00790040 msg.c:9578: Test failed: wrong qstatus 00390000 msg.c:9589: Test failed: wrong qstatus 00310000 msg.c:9594: Test failed: PeekMessageA should have returned FALSE instead of msg 0113 === W7PROX64 (64 bit msg) === Timeout

1 0

Re: wininet: fix the handling of insufficient buffers in InternetGetCookie*()
by testbot＠testbot.winehq.org 29 Jun '10

29 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=3020 Your paranoid android. === W98SE (32 bit internet) === internet.c:440: Test failed: A=B present internet.c:442: Test failed: E=F present internet.c:444: Test failed: I=J present internet.c:445: Test failed: K=L present internet.c:452: Test failed: A=B present internet.c:454: Test failed: E=F present internet.c:456: Test failed: I=J present internet.c:457: Test failed: K=L present internet.c:1158: Test failed: Retrieved proxy server should've been L"proxy.example", was: L"\0001\a000\2684X\0fb4h\0200" internet.c:1164: Test failed: Expected regtype to be REG_DWORD, was: 3 internet.c:1192: Test failed: Retrieved flags should've been PROXY_TYPE_DIRECT, was: 5767180 internet.c:1195: Test failed: Expected regtype to be REG_DWORD, was: 3 internet.c:1222: Test failed: Retrieved flags should've been PROXY_TYPE_PROXY | PROXY_TYPE_DIRECT, was: 5767180 internet.c:1225: Test failed: Expected regtype to be REG_DWORD, was: 3 === W2KPROSP4 (32 bit internet) === internet.c:440: Test failed: A=B present internet.c:442: Test failed: E=F present internet.c:444: Test failed: I=J present internet.c:445: Test failed: K=L present internet.c:452: Test failed: A=B present internet.c:454: Test failed: E=F present internet.c:456: Test failed: I=J present internet.c:457: Test failed: K=L present === WXPPROSP3 (32 bit internet) === internet.c:517: Test failed: bad last error {error = 122} internet.c:545: Test failed: the function failed internet.c:546: Test failed: bad last error {error = 122} === WVISTAADM (32 bit internet) === internet.c:517: Test failed: bad last error {error = 122} internet.c:545: Test failed: the function failed internet.c:546: Test failed: bad last error {error = 122} === W2K8SE (32 bit internet) === internet.c:517: Test failed: bad last error {error = 122} internet.c:545: Test failed: the function failed internet.c:546: Test failed: bad last error {error = 122} === W7PRO (32 bit internet) === internet.c:474: Test failed: bad last error {error = 5023} internet.c:502: Test failed: bad last error {error = 5023} internet.c:517: Test failed: bad last error {error = 5023} internet.c:545: Test failed: the function failed internet.c:546: Test failed: bad last error {error = 122} === W7PROX64 (32 bit internet) === internet.c:474: Test failed: bad last error {error = 5023} internet.c:502: Test failed: bad last error {error = 5023} internet.c:517: Test failed: bad last error {error = 5023} internet.c:545: Test failed: the function failed internet.c:546: Test failed: bad last error {error = 122} === W7PROX64 (64 bit internet) === internet.c:474: Test failed: bad last error {error = 5023} internet.c:502: Test failed: bad last error {error = 5023} internet.c:517: Test failed: bad last error {error = 5023} internet.c:545: Test failed: the function failed internet.c:546: Test failed: bad last error {error = 122}

1 0

Using string resources in conformance tests.
by Michael Mc Donnell 29 Jun '10

29 Jun '10

Hi wine developers! I've written a conformance test (my first) for bug 17986: BrsFolder_OnCommand make new folder not implemented. The conformance test tests if clicking on the "Make New Folder" button in a SHBrowseForFolder dialog box results in creation of a new folder. I want the test to be localized and work across all newer versions of Windows, but I'm having trouble with it. I use the LoadString function to get the "New folder" string from shell32.dll that is used for creating a new folder. The problem is that the location where it is stored in shell32.dll varies between the different versions of Windows. I can only make the test work on one version at a time. Even the capitalization varies between the different versions of Windows, i.e. "New Folder" vs. "New folder". My question is how should we handle a problem like the one mentioned above? Should we avoid using string resources in conformance test, or should we try to handle the version issues? One solution would be to hard code the string instead of loading it from a resource. This would, however, mean that the test would be skipped on all non-English versions of windows, and it would additionally have to ignore the capitalization differences. Another solution would be to get the string according to the version of Windows. This would, however, pose a problem in wine because it does not emulate any specific Windows version. The location of the string in wine's shell32.dll does not match any version of Windows, and we would therefore also have to detect if the test is running on wine. Has anyone bumped into the same problem, or does anyone know a thread about this on wine-devel? Do you have any comments on what to do? Thanks, Michael Mc Donnell

2 2

Re: [2/2] urlmon: implement HlinkSimpleNavigateToMoniker
by Jacek Caban 29 Jun '10

29 Jun '10

On 6/28/10 9:17 PM, André Hentschel wrote: > --- > dlls/urlmon/umon.c | 8 ++++++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/dlls/urlmon/umon.c b/dlls/urlmon/umon.c > index e122e07..12b1b0c 100644 > --- a/dlls/urlmon/umon.c > +++ b/dlls/urlmon/umon.c > @@ -734,8 +734,12 @@ HRESULT WINAPI HlinkSimpleNavigateToMoniker(IMoniker *pmkTarget, > LPCWSTR szLocation, LPCWSTR szTargetFrameName, IUnknown *pUnk, > IBindCtx *pbc, IBindStatusCallback *pbsc, DWORD grfHLNF, DWORD dwReserved) > { > - FIXME("stub\n"); > - return E_NOTIMPL; > + URLMoniker *This = MONIKER_THIS(iface); You can't do this. There is no guaranty that the moniker is URL moniker. Jacek

1 0

The WINE Project should solicit grants to hire professional developers
by Richard Yao 29 Jun '10

29 Jun '10

Dear All: I am a senior undergraduate applied mathematics/computer science student and this year, I migrated from Windows 7 to Gentoo Linux on my computers. I tried using Linux alternatives to many applications I used on Windows, but not all software has good alternatives, so I have been using WINE for certain things. The WINE project's accomplishments so far have been extremely impressive, but at the same time, WINE's implementation of the Windows API is deficient in many ways and I think that the WINE project will need to improve its own organization before progress toward true API parity with Windows can be made. I can divide WINE's development resources into two groups, volunteer and professional. The volunteer group is predominantly focused on games.The professional group is comprised of CodeWeavers and Google. CodeWeavers does what its customers want it to do, and as such, it has a large focus on games. Google on the other hand, paid CodeWeavers to make some improvements to WINE, mostly for Picasa, but also for Adobe Photoshop CS2, the reason for which I cannot imagine. Google also has its annual Summer of Code program. Each source of manpower has its own special interest and I do not believe that WINE will ever obtain any kind of API parity with Windows as long as this remains the case. With these things in mind, I would like to propose that the WINE project solicit grants from charitable organizations so that it could hire professional developers to augment its existing resources, specifically in the areas for which special interests could care less. If the Wine project could solicit sufficient funding to hire a few dozen developers for a period of several years, then I think that having WINE become as good as Windows would enter the realm of possibility. I know that many people will laugh at my suggestion (especially when they read the organization I suggest that the WINE project contact), but as far as I can tell, the WINE project has not solicited grants to be able to hire professional developers and I think that failing to solicit such grants places a handicap on the WINE project. There exist charitable organizations that seek to fund solutions to "global problems that are ignored by governments and other organizations" (as stated in Wikipedia). Because enabling Windows programs to run on free UNIX operating systems would reduce the cost of computing for all people, including those in third world countries, I am certain that such organizations that would be willing to fund WINE, provided that the WINE project inform them of its existence. The specific organization from which I think that the WINE project should attempt to solicit grant money is the Bill and Melinda Gates Foundation. In consideration of their guiding principles and the fact that they must spend $1.5 billion a year, it seems only logical to me that they would provide funding for the WINE project if asked: http://www.gatesfoundation.org/about/Pages/guiding-principles.aspx http://en.wikipedia.org/wiki/Bill_%26_Melinda_Gates_Foundation#Activities The Bill and Melinda Gates Foundation is not the only organization for which the WINE project could solicit funding, but I think that it is a good place to start. Please consider the possibility of soliciting grants so that the WINE project could hire professional developers. Also, I am not registered on the mailing list, so please CC me any responses made either directly or indirectly to this email, even if it ridicules my suggestion. Yours truly, Richard Yao

3 2

Re: ntdll: add stub for NtSystemDebugControl (try 2)
by Andrew Nguyen 29 Jun '10

29 Jun '10

2010/6/28 Austin English <austinenglish(a)gmail.com>: > with correct spec file this time > > -- > -Austin > > > > The spec argument that corresponds to the PULONG prototype argument should also be ptr.

1 0

Re: ntdll: add stub for NtSystemDebugControl
by Andrew Nguyen 29 Jun '10

29 Jun '10

On Mon, Jun 28, 2010 at 8:16 PM, Austin English <austinenglish(a)gmail.com> wrote: > See http://bugs.winehq.org/show_bug.cgi?id=23431 > > -- > -Austin > > > > The NtSystemDebugControl spec types don't match the prototype arguments.

1 0

Re: configure.ac: Don't try to rm dirs.
by Alexandre Julliard 28 Jun '10

28 Jun '10

Nicolas Le Cam <niko.lecam(a)gmail.com> writes: > Hi, > > This patch allows to do a make clean in a wine tree configured with > with-wine64 option and fix following errors : > rm: cannot remove `fonts': Is a directory > rm: cannot remove `server': Is a directory These should be symlinks in a wow64 tree. Probably you didn't start from a fresh tree. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] user32: check for valid pointer in CreateIconFromResource
by Alexandre Julliard 28 Jun '10

28 Jun '10

Wolfram Sang <wolfram(a)the-dreams.de> writes: > According to TestBot (#2851), all non-crashing Windows versions return 0. > > Found while working on Bug 21012. Although this patch doesn't cure this > bug, I think it is still worth adding the check because the pointer > may come from the (always evil ;)) user-application. Do you have an actual application that does this, or is this just hiding a Wine bug? -- Alexandre Julliard julliard(a)winehq.org

4 4

Re: ddraw: Move complex surface destruction into its own function
by Luke Benstead 28 Jun '10

28 Jun '10

Ok I wasn't sure as it's pretty trivial. I'll resend along with the others after 1.2. On Jun 28, 2010 8:36 PM, "Henri Verbeet" <hverbeet(a)gmail.com> wrote: On 28 June 2010 20:03, Luke Benstead <kazade(a)gmail.com> wrote: > Needed to properly fix ddraw surfac... That's of course not appropriate during code freeze.

2 1

Re: ddraw: Move complex surface destruction into its own function
by Henri Verbeet 28 Jun '10

28 Jun '10

On 28 June 2010 20:03, Luke Benstead <kazade(a)gmail.com> wrote: > Needed to properly fix ddraw surface refcounting as it must be called from > the surface thunks. > That's of course not appropriate during code freeze.

1 0

Re: kernel32: Add NERR_UserNotFound to Norweigan winerr
by Paul Vriens 28 Jun '10

28 Jun '10

On 06/28/2010 08:15 PM, Austin English wrote: > See http://bugs.winehq.org/show_bug.cgi?id=11168 > Hi Austin, Applying the patch gives: [paul@acer wine-git]$ patch -p 1 -i /home/paul/kernel32_nor.txt (Stripping trailing CRs from patch.) patching file dlls/kernel32/nls/winerr_nor.mc Compiling gives: ../../../wine-git/dlls/kernel32/nls/winerr_nor.mc:3737:2: Error: Unexpected EOF make: *** [nls/winerr_nor.mc.rc] Error 1 You need to add a '.' at the end of the mc file (see the others). -- Cheers, Paul.

2 1

Wine on cygwin now compiles!
by Austin English 28 Jun '10

28 Jun '10

Thanks to a few recent commits by AJ (and several commits over the past months by others), wine now builds on Cygwin. Not everything works, of course, but still a neat exercise in recursion. I've put a screenshot of wine's notepad running on XP on bugzilla (http://bugs.winehq.org/show_bug.cgi?id=21181) see: http://bugs2.winehq.org/attachment.cgi?id=28896 -- -Austin

6 7

Fwd: Possible patch for #12706
by Jeff Cook 28 Jun '10

28 Jun '10

This is a patch that makes WINE detect snd_usb_audio mics and assign them a mixer and working master control. See bug #12706 for more information about this problem: http://bugs.winehq.org/show_bug.cgi?id=12706 I wasn't able to test it completely because I wasn't able to switch my default input device to the USB mic and no one in IRC is helping with this, but it might make things work because theoretically the only problem was that WINE was ignoring devices that looked like snd_usb_audio's microphones. I suggest that someone who CAN get snd_usb_audio mic as their default test it out and confirm, I would really appreciate that. Thanks to all in IRC who helped me get things this far, especially mlankhorst. This patch is based against the current git HEAD, eaa227c12d8bb. I've also posted it at the aforementioned bug. -- Jeff Cook (801) 231-3157 jeff(a)deserettechnology.com

3 2

Re: user32: Make sure the desktop window is created before caps enumeration.
by Alexandre Julliard 28 Jun '10

28 Jun '10

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > This patch fixes the problem reported in the bug 21709. That's just hiding the bug. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] shell32: Use more accurate PathIsURL instead of searching for a colon
by Alexandre Julliard 28 Jun '10

28 Jun '10

Andrew Eikum <aeikum(a)codeweavers.com> writes: > diff --git a/dlls/shell32/shfldr_desktop.c b/dlls/shell32/shfldr_desktop.c > index 30aea3b..54d13dc 100644 > --- a/dlls/shell32/shfldr_desktop.c > +++ b/dlls/shell32/shfldr_desktop.c > @@ -193,7 +193,7 @@ static HRESULT WINAPI ISF_Desktop_fnParseDisplayName (IShellFolder2 * iface, > *ppidl = pidlTemp; > return S_OK; > } > - else if (strchrW(lpszDisplayName,':')) > + else if (PathIsURLW(lpszDisplayName)) > { A better way would be to check the result of the ParseURLW call. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [hhctrl.ocx] Null pointer fix, new patch
by Dmitry Timoshkov 28 Jun '10

28 Jun '10

Jaroslav Šmíd <jardasmid(a)gmail.com> wrote: > diff -urN Wine-git.orig/dlls/hhctrl.ocx/chm.c Wine-git/dlls/hhctrl.ocx/chm.c > --- Wine-git.orig/dlls/hhctrl.ocx/chm.c 2010-06-22 12:41:54.034540000 +0200 > +++ Wine-git/dlls/hhctrl.ocx/chm.c 2010-06-22 12:51:07.454541388 +0200 > @@ -238,11 +238,11 @@ > info->WinType.pszIndex = strdupW(null); > info->WinType.fsValidMembers=0; > info->WinType.fsWinProperties=HHWIN_PROP_TRI_PANE; > - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); > + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? > info->pCHMInfo->defTitle : null); > info->WinType.dwStyles=WS_POPUP; > info->WinType.dwExStyles=0; > info->WinType.nShowState=SW_SHOW; > - info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic); > + info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic ? > info->pCHMInfo->defTopic : null); > info->WinType.curNavType=HHWIN_NAVTYPE_TOC; > return TRUE; > } The patch is wrapped. -- Dmitry.

3 2

Re: Release plans
by wylda＠volny.cz 27 Jun '10

27 Jun '10

Hi, another week and Sunday gone so time for simple numbers... 340 regressions <-- release announcement 356 regressions <-- release announcement + 1week 339 regressions <-- release announcement + 2weeks(rc1) 322 regressions <-- release announcement + 3weeks(rc2) 325 regressions <-- release announcement + 4weeks 326 regressions <-- release announcement + 5weeks(rc3) List of fixed bugs on rc3 release was long and impressive. Unfortunately for regressions there is a stagnation.

4 5

How do you make x64 crosstests?
by Ilya Basin 27 Jun '10

27 Jun '10

_

4 3

Re: Reg ukrainian translation update
by Michael Stefaniuc 27 Jun '10

27 Jun '10

Hello Igor, On 06/27/2010 12:35 PM, Igor Paliychuk wrote: > Updated translation, changed cyrillic 'i' to latin 'i' because first one in cmd is shown as '?'. you don't need that because there is no problem with that. Wine needs a proper windows console. Try it out in "wineconsole cmd" and there it will show up correctly. bye michael

1 0

Re: [1/3] msvcrt.dll: Tests for getenv_s and _wgetenv_s
by Piotr Caban 27 Jun '10

27 Jun '10

> Is there any known MSVCRT version in which getenv_s is exported and > _set_invalid_parameter_handler is not? Both under Windows Vista and Windows 7 getenv_s is exported and _set_invalid_paramter_handler is not.

1 0

Debian package backorder
by Ben Klein 27 Jun '10

27 Jun '10

Unless someone wants to donate an AM2/DDR2 motherboard to me, someone is going to have to take over the packaging of Debian Stable, Testing and Unstable packages.

2 3

Re: Wine on cygwin now compiles!
by Stefan Dösinger 27 Jun '10

27 Jun '10

For dx10 you just need wined3d and the client libs. Those work since quite a while without any other wine component

1 0

Re: add russian translation for winerrs messages
by Nikolay Sivov 27 Jun '10

27 Jun '10

On 6/26/2010 18:23, Vitaly Lipatov wrote: > It patch adds russian translation for kernel32 windows error code descriptions This one: --- +LanguageNames=(RUS=0x419:winerr) --- should be --- +LanguageNames=(RUS=0x19:winerr) --- cause #define LANG_RUSSIAN 0x19

1 0

Re: [hhctrl.ocx] Make sure pszCaption and pszFile are never 0
by Charles Davis 26 Jun '10

26 Jun '10

On Jun 26, 2010, at 2:32 PM, Jaroslav Šmíd wrote: > --- > dlls/hhctrl.ocx/chm.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/hhctrl.ocx/chm.c b/dlls/hhctrl.ocx/chm.c > index 4c85bd9..f0452fa 100644 > --- a/dlls/hhctrl.ocx/chm.c > +++ b/dlls/hhctrl.ocx/chm.c > @@ -238,11 +238,11 @@ BOOL LoadWinTypeFromCHM(HHInfo *info) > info->WinType.pszIndex = strdupW(null); > info->WinType.fsValidMembers=0; > info->WinType.fsWinProperties=HHWIN_PROP_TRI_PANE; > - info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle); > + info->WinType.pszCaption=strdupW(info->pCHMInfo->defTitle ? > info->pCHMInfo->defTitle : null); > info->WinType.dwStyles=WS_POPUP; > info->WinType.dwExStyles=0; > info->WinType.nShowState=SW_SHOW; > - info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic); > + info->WinType.pszFile=strdupW(info->pCHMInfo->defTopic ? > info->pCHMInfo->defTopic : null); > info->WinType.curNavType=HHWIN_NAVTYPE_TOC; > return TRUE; > } Your mailer mangled the patch, such that long lines are broken into two lines. THAT is what we mean by "your patch got wrapped". We can't apply your patch in this state, so you'll have to send it again after configuring your mail client not to wrap long lines. Chip

4 4

Re: add russian translation for winerrs messages
by Paul Vriens 26 Jun '10

26 Jun '10

On 06/26/2010 04:23 PM, Vitaly Lipatov wrote: > + > +LanguageNames=(RUS=0x419:winerr) > + > +MessageId=0 Hi, It looks like the file is in UTF-8 so shouldn't we need a "CodePages=(RUS=65001:0)"? -- Cheers, Paul.

1 1

Re: Please resend the fixed gcov patch by tomorrow so I can test building with it :)
by Peter Davies 26 Jun '10

26 Jun '10

On 18 June 2010 01:50, Scott Ritchie <scott(a)open-vote.org> wrote: > Hey Peter, > > Was just hoping you'd make the (I believe trivial) change to your gcov > patch that Alexandre wanted and submit it by tomorrow so it creeps into > the next RC. I want to start messing around with profiled package > builds this weekend :) > > Anyway, keep up the good work! > > Thanks, > Scott Ritchie > I didn't send it because the change was so trivial (I have now). Note you will need to build wine-preloader without PGO (and with a libport.a without PGO) or you will get libc linking errors. Peter

2 2

Re: Add files generated by "make depend", PGO and gcov to .gitignore
by Alexandre Julliard 26 Jun '10

26 Jun '10

Peter Davies <ultratwo(a)gmail.com> writes: > @@ -79,6 +79,9 @@ my @ignores = ( > "*.ok", > "*.res", > "*.so", > + "*.gcno", > + "*.gcov", > + "/conf*", They are not generated by a standard build so they don't belong here. Put then in your local ignore file. -- Alexandre Julliard julliard(a)winehq.org

3 2

automated stack dumps broken, just output winedbg usage message now?
by Dan Kegel 26 Jun '10

26 Jun '10

Is anybody else seeing winedbg fail to generate stack dumps? I'm seeing wine: Unhandled page fault on read access to 0x00000000 at address 0xb736bd68 (thread 0009), starting debugger... Usage: winedbg [ [ --gdb ] [ prog-name [ prog-args ] | <num> | file.mdmp | --help ] on a lot of apps when they crash. Could be me, but I figured I'd ask. This is with wine-1.2-rc3.

2 1

Re: [PATCH 6/6] d3dx9: Test raw vertex data for D3DXCreateSphere.
by testbot＠testbot.winehq.org 26 Jun '10

26 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2935 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 5/6] d3dx9: Add tests for D3DXCreateSphere vertex buffer description.
by testbot＠testbot.winehq.org 26 Jun '10

26 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2934 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 4/6] d3dx9: Test number of vertices for D3DXCreateSphere.
by testbot＠testbot.winehq.org 26 Jun '10

26 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2933 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 3/6] d3dx9: Add framework for a more sophisticated D3DXCreateSphere test.
by testbot＠testbot.winehq.org 26 Jun '10

26 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2932 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 2/6] d3dx9: Add a few more tests for D3DXCreateSphere.
by testbot＠testbot.winehq.org 26 Jun '10

26 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2931 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 1/6] d3dx9: Add stub and basic test for D3DXCreateSphere.
by testbot＠testbot.winehq.org 26 Jun '10

26 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2930 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

structure has #pragma pack(8) in Windows SDK (AMD64) and #pragma pack(1) in wine headers
by Ilya Basin 25 Jun '10

25 Jun '10

The struct in question is CSFV defined in shlobh.h. If I try to compile shell32_test for x64 using headers from windows 2008 SDK, I get assertion failure here: http://source.winehq.org/source/dlls/shell32/tests/generated.c?v=wine-1.2-r… Is it normal for wine to have different structure packing?

2 1

Tests for msvcrt
by Paul Chitescu 25 Jun '10

25 Jun '10

Hi! What would be the best way of testing MSVCRT.DLL considering that many functions may or may be not present in the native version? > > /********************************************************************* > > + * getenv_s - not exported in native msvcrt > > + */ > > +int CDECL getenv_s(size_t *size, char *buffer, size_t bufLen, const char *name > Both getenv_s and _wgetenv_s are exported in native msvcrt. In older versions of MSVCRT.DLL (XP and earlier, no idea about Vista) these functions are not exported. They were added first in Visual Studio 2005 (MSVCRT80.DLL) and somehow made they way back in MSVCRT. Using LoadLibrary / GetProcAddress would fail on all older Windows platforms. It would be possible to test MSVCR80 instead but that may not be installed on the tested system. Any thoughts? Paul Chitescu

3 3

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
by Misha Koshelev 25 Jun '10

25 Jun '10

> On 24 June 2010 05:18, Misha Koshelev <misha680 at gmail.com> wrote: > > Dan suggested tests ok during code freeze so blame Dan for my patches ;) > Certainly will. wine-devel is an open mailing list, and posting is > easy. You'll probably want to check with something like "git shortlog > -s -n" if the advice you're getting is actually worth taking. The way > I see it, you have more experience with getting patches accepted > yourself. More to the point, if you look at > http://source.winehq.org/patches/, you'll see 62909 is marked as > "Deferred", so resending in a slightly different form isn't going to > help much. > > As for the patch itself, I'm not convinced there's value in having a > separate file for "Shape Drawing Functions", these are clearly mesh > constructors. I thought the original patch was mostly ok in that > regard, although there are (very) minor issues like using %d for > unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 > over simply "IDirect3DDevice9 *". Oh and the LPDIRECT3DDEVICE9's are straight from line.c tests. But I will heed your advice on the %d's Misha

2 2

Re: [PATCH 2/7] d3dx9: Add IUnknown method calls to ID3DXMesh.
by Misha Koshelev 25 Jun '10

25 Jun '10

> On 24 June 2010 05:18, Misha Koshelev <misha680 at gmail.com> wrote: > > +#if !defined(__cplusplus) || defined(CINTERFACE) > > +/*** IUnknown methods ***/ > > +#define ID3DXMesh_QueryInterface(p,a,b) (p)->lpVtbl->QueryInterface(p,a,b) > > +#define ID3DXMesh_AddRef(p) (p)->lpVtbl->AddRef(p) > > +#define ID3DXMesh_Release(p) (p)->lpVtbl->Release(p) > > +#else > > +/*** IUnknown methods ***/ > > +#define ID3DXMesh_QueryInterface(p,a,b) (p)->QueryInterface(a,b) > > +#define ID3DXMesh_AddRef(p) (p)->AddRef() > > +#define ID3DXMesh_Release(p) (p)->Release() > > +#endif > > + > Which version of the DX SDK do these match? > > > ______________________________________________________________________ Ok, now here I just have to plead ignorance my apologies... If I do not declare these functions, how do I call the Release method of the appropriate interfaces? Specifically, I started looking at the test for line.c - I believe that if I create a mesh, I have to release it. I have largely been learning from this page: http://www.mvps.org/directx/articles/d3dxmesh.htm (which is DirectX 8) but it seems I have to somehow release the functions no? Also, I'm probably going to start with the D3DXCreateBox function, as I need to figure out exactly what's going on with the vertices before I delve into something as complicated as spheres ;) Thanks y'all :) Misha

2 1

(no subject)
by Misha Koshelev 25 Jun '10

25 Jun '10

> On 24 June 2010 05:18, Misha Koshelev <misha680 at gmail.com> wrote: > > Dan suggested tests ok during code freeze so blame Dan for my patches ;) > Certainly will. wine-devel is an open mailing list, and posting is > easy. You'll probably want to check with something like "git shortlog > -s -n" if the advice you're getting is actually worth taking. The way > I see it, you have more experience with getting patches accepted > yourself. More to the point, if you look at > http://source.winehq.org/patches/, you'll see 62909 is marked as > "Deferred", so resending in a slightly different form isn't going to > help much. > > As for the patch itself, I'm not convinced there's value in having a > separate file for "Shape Drawing Functions", these are clearly mesh > constructors. I thought the original patch was mostly ok in that > regard, although there are (very) minor issues like using %d for > unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 > over simply "IDirect3DDevice9 *". > So I don't think I'm going to be getting much productive done with 1.2 bugs done in a single day, and the one I started working on yesterday is now fixed. So might as well start thinking about D3DX9. So here is why I thought maybe having a separate shape.c file might be good. I am very new to D3DX9 so please pardon my ignorance, but simply looking at SDK, I see: i) http://msdn.microsoft.com/en-us/library/bb172976%28v=VS.85%29.aspx Shape Drawing Functions are all defined in "D3dx9shape.h" whereas http://msdn.microsoft.com/en-us/library/bb172973%28v=VS.85%29.aspx Mesh Functions are all defined in "D3dx9mesh.h" This is not a reason to implement shape drawing functions in a separate file _per se_, but additionally: ii) all the tests in mesh.c do not rely on CreateWindow calls or Direct3DCreate9 calls whereas those for shape functions inherently will (like line.c) Thus, since I'm going to try to focus on d3dx9 stuff (hope code-freeze is over July 4th), it seems like it might be good to have a separate file. What is the argument for keeping them all in the mesh file besides that they are mesh creation functions? Thank you Misha

2 1

Re: sorry guys... slow on uptake today :)
by James Mckenzie 25 Jun '10

25 Jun '10

Misha Koshelev <misha680(a)gmail.com> wrote: > >So I've been working on bug 13891, but got sidetracked by what I thought >was a race condition as dlls/shell32/tests/shlexec.c was hanging. > >Spent several hours tracing it to line 464 in dlls/ntdll/directory.c > > if (stat( entry->mnt_dir, &st ) == -1) continue; > >(read from /etc/mtab) > >Turned out it was my curlftpfs file system, which tends to disconnect >randomly and not unmount (doh!). > >Anyway I hope to have perhaps some tests for this bug before I leave to >Russia (on Sat morning), but unfortunately I might not be able to get >this bug fixed until post-code freeze. Sorry :( > If the fix is large and ugly, it will not be looked at until after the code freeze is lifted anyway. Have a safe travel. James Mckenzie

2 1

Re: [PATCH] [try 4] ddraw: Grow indexbuffer as needed
by Alexandre Julliard 25 Jun '10

25 Jun '10

Mikko Rasa <tdb(a)tdb.fi> writes: > + /* check that the buffer is large enough to hold the indices, > + * reallocate if necessary. > + */ > + hr = IWineD3DBuffer_GetDesc(This->indexbuffer, &desc); > + if(desc.Size < IndexCount * sizeof(WORD)) > + { > + UINT size = desc.Size; > + IWineD3DBuffer *buffer; > + IUnknown *parent; > + > + while(size < IndexCount * sizeof(WORD)) > + { > + size <<= 1; > + /* We keep adding zero bits to the right, so an overflow > + * will eventually result in all zeroes. Detect this to > + * avoid infinite loop. > + */ > + if(!size) > + { > + ERR("UINT overflow while trying to grow indexbuffer to hold %u indices\n", IndexCount); > + LeaveCriticalSection(&ddraw_cs); > + return D3DERR_TOOMANYPRIMITIVES; > + } > + } A simple "size = max(desc.Size*2,IndexCount*sizeof(WORD))" would do just as well. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wined3d: Silence a noisy fixme.
by Henri Verbeet 25 Jun '10

25 Jun '10

I don't think so. That FIXME should have been an ERR, and if you're seeing it that's a bug.

1 0

sorry guys... slow on uptake today :)
by Misha Koshelev 25 Jun '10

25 Jun '10

So I've been working on bug 13891, but got sidetracked by what I thought was a race condition as dlls/shell32/tests/shlexec.c was hanging. Spent several hours tracing it to line 464 in dlls/ntdll/directory.c if (stat( entry->mnt_dir, &st ) == -1) continue; (read from /etc/mtab) Turned out it was my curlftpfs file system, which tends to disconnect randomly and not unmount (doh!). Anyway I hope to have perhaps some tests for this bug before I leave to Russia (on Sat morning), but unfortunately I might not be able to get this bug fixed until post-code freeze. Sorry :( Misha

1 0

Re: comctl32/tests: remove noisy trace
by testbot＠testbot.winehq.org 24 Jun '10

24 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2910 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
by James Mckenzie 24 Jun '10

24 Jun '10

Henri Verbeet <hverbeet(a)gmail.com wrote: > >On 24 June 2010 18:11, Misha Koshelev <misha680(a)gmail.com> wrote: >> Ok thank you. Since we are in code freeze and I'd like to help wine, perhaps then I >>will just go down the list of 1.2 milestone bugs for now and see if I can help. >> >Yeah, milestone bugs should generally be ok, as well as any open regressions. > Some of the regression bugs are pre-Wine 1.0. Sad, but if you can fix those, it would greatly help bring Wine code up-to-date. James McKenzie

2 1

Re: [PATCH] [try 4] ddraw: Grow indexbuffer as needed
by Stefan Dösinger 24 Jun '10

24 Jun '10

> + while(size < IndexCount * sizeof(WORD)) > + { > + size <<= 1; > + } Thinking about it, is there a reason for growing the buffer in power of two sizes, and not simply set it to the size required for the draw call? E.g. if the app passes index data with a size somewhere between 2^31 and 2^32-1(which still still fits in the UINT variable) the power of two growing will try to create a 2^32 byte buffer which overflows and fails. So you're cutting the possible index buffer size in half. (Of course if an app actually tries to create a >2GB index buffer we have bigger problems than the UINT, especially in a 32 bit process)

2 2

Re: Porting WIne to D
by James Mckenzie 24 Jun '10

24 Jun '10

Gert van den Berg <wine-devel(a)mohag.net> wrote: >Like the D website says: >Who D is Not For > * Realistically, nobody is going to convert million line C or C++ >programs into D. Since D does not compile unmodified C/C++ source >code, *D is not for legacy apps*. (However, D supports legacy C API's >very well. D can connect directly to any code that exposes a C >interface.) That should rule out moving Wine to D for a long time. 9 Million + lines of code would make this a lengthy, but not impossible, task. > >D also specifically drops 16-bit support, which might cause problems >for the Win16 / DOS parts of Wine... Another show-stopper for those folks using Wine to run Windows 2.x/3.x programs. James McKenzie

2 1

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
by Misha Koshelev 24 Jun '10

24 Jun '10

> > On 24 June 2010 05:18, Misha Koshelev <misha680 at gmail.com> wrote: > > Dan suggested tests ok during code freeze so blame Dan for my patches ;) > Certainly will. wine-devel is an open mailing list, and posting is > easy. You'll probably want to check with something like "git shortlog > -s -n" if the advice you're getting is actually worth taking. The way > I see it, you have more experience with getting patches accepted > yourself. More to the point, if you look at > http://source.winehq.org/patches/, you'll see 62909 is marked as > "Deferred", so resending in a slightly different form isn't going to > help much. Ah I see thank you. I take it this means deferred until post-code freeze (please correct me if incorrect). > > > As for the patch itself, I'm not convinced there's value in having a > separate file for "Shape Drawing Functions", these are clearly mesh > constructors. I thought the original patch was mostly ok in that > regard, although there are (very) minor issues like using %d for > unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 > over simply "IDirect3DDevice9 *". > Ok thank you. Since we are in code freeze and I'd like to help wine, perhaps then I will just go down the list of 1.2 milestone bugs for now and see if I can help. Post code freeze, I can then start on the d3dx9 stuff as I am really not akin to having my own private repo as of yet and I think that going from a private repo to getting patches into Wine itself might be a little more difficult than I'd like - rather than doing it all at once... So thus for now work on 1.2 milestones. Then D3DX9. Off to work... Misha

2 1

Re: kernel32: Update Gaelic resource
by Michael Stefaniuc 24 Jun '10

24 Jun '10

Hello Ken, Ken Sharp wrote: > From: Ken Sharp <kennybobs(a)o2.co.uk> > Date: Tue, 15 Jun 2010 09:42:05 +0100 > Subject: kernel32: Update Gaelic resource the patch changes the file encoding to UTF-8 without changing the "#pragma code_page" too. Though Alexandre already rejected codepage changes to the NLS files during the 1.2 freeze as too risky changes; NLS files are more than just translations. The best thing is to resend the changes without the codepage change. thanks bye michael

1 0

Re: kernel32: Update Gaelic resource
by Dmitry Timoshkov 24 Jun '10

24 Jun '10

Ken Sharp <kennybobs(a)o2.co.uk> wrote: > diff --git a/dlls/kernel32/nls/gae.nls b/dlls/kernel32/nls/gae.nls > index 6e19ff4..a005be3 100644 > --- a/dlls/kernel32/nls/gae.nls > +++ b/dlls/kernel32/nls/gae.nls Looks like you are using UTF-8 while the file is in code page 1252. -- Dmitry.

1 0

Porting WIne to D
by Christopher Selph 24 Jun '10

24 Jun '10

Hi everyone, new here. I have been fooling around with the idea of porting WIne to the D programming language. What do you think would be the chances of sucess? D has the speed of C, but is a garbage collected language and OOP. D: http://www.digitalmars.com/d Chris

5 4

Re: [PATCH] ddraw: Grow indexbuffer as needed (now with overflow check)
by Stefan Dösinger 24 Jun '10

24 Jun '10

Am 24.06.2010 um 11:30 schrieb Mikko Rasa: > On 24.06.2010 12:07, Stefan Dösinger wrote: >> >> Am 23.06.2010 um 21:57 schrieb Mikko Rasa: >>> + if(!size) >>> + { >>> + ERR("UINT overflow while trying to grow indexbuffer to hold %u indices\n", IndexCount); >>> + return D3DERR_TOOMANYPRIMITIVES; >>> + } >>> + } >> You have to release the ddraw lock before returning from the function(LeaveCriticalSection(&ddraw_cs)) > > Doh. Fixed that; anything else that should be rectified before I resubmit? Nothing I can spot so far

1 0

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
by Henri Verbeet 24 Jun '10

24 Jun '10

On 24 June 2010 05:18, Misha Koshelev <misha680(a)gmail.com> wrote: > Dan suggested tests ok during code freeze so blame Dan for my patches ;) Certainly will. wine-devel is an open mailing list, and posting is easy. You'll probably want to check with something like "git shortlog -s -n" if the advice you're getting is actually worth taking. The way I see it, you have more experience with getting patches accepted yourself. More to the point, if you look at http://source.winehq.org/patches/, you'll see 62909 is marked as "Deferred", so resending in a slightly different form isn't going to help much. As for the patch itself, I'm not convinced there's value in having a separate file for "Shape Drawing Functions", these are clearly mesh constructors. I thought the original patch was mostly ok in that regard, although there are (very) minor issues like using %d for unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 over simply "IDirect3DDevice9 *".

1 0

Re: [PATCH 2/7] d3dx9: Add IUnknown method calls to ID3DXMesh.
by Henri Verbeet 24 Jun '10

24 Jun '10

On 24 June 2010 05:18, Misha Koshelev <misha680(a)gmail.com> wrote: > +#if !defined(__cplusplus) || defined(CINTERFACE) > +/*** IUnknown methods ***/ > +#define ID3DXMesh_QueryInterface(p,a,b) (p)->lpVtbl->QueryInterface(p,a,b) > +#define ID3DXMesh_AddRef(p) (p)->lpVtbl->AddRef(p) > +#define ID3DXMesh_Release(p) (p)->lpVtbl->Release(p) > +#else > +/*** IUnknown methods ***/ > +#define ID3DXMesh_QueryInterface(p,a,b) (p)->QueryInterface(a,b) > +#define ID3DXMesh_AddRef(p) (p)->AddRef() > +#define ID3DXMesh_Release(p) (p)->Release() > +#endif > + Which version of the DX SDK do these match?

1 0

Re: [PATCH] ddraw: Grow indexbuffer as needed (now with overflow check)
by Stefan Dösinger 24 Jun '10

24 Jun '10

Am 23.06.2010 um 21:57 schrieb Mikko Rasa: > + if(!size) > + { > + ERR("UINT overflow while trying to grow indexbuffer to hold %u indices\n", IndexCount); > + return D3DERR_TOOMANYPRIMITIVES; > + } > + } You have to release the ddraw lock before returning from the function(LeaveCriticalSection(&ddraw_cs))

1 0

Question about video capture and rendering and encoding in wine
by shenyue 24 Jun '10

24 Jun '10

Hi everyone, Previously I post this question on wine-user forum, seems nobody answered/interested, so I post it here. Hope somebody give me a hand :) I have some questions about wine video capture andrendering. I'm a newbie to wine, and am working on QQ or any other messengers in wine. My environment is : ubuntu 10.04, installed wine 1.1.42 (later when I modify code, wine-1.1.42's source instead), QQ2009. And during my debugging, I also check some source code from latest wine 1.2-rc4. Although QQ's level is "garbage", but fortunately it works almost fine under wine, including login, text chat, ..... But the video call can only partially work.I can see my friend's(he's under windows of course) video, while I can't see my preview video, and he cannot see mine video too. And no audio at all. (Audio is another issue, I haven't deal with it now.) As a comparison, I run GraphEdt to check what's wrong with video capture and rendering, my filter graph=video capture + video render. when I 'use clock', the same thing happens, no video rendering at all, but when I DONOT 'use clock', video rendering works fine. Then I read the source code and find out one problem(maybe right, maybe wrong), when wine/dlls/qcap/v4l.c send media samples to downstream filters, it do not set any timestamp on it. Thus if I use VideoRenderer as I did in GraphEdt, the video render got wrong start and stop reference time for media sample, and then the synchronisation result will be very strange. So I modify the v4l.c and set proper timestamp on media sample. Good result, even when I 'use clock', the capture+render graph works find in GraphEdt. But when I turn to QQ, my video capture+preview+encoding graph still seems don't work. Then I checked msdn for these things, according to msdn: "Video frames from a preview pin (as opposed to a capture pin) are not time stamped. Because of graph latency, a video frame that is stamped with the capture time will always arrive late at the video renderer. This may cause the renderer to drop frames, in an attempt at quality control." "Quality control is a mechanism for adjusting the rate of data flow through the filter graph in response to run-time performance. If a renderer filter is receiving too much data or too little data, it can send a quality message. The quality message requests an adjustment in the data rate. By default, quality messages travel upstream from the renderer until they reach a filter that can respond (if any)." I've cheked winedbg log, QQ's filter graph looks like: vfw capture filter + QQ's own video render filter + ... + ddraw/d3d7 rendering. QQ did not use smarttee, preview pin, standard VideoRender or VideoRenderDefault or VideoMixingRender9 (because QQ never query their id). Instead, I guess QQ write a video render filter by itself, and in QQ's render filter, it directly use ddraw/d3d7 surface to render, and maybe it does something similar to smarttee, to output to preview and encoding at the same time. Since QQ did not use preview pin directly, at first I guess maybe 'not time stamped' is not correct, so I add some timestamp to capture's output video frame, still no preview occurs, but result in continuous IQualityControl interface query, but even latest wine-1.2-rc4 has not implemented IQualityControl, so I guess, still something wrong in timestamp synchronisation, and QQ's video render want to use IQualityControl to fix it which wine doesn't support, so maybe every frame is dropped, this result in my black preview video window. I read from wine docs/wiki, once before windows messenger (8.1?) worked fine in wine, I guess since you have written qcap/vfwcapture, of course somebody has used wine for camera+preview+maybe encoding before, why it succeeded by then, but fail now? Is there anything wrong for me? Btw1: there's a bug in wine-1.1.42's dlls/quartz/memallocator.c, MediaSample's GetTime() return value is wrong, I've fixed that bug according to latest wine, but still no video preview, and my friend cannot see my video. Btw2: since qcap only works for v4l1, I ran flashcam to convert v4l2 to v4l1. But I still wondering, since Maarteen original code supports v4l2, why it result in only support v4l1 (but not both v4l1 and v4l2)? Thank you very much in advance. Best regards, Karma 搬迁通知： 2010年1月18日起，上海奇码数字信息有限公司迁至新址办公。新地址为：上海张江祖冲之路887弄88号502室。 ==========================================================

2 2

re: [PATCH 7/7] d3dx9: Test raw vertex data for D3DXCreateSphere.
by Dan Kegel 24 Jun '10

24 Jun '10

Misha wrote: + /* comparisons of 0.0f with -0.0f do not quite seem to work correctly */ Boy, that's for sure. + todo_wine ok( vertex_data[i].x==test_vertex_data[i].x || (fabsf(vertex_data[i].x) < 0.0001f && fabsf(test_vertex_data[i].x) < 0.0001f), "Got result %f, expected %f\n",vertex_data[i].x,test_vertex_data[i].x); You probably want to define an AlmostEqual() function and use that rather than repeating the logic. See http://code.google.com/p/googletest/wiki/GoogleTestAdvancedGuide#Floating-P… and the paper it points to, http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm - Dan

1 0

something I hacked up for git - maybe will help
by Misha Koshelev 24 Jun '10

24 Jun '10

I like to reapply my patches a lot - so this gets rid of trailing whitespace and applies the patch. Just thought I'd send out. I know there's tools to avoid trailing whitespace in emacs (http://github.com/glasserc/ethan-wspace works well), but this is my simple solution ;) Misha

1 0

Re: [PATCH 7/7] d3dx9: Test raw vertex data for D3DXCreateSphere.
by testbot＠testbot.winehq.org 24 Jun '10

24 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2889 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 6/7] d3dx9: Add tests for D3DXCreateSphere vertex buffer description.
by testbot＠testbot.winehq.org 24 Jun '10

24 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2888 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 5/7] d3dx9: Test number of vertices for D3DXCreateSphere.
by testbot＠testbot.winehq.org 24 Jun '10

24 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2887 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 3/7] d3dx9: Add framework for a more sophisticated D3DXCreateSphere test.
by testbot＠testbot.winehq.org 24 Jun '10

24 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2886 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
by testbot＠testbot.winehq.org 24 Jun '10

24 Jun '10

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=2885 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: Porting WIne to D
by Christopher Selph 24 Jun '10

24 Jun '10

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

3 3

wordpad: Remove untranslated resources from the Chinese translation.
by Dylan Smith 23 Jun '10

23 Jun '10

--- programs/wordpad/Zh.rc | 24 ------------------------ 1 files changed, 0 insertions(+), 24 deletions(-) diff --git a/programs/wordpad/Zh.rc b/programs/wordpad/Zh.rc index 135f00c..bae40a7 100644 --- a/programs/wordpad/Zh.rc +++ b/programs/wordpad/Zh.rc @@ -111,30 +111,6 @@ BEGIN END END -IDM_COLOR_POPUP MENU DISCARDABLE -BEGIN - POPUP "" - BEGIN - MENUITEM "Black", ID_COLOR_BLACK - MENUITEM "Maroon", ID_COLOR_MAROON - MENUITEM "Green", ID_COLOR_GREEN - MENUITEM "Olive" ID_COLOR_OLIVE - MENUITEM "Navy" ID_COLOR_NAVY - MENUITEM "Purple" ID_COLOR_PURPLE - MENUITEM "Teal" ID_COLOR_TEAL - MENUITEM "Gray" ID_COLOR_GRAY - MENUITEM "Silver" ID_COLOR_SILVER - MENUITEM "Red" ID_COLOR_RED - MENUITEM "Lime" ID_COLOR_LIME - MENUITEM "Yellow" ID_COLOR_YELLOW - MENUITEM "Blue" ID_COLOR_BLUE - MENUITEM "Fuchsia" ID_COLOR_FUCHSIA - MENUITEM "Aqua" ID_COLOR_AQUA - MENUITEM "White" ID_COLOR_WHITE - MENUITEM "Automatic" ID_COLOR_AUTOMATIC - END -END - IDD_DATETIME DIALOG DISCARDABLE 30, 20, 130, 80 STYLE DS_MODALFRAME | WS_CAPTION | WS_SYSMENU CAPTION "日期和时间" -- 1.7.0.4

2 1

Re: oledlg: Add the Romanian translation.
by Alexandru Băluț 23 Jun '10

23 Jun '10

2010/6/23 Michael Stefaniuc <mstefani(a)redhat.com>: > + CONTROL "Creează un nou",IDC_CREATENEW,"Button",BS_AUTORADIOBUTTON | > + WS_GROUP,7,20,67,10 "Creează nou" seems better, the original is "Create New", not "Create a New". I don't really get what "Create New" is supposed to mean, or what is the difference between the "Create New" and "Create Control", since for both you press the same button "Add Control...", so both actually create a Control. I might be wrong. > + PUSHBUTTON "&Adăugare control...",IDC_ADDCONTROL,81,88,67,14,NOT WS_VISIBLE This is a button, "&Adaugă [...]" seems more appropriate. "&Adaugă un control" would be consistent with "Creează un control" which is used for a radio button. > +CAPTION "Paste Special" It should say "Inserare specială", to be consistent with: > + CONTROL "I&nserează", IDC_PS_PASTE, "Button", BS_AUTORADIOBUTTON | WS_TABSTOP | WS_GROUP | WS_VISIBLE, > + CONTROL "Inserează &linkul", IDC_PS_PASTELINK, "Button", BS_AUTORADIOBUTTON | WS_VISIBLE, Is "Inserează &legătura" wrong? > + IDS_PS_PASTE_DATA "Inserează conținutul din clipboard în document ca %s." > + IDS_PS_PASTE_OBJECT "Inserează conținutul din clipboard în document astfel încât să îl puteți activa utilizând %s." > + IDS_PS_PASTE_OBJECT_AS_ICON "Inserează conținutul din clipboard în document astfel încât să îl puteți activa utilizând %s. Va fi afișat ca o pictogramă." > + IDS_PS_PASTE_LINK_DATA "Inserează conținutul din clipboard în document ca %s. Datele sunt legate de fișierul sursă, astfel încât modificările aduse fișierului vor fi reflectate în document." > + IDS_PS_PASTE_LINK_OBJECT "Inserați o imagine a conținutului din clipboard în document. Imaginea este legată de fișierul sursă, astfel încât modificările aduse fișierului vor fi reflectate în document." > + IDS_PS_PASTE_LINK_OBJECT_AS_ICON "Inserați o scurtătură care conduce la locația conținutului din clipboard. Scurtătura este legată de fișierul sursă, astfel încât modificările aduse fișierului vor fi reflectate în document." > + IDS_PS_NON_OLE "Inserează conținutul din clipboard în document." All the English messages for these start with "Inserts [...]" - We should be consistent, and use "Inserează [...]" for all of them. Thanks, Alex

2 2

Re: [PATCH] user32: check for valid pointer in CURSORICON_CreateIconFromBMI
by Alexandre Julliard 23 Jun '10

23 Jun '10

Wolfram Sang <wolfram(a)the-dreams.de> writes: > @@ -884,6 +884,10 @@ static HICON CURSORICON_CreateIconFromBMI( BITMAPINFO *bmi, > return 0; > } > > + /* A few Windows versions crash getting NULL, but most simply return it */ > + if (!bmi) > + return 0; That's not the right place for it, this is an internal function. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: Porting WIne to D
by Stephen Eilert 23 Jun '10

23 Jun '10

On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph <cds.wine(a)gmail.com> wrote: > Well, being a garbage collected language, it would help with the memory > leaks in Wine. Being OOP it could extend the design of the code to make it > cleaner and reusable. The assertions above are opinions, not facts. Also, it requires a full rewrite. Wine Initial release(per Wikipedia): 4 July 1993 Good luck. --Stephen Sent from my Emacs

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel