November 2008 - Wine-Devel - list.winehq.org

Re: d3dx9: Implement ID3DXSprite_OnLostDevice/OnResetDevice
by Henri Verbeet Nov. 16, 2008

Nov. 16, 2008

2008/11/15 Tony Wasserka <tony.wasserka(a)freenet.de>: > + if(This->sprites) { > + int i; > + for(i=0;i<This->sprite_count;i++) > + if(This->sprites[i].texture) This if should be redundant. I looked at some of the other sprite code, and noticed you've got similar constructions in other places. You also don't handle HeapAlloc/HeapReAlloc failures in most places. > + HeapFree(GetProcessHeap(), 0, This->sprites); Why do you free the sprites array here?

1 0

Re: d3dx9: ID3DXSprite: Move vdecl creation to ID3DXSprite_Begin [PATCH 2/3]
by Henri Verbeet Nov. 16, 2008

Nov. 16, 2008

As a general remark about drawing sprites, when shaders are available you can use those instead, which should save you from messing around with render states and texture stage states.

1 0

Re: d3dx9: Implement ID3DXSprite_*etTransform [PATCH 1/3]
by Henri Verbeet Nov. 16, 2008

Nov. 16, 2008

2008/11/15 Tony Wasserka <tony.wasserka(a)freenet.de>: > + TRACE("(%p): relay\n", This); "relay" doesn't make sense here. > + memcpy(transform, &This->transform, sizeof(D3DXMATRIX)); Why not just write "*transform = This->transform"?

1 0

DIB Engine
by Massimo Del Fedele Nov. 16, 2008

Nov. 16, 2008

I recently had a chat with Dan Kegel about the way to contribute and start hacking on a DIB engine. I grabbed Huw Davies and Jesse Allen's repositories and started looking at them. As it'll be an hard (and long) work, I'd like to know some opinions on how to proceed and propose an idea on how to have it introduced in mainstream without breaking stuff. The idea is, for now, JUST an idea and I still don't know if it'll be possible, but I guess yes. So, I was thinking on : 1) Try to join best stuffs of both repos of Huw and Jesse. 2) Add the environment variable DIBENGINE which could have 3 different values (or be missing) : missing DIBENGINE env var or DIBENGINE=NONE New dib engine will not be used, back to X11DRV DIBENGINE=FORWARD Unimplemented stuffs forwarded to X11, the rest using new dib engine code DIBENGINE=FULL use just dib engine code and shows FIXMEs for unimplemented stuffs The first would allow to insert dib engine in main stream without breaking anything, the last would allow to see what's more important to implement. The middle one (FORWARD) would allow to check if something breaks during the transition, and use the developed parts. 3) Stop and wait till it's put on mainstream, so more people could contribute. The doubt is if it'll be possible the mixed approach, forwarding unimplemented stuffs to X11, but I think so. Is it an acceptable way to proceed ? Ciao Max

4 11

Re: Slovak translations
by Austin English Nov. 16, 2008

Nov. 16, 2008

2008/11/16 Kario <kario(a)szm.sk>: > hi, my name is Mario Kacmar, I am from Slovakia > > and I made this patch with Slovak translations > > please commit my patch, or if is something wrong > > please contact me back > > > > see attachment > > === reklama ====================================== > http://mail.szm.com - e-mail a priestor na www stranku zadarmo > http://webhosting.szm.com - domeny a webhosting za najnizsie ceny > > > > > > > From: unknown <Kario(a).(none)> Your e-mail is munged in the patch. Also, please submit one change per patch, i.e., one translated file per patch. Thanks for helping Wine! -- -Austin

1 0

Re: [1/4] user32/tests: Test size and minmax of WS_THICKFRAME child.
by Austin English Nov. 16, 2008

Nov. 16, 2008

On Sun, Nov 16, 2008 at 10:52 AM, Florian Köberle <florian(a)fkoeberle.de> wrote: > Patch to fix bug 15188. > > This work is based on: > http://www.winehq.org/pipermail/wine-patches/2008-October/062460.html > > In this new patch series I calculate size like this: > > const int outer = 2; > int resizeBorder = GetSystemMetrics(SM_CXFRAME) - > GetSystemMetrics(SM_CXDLGFRAME); > int size = 2*(outer + resizeBorder); > > I took this formular from dlls/user32/nonclient.c: > ------------------ > adjust = 0; > if ((exStyle & WS_EX_DLGMODALFRAME) || > (style & (WS_THICKFRAME|WS_DLGFRAME))) adjust = 2; /* outer */ > } > if (style & WS_THICKFRAME) > adjust += ( GetSystemMetrics (SM_CXFRAME) > - GetSystemMetrics (SM_CXDLGFRAME)); /* The resize > border */ > ------------------ > > While writing this test I also tried some other styles and compared the > behavior between > CreateWindowEx and AdjustWindowRectEx. It didn't look like they have > much in common, that is why I didn't wrote the test against > AdjustWindowRectEx. > > Best regards, > Florian > > > > > From 762f49e2192b6d8477826c6535ef1ba0e1fd9d9b Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Florian=20K=C3=B6berle?= <florian(a)fkoeberle.de> Looks like you've botched the encoding somehow... > + test_thick_child_size(hwndMain); // causes test_capture_2() to fail Don't use C++ style comments, use C (/* comment */) instead. -- -Austin

2 1

Re: tools/fnt2bdf: fix a few compiler warnings (1/10)
by Michael Stefaniuc Nov. 16, 2008

Nov. 16, 2008

Austin English wrote: > This series of patches fixes most of the new warnings generated in gcc > 4.3.2. There's one issue left, but I'm not quite sure what should be > done on that one. > diff --git a/tools/fnt2bdf.c b/tools/fnt2bdf.c > index 1a14d6c..3c3134b 100644 > --- a/tools/fnt2bdf.c > +++ b/tools/fnt2bdf.c > @@ -595,14 +595,14 @@ int main(int argc, char **argv) > > if( !(lpfont = (unsigned char*) realloc( lpfont, length )) ) > { >- fprintf(stderr, errorMemory ); >+ fprintf(stderr, "%s", errorMemory ); Ugly. You could just use fputs instead. But if you know that the passed in strings are safe aka no format specifiers in them you can leave the code as is as the compiler warning is bogus. > exit(1); > } bye michael

3 3

Re: [PATCH 1/7] msi: Add more tests for the CompLocator part of the AppSearch action.
by Paul Vriens Nov. 16, 2008

Nov. 16, 2008

James Hawkins wrote: > --- > dlls/msi/tests/package.c | 526 +++++++++++++++++++++++++++++++++++++--------- > 1 files changed, 421 insertions(+), 105 deletions(-) > > > ------------------------------------------------------------------------ > > Hi James, I was looking at why on Win9x there were some registry entries left behind with the package tests. It had to do with creating the UserData keys (which doesn't exist at all on win9x/winme btw.) within test_complocator (by calling set_component_path) and trying to delete them with a W-function (that isn't present on win9x/winme by default). I did some further testing on several platforms and it turns out the test_complocator succeeds even without creating those registry keys in the first place (tested on Win98, W2K3 and Wine). The attached 'patch' just excludes the registry entry creation/deletion. Am I completely missing something or can this registry creation/deleted be removed from that test? -- Cheers, Paul. diff --git a/dlls/msi/tests/package.c b/dlls/msi/tests/package.c index 47ffa35..3c128f0 100644 --- a/dlls/msi/tests/package.c +++ b/dlls/msi/tests/package.c @@ -7906,6 +7906,7 @@ static void test_complocator(void) CreateDirectoryA("olorotitan", NULL); CreateDirectoryA("pantydraco", NULL); +#if 0 set_component_path("abelisaurus", MSIINSTALLCONTEXT_MACHINE, "{E3619EED-305A-418C-B9C7-F7D7377F0934}", NULL, FALSE); set_component_path("bactrosaurus", MSIINSTALLCONTEXT_MACHINE, @@ -7922,6 +7923,7 @@ static void test_complocator(void) "{8B1034B7-BD5E-41ac-B52C-0105D3DFD74D}", NULL, FALSE); set_component_path("neosodon", MSIINSTALLCONTEXT_MACHINE, "{0B499649-197A-48EF-93D2-AF1C17ED6E90}", NULL, FALSE); +#endif r = MsiDoAction(hpkg, "AppSearch"); ok(r == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", r); @@ -8039,6 +8041,7 @@ static void test_complocator(void) RemoveDirectoryA("neosodon"); RemoveDirectoryA("olorotitan"); RemoveDirectoryA("pantydraco"); +#if 0 delete_component_path("{E3619EED-305A-418C-B9C7-F7D7377F0934}", MSIINSTALLCONTEXT_MACHINE, NULL); delete_component_path("{D56B688D-542F-42Ef-90FD-B6DA76EE8119}", @@ -8055,6 +8058,7 @@ static void test_complocator(void) MSIINSTALLCONTEXT_MACHINE, NULL); delete_component_path("{0B499649-197A-48EF-93D2-AF1C17ED6E90}", MSIINSTALLCONTEXT_MACHINE, NULL); +#endif DeleteFileA(msifile); }

1 0

uninitialized reference in wineconsole in call to WriteConsoleInput?
by Dan Kegel Nov. 16, 2008

Nov. 16, 2008

One more of the 100 valgrind warnings; this one is in kernel32/tests/console.c (but really in wineconsole). It's code Eric wrote six years ago, and the fix might be as straightforward as using memcpy(&ir, 0, sizeof(ir)) in WCUSER_GenerateMouseInputRecord(). Is there a better fix? Short form: SyscallParam wine_server_call WriteConsoleInputW WCUSER_GenerateMouseInputRecord WCUSER_Proc call_window_proc WINPROC_call_window DispatchMessageW WCUSER_MainLoop WinMain main Long form: <kind>SyscallParam</kind> <what>Syscall param writev(vector[...]) points to uninitialised byte(s)</what> <stack> <frame> <obj>dlls/ntdll/ntdll.dll.so</obj> <fn>wine_server_call</fn> <dir>dlls/ntdll</dir> <file>server.c</file> <line>248</line> </frame> <frame> <obj>dlls/kernel32/kernel32.dll.so</obj> <fn>WriteConsoleInputW</fn> <dir>dlls/kernel32/../../include/wine</dir> <file>server.h</file> <line>61</line> </frame> <frame> <obj>programs/wineconsole/wineconsole.exe.so</obj> <fn>WCUSER_GenerateMouseInputRecord</fn> <dir>programs/wineconsole</dir> <file>user.c</file> <line>1087</line> </frame> <frame> <obj>programs/wineconsole/wineconsole.exe.so</obj> <fn>WCUSER_Proc</fn> <dir>programs/wineconsole</dir> <file>user.c</file> <line>1186</line> </frame> <frame> <obj>dlls/user32/user32.dll.so</obj> </frame> <frame> <obj>dlls/user32/user32.dll.so</obj> <fn>call_window_proc</fn> <dir>dlls/user32</dir> <file>winproc.c</file> <line>458</line> </frame> <frame> <obj>dlls/user32/user32.dll.so</obj> <fn>WINPROC_call_window</fn> <dir>dlls/user32</dir> <file>winproc.c</file> <line>2212</line> </frame> <frame> <obj>dlls/user32/user32.dll.so</obj> <fn>DispatchMessageW</fn> <dir>dlls/user32</dir> <file>message.c</file> <line>3108</line> </frame> <frame> <obj>programs/wineconsole/wineconsole.exe.so</obj> <fn>WCUSER_MainLoop</fn> <dir>programs/wineconsole</dir> <file>user.c</file> <line>1378</line> </frame> <origin> <what>Uninitialised value was created by a stack allocation</what> <stack> <frame> <obj>programs/wineconsole/wineconsole.exe.so</obj> <fn>WCUSER_GenerateMouseInputRecord</fn> <dir>programs/wineconsole</dir> <file>user.c</file> <line>1066</line> </frame> </stack> </origin>

2 1

Re: Race in thread shutdown in imm32?
by Ge van Geldorp Nov. 15, 2008

Nov. 15, 2008

> From: "Rob Shearman" <robertshearman(a)gmail.com> > > I believe that Windows terminates all threads on process > exit It does, see http://blogs.msdn.com/oldnewthing/archive/2007/05/03/2383346.aspx

1 0

Re: OLEAUT32: implement OleLoadPictureFile(Ex) and add tests
by Detlef Riekenberg Nov. 14, 2008

Nov. 14, 2008

On Mi, 2008-11-12 at 23:40 -0800, Jeremy Drake wrote: I have no Idea about that area, but the unicode API is not implemented on win9x (GetTempFileNameW, CreateFileW, DeleteFileW) > if(!pOleLoadPictureFile || !pOleLoadPictureFileEx) Are there systems in the Wild that have OleLoadPictureFile, but are missing OleLoadPictureFile? In that case, you should use 2 seperate tests. > skip("Skipping OleLoadPictureFile tests\n"); Think, what you would see in the log before your text: "filename.c:__LINE__: Tests skipped:" "Skipping" is redundant and "tests" also. The usual way would be: skip("OleLoadPictureFile not found\n"); When you want to make sure, that we never skip in Wine here, then use win_skip instead. -- By by ... Detlef

1 1

Re: gdiplus: fix GdipFlattenPath for already-flat paths and add a test
by Vincent Povirk Nov. 14, 2008

Nov. 14, 2008

Please ignore this patch. It has a line removed that shouldn't be. Vincent Povirk On Fri, Nov 14, 2008 at 5:07 PM, Vincent Povirk <vincent(a)codeweavers.com> wrote: > > > >

1 0

RFC: Wine Icons
by Joel Holdsworth Nov. 14, 2008

Nov. 14, 2008

Hi All, I notice that some of Wine's icons have been changed in recent releases. In principle I think updating the icons is a great idea, but right now I gotta say that icons in Wine are a real disaster. Take a look here: http://www.airwebreathe.org.uk/icons.png This is a screenshot of the shell folder select dialog. Out of those icons My Documents looks the least broken - with it's wannabe 98/ME/2000 styling. Desktop, "/", My Computer and Trash look like they've been taken from large icons which have shrunk - badly, and with a broken alpha channel. And the new golden Folder icons look completely out of place - they bear no resemblance to anything else, they've been scaled down poorly, they don't look like Windows icons, and they don't fit in with the Gnome desktop (and I can't imagine they'd look good in KDE or on Mac either). I'd really like for Wine to start using icons from the Tango project, or similar. The purpose of Tango was to create a set of icons that are clear to see, and look good on Windows, Gnome, KDE, and MacOS. Surely that's exactly what we want? Note that ReactOS is using Tango, and it seems to be working out pretty well for them! Any comments on that? Best Regards Joel Holdsworth

3 4

Re: RFC: Wine Icons
by Branan Riley Nov. 14, 2008

Nov. 14, 2008

On Fri, Nov 14, 2008 at 9:43 AM, Branan Riley <branan(a)gmail.com> wrote: > On Fri, Nov 14, 2008 at 5:54 AM, Joel Holdsworth > <joel(a)airwebreathe.org.uk> wrote: >> Hi All, >> >> I notice that some of Wine's icons have been changed in recent releases. >> In principle I think updating the icons is a great idea, but right now I >> gotta say that icons in Wine are a real disaster. >> >> Take a look here: http://www.airwebreathe.org.uk/icons.png >> >> This is a screenshot of the shell folder select dialog. Out of those >> icons My Documents looks the least broken - with it's wannabe 98/ME/2000 >> styling. Desktop, "/", My Computer and Trash look like they've been >> taken from large icons which have shrunk - badly, and with a broken >> alpha channel. And the new golden Folder icons look completely out of >> place - they bear no resemblance to anything else, they've been scaled >> down poorly, they don't look like Windows icons, and they don't fit in >> with the Gnome desktop (and I can't imagine they'd look good in KDE or >> on Mac either). >> >> I'd really like for Wine to start using icons from the Tango project, or >> similar. The purpose of Tango was to create a set of icons that are >> clear to see, and look good on Windows, Gnome, KDE, and MacOS. Surely >> that's exactly what we want? >> >> Note that ReactOS is using Tango, and it seems to be working out pretty >> well for them! >> >> Any comments on that? >> >> Best Regards >> Joel Holdsworth > > The problem with hardcoding Tango is that it won't necessarily match > the user's desktop. > > On Linux and FreeBSD, I'd suggest finding a way to detect the current > icon theme (perhaps determine which desktop environment is running, > then read the config file for that desktop?) and use the > freedesktop.org icon names and the XDG_DATA_DIRS variable to locate > the icons. This wouldn't work on KDE3 (which doesn't use the > freedesktop spec). In that case I would say fall back to the hicolor > icons. > > On Mac, you should use the native mac icons, but that might not work > to do Obj-C issues (I know nothing about mac programming, so maybe > there's a way to get native icons without Obj-C?). > > This way, when theming is implemented, the icons and the theme will > both match the user's desktop environment. It's more complicated than > just implementing Tango, but visually it makes more sense. > > Branan Thinking about this a bit more, it would require a tool to generate the .DLL with the icons we want from the freedesktop spec, in order to maintain compatibility with Windows on how system icons are handled. This could be done once when the prefix is created, with an option in winecfg to re-build the icon DLL.

2 1

Re: Revert "quartz: Reaching a renderer in the filtergraph is not an error."
by Lei Zhang Nov. 14, 2008

Nov. 14, 2008

On Fri, Nov 14, 2008 at 1:54 PM, Maarten Lankhorst <maarten(a)codeweavers.com> wrote: > This is plain wrong, input pin and output pin are supposed to be connected > to each other, not the input pin being connected to a renderer pin and NOT > reaching output pin > --- > > From 0f91e8a67c88d1ec0871c772679871249fd7625f Mon Sep 17 00:00:00 2001 > From: Maarten Lankhorst <maarten(a)codeweavers.com> > Date: Fri, 14 Nov 2008 22:50:34 +0100 > Subject: [PATCH] Revert "quartz: Reaching a renderer in the filtergraph is > not an error." > > This reverts commit 62a0bd65d2fe9febd6928ff5912e84a34f76a97f. > --- > dlls/quartz/filtergraph.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/dlls/quartz/filtergraph.c b/dlls/quartz/filtergraph.c > index b249724..c53771e 100644 > --- a/dlls/quartz/filtergraph.c > +++ b/dlls/quartz/filtergraph.c > @@ -1042,8 +1042,9 @@ static HRESULT WINAPI > FilterGraph2_Connect(IFilterGraph2 *iface, IPin *ppinOut, > if (SUCCEEDED(hr)) { > unsigned int i; > if (nb == 0) { > - TRACE("Reached a renderer\n"); > - break; > + IPin_Disconnect(ppinfilter); > + IPin_Disconnect(ppinOut); > + goto error; > } > TRACE("pins to consider: %d\n", nb); > for(i = 0; i < nb; i++) > -- > 1.5.6.5 > > > > > Correct, I got this one wrong. Please revert my patch and apply Maarten's patch to fix infinite recursion.

1 0

Governance of Wine with respect to the Software Freedom Conservancy
by Jeremy White Nov. 14, 2008

Nov. 14, 2008

Hi folks, As you may recall, several years ago, we decided to work with the Software Freedom Conservancy to ask them to manage aspects of Wine that merited the shield of a formal organization. They have been great, and a great improvement over our former process. I thought I'd send an email out for the record, expressing what they do for us, and how that is governed. First, there are essentially 2 major assets they manage for us. They manage all funds donated to Wine - the donate button goes into a bank account they manage. They also hold trademarks to the Wine logo that they filed on our behalf. For decisions on how to spend funds, we've adopted a loose set of guidelines. That is, Dan Kegel, Alexandre, and myself are in contact with them. The goal is that all 3 of us agree on every decision, but 2 of the 3 of us must concur with any decision before it is effective. We three can appoint anyone else we choose to replace or augment the decision group. All decisions are CC'd to the WWN author (currently Zach Goldberg) for monitoring. The SFC will recognize a 'revolt' by the Wine project. That is, Dan, Alexandre and I can be overthrown, once you figure out our evil plans, if the SFC is persuaded that the majority of Wine contributors agree on that point. Patch count in the Wine tree will be the primary mechanism to recognize a contributor. Finally, all spending by the SFC on Wine's behalf for the last few years has been related to Wineconf. That has either been to pay for conference expenses directly (as in Reading, 2 years ago), or to help defray travel costs for Wine contributors to come to Wineconf (as happened this year). Cheers, Jeremy

1 0

Re: RFC: Wine Icons
by Branan Riley Nov. 14, 2008

Nov. 14, 2008

forgot CC on first send. On Fri, Nov 14, 2008 at 5:54 AM, Joel Holdsworth <joel(a)airwebreathe.org.uk> wrote: > Hi All, > > I notice that some of Wine's icons have been changed in recent releases. > In principle I think updating the icons is a great idea, but right now I > gotta say that icons in Wine are a real disaster. > > Take a look here: http://www.airwebreathe.org.uk/icons.png > > This is a screenshot of the shell folder select dialog. Out of those > icons My Documents looks the least broken - with it's wannabe 98/ME/2000 > styling. Desktop, "/", My Computer and Trash look like they've been > taken from large icons which have shrunk - badly, and with a broken > alpha channel. And the new golden Folder icons look completely out of > place - they bear no resemblance to anything else, they've been scaled > down poorly, they don't look like Windows icons, and they don't fit in > with the Gnome desktop (and I can't imagine they'd look good in KDE or > on Mac either). > > I'd really like for Wine to start using icons from the Tango project, or > similar. The purpose of Tango was to create a set of icons that are > clear to see, and look good on Windows, Gnome, KDE, and MacOS. Surely > that's exactly what we want? > > Note that ReactOS is using Tango, and it seems to be working out pretty > well for them! > > Any comments on that? > > Best Regards > Joel Holdsworth The problem with hardcoding Tango is that it won't necessarily match the user's desktop. On Linux and FreeBSD, I'd suggest finding a way to detect the current icon theme (perhaps determine which desktop environment is running, then read the config file for that desktop?) and use the freedesktop.org icon names and the XDG_DATA_DIRS variable to locate the icons. This wouldn't work on KDE3 (which doesn't use the freedesktop spec). In that case I would say fall back to the hicolor icons. On Mac, you should use the native mac icons, but that might not work to do Obj-C issues (I know nothing about mac programming, so maybe there's a way to get native icons without Obj-C?). This way, when theming is implemented, the icons and the theme will both match the user's desktop environment. It's more complicated than just implementing Tango, but visually it makes more sense. Branan

3 2

Re: imm32: implement ImmInstallIME(W/A)
by Juan Lang Nov. 14, 2008

Nov. 14, 2008

Hi Aric, minor nit: + if (rc == ERROR_SUCCESS) + return hkl; + else + { + FIXME("Unable to set IME registry values\n"); I think a WARN would be more approriate here. --Juan

1 0

Re: RFC: Wine Icons
by Branan Riley Nov. 14, 2008

Nov. 14, 2008

> I totally agree. Of course hardcoding visuals isn't nearly so cool as > doing them "properly", but right now that's what we've got - and these > hardcoded visuals are even being "upgraded", so if they're being > upgraded then wouldn't it be better to upgrade in the direction of some > kind of a standard? > > At least in the past the visuals sort-of looked consistent with Windows > 98. Now they don't look consistent with anything. Don't get me wrong: > the new icons I see aren't specially bad - it's just that they don't fit > with anything else. > > I wonder if we can fix this. > > Best Regards > Joel Holdsworth I don't have any problems with Tango in the short-term - Wine doesn't match my desktop anyway. I just don't want to see a huge amount of effort get put into it if a theming system is going to be put in place. But since the icons are being replaced anyway, I agree that using an already-existing icon set makes way more sense than creating all-new icons. Branan *sigh* the GMAIL web interface makes mailing lists such a pain. Sorry for getting this to you twice again, joel

1 0

re: Bugzilla - Add keyword and remove OS's
by James Mckenzie Nov. 14, 2008

Nov. 14, 2008

Sorry for the top post +1 for removing the Pre-X Mac OS's James McKenzie -----Original Message----- >From: Dan Kegel <dank(a)kegel.com> >Sent: Nov 14, 2008 8:35 AM >To: Wine Devel <wine-devel(a)winehq.org> >Subject: re: Bugzilla - Add keyword and remove OS's > >I think we should keep most of them, but classic Mac OS >(pre-X) can go, as we never worked there (not even Darwine), >and nobody cares about it anymore. I've deleted >Mac System 7, and will delete the rest of the classic >mac OS's if there is consensus. > >

1 0

Bugzilla - Add keyword and remove OS's
by Austin English Nov. 14, 2008

Nov. 14, 2008

Howdy, The OS list in bugzilla is a bit excessive. There are 16 OS's that I think we should remove, as no one is using them (HP-UX has one bug filed against it, but for all intents and purposes, it's not being used). Many of these aren't x86, so only could be used for Winelib anyway. Mac System 7 Mac System 7.5 Mac System 7.6.1 Mac System 8.0 Mac System 8.5 Mac System 8.6 Mac System 9.x BSDI AIX BeOS HP-UX IRIX Neutrino OpenVMS OS/2 OSF/1 While we're at it, I'd like to add PC-BSD and OpenSolaris. Lastly, how about a compiler keyword, for bugs related to compiler warnings/errors/etc.? -- -Austin

3 4

Re: Try#4 for IDirectDrawSurface_GetSurfaceDesc error checking in ddraw test
by chris ahrendt Nov. 14, 2008

Nov. 14, 2008

Stefan D

1 0

Try#4 for IDirectDrawSurface_GetSurfaceDesc error checking in ddraw test
by chris ahrendt Nov. 14, 2008

Nov. 14, 2008

Michael / All, Been busy for awhile so have not had the time to work on this patch but here is the 4th try and hopefully final version of the ddraw patch. I took Michaels suggestions and encorporated them into the patch as well. Please let me know if this patch is now ready to submit =) chris

2 1

Re: Bugzilla - Add keyword and remove OS's
by James Mckenzie Nov. 14, 2008

Nov. 14, 2008

Markus: I don't think that Wine will build on MacOS 9 or earlier anymore. James McKenzie -----Original Message----- >From: Markus Hitter <mah(a)jump-ing.de> >Sent: Nov 14, 2008 1:53 AM >To: Austin English <austinenglish(a)gmail.com> >Cc: Wine Developers List <wine-devel(a)winehq.org> >Subject: Re: Bugzilla - Add keyword and remove OS's > > >Am 14.11.2008 um 00:15 schrieb Austin English: > >> Howdy, >> >> The OS list in bugzilla is a bit excessive. [...] >> Mac System 7 >> Mac System 7.5 >> Mac System 7.6.1 >> Mac System 8.0 >> Mac System 8.5 >> Mac System 8.6 >> Mac System 9.x > >You could merge them to "MacOS 9 and before" > > >MarKus > >- - - - - - - - - - - - - - - - - - - >Dipl. Ing. Markus Hitter >http://www.jump-ing.de/ > > > > > >

2 1

Some oddity with kernel32/pipe tests on NT4 and W2K
by Paul Vriens Nov. 14, 2008

Nov. 14, 2008

Hi I'm looking into the timeout issue on NT4. The timeout seems to be coming from: 796 size = 32678; ... 799 ok(CreatePipe(&piperead, &pipewrite, &pipe_attr, size) != 0, "CreatePipe failed\n"); 800 ok(WriteFile(pipewrite, buffer, size, &written, NULL), "Write to anonymous pipe failed\n"); When I change it to write a smaller number of bytes: 800 ok(WriteFile(pipewrite, buffer, (size - 24), &written, NULL), "Write to anonymous pipe failed\n"); we don't have a timeout. Changing the 'size - 24' to a bigger number like 'size - 23' gives a timeout again. Also changing size to 16384 still needs that 'size - 24' in the WriteFile(). In fact every size I use I need a 'size - 24'; I can also make this timeout go away by specifying at least 'size + 24' in the CreatePipe() call. MSDN states that the passed size for CreatePipe us used as an suggestion. I guess NT4 and W2K don't guess/calculate that well? Any ideas? -- Cheers, Paul.

1 0