wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

winetest failing on Windows 2000, VIA AC 97 audio
by Jakob Eriksson 23 Dec '04

23 Dec '04

http://test.winehq.org/data/200412231000/2000_MarcelHekman/winmm:wave.txt Can we blacklist this driver somehow? AFAIK I submitted a black list patch before for this driver but it was silently dropped. regards, Jakob

1 0

MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)
by Mike Hearn 23 Dec '04

23 Dec '04

Hi ho, Every so often I try out my favourite game to see how well it runs in Wine. This time, I found the demo (I have the full game but the demo is easier to debug) was working well! The following snowboarding game: http://www.housemarque.com/games/supremesb/ssb_demo.exe is not only a lot of fun but also Very Nearly There in Wine. There are only two problems preventing it from running perfectly: 1) There seems to be a bug in our msvcrt file reading APIs. I've chased this one before and got nowhere, but maybe somebody more familiar with the code can find it. We seem to pass back corrupt data: with builtin msvcrt the demo complains with a nicely detailed assertion that it can't find a file marker it's looking for. Native MSVCRT from WinXP makes it work (once you set winver=winxp) 2) When racing, the sky is black. An OpenGL bug perhaps? Weirdly when it's showing the pre-recorded demos the sky is just fine. The rest of the graphics are perfect. Finally if you put it in desktop mode, an X protocol error occurs initialising OpenGL. The XGetWindowAttributes call complains of a bad window. I debugged this for a bit and got nowhere, it wasn't as straightforward as it looked. Suffice to say that at the point it died opengl32.dll had been initialised several times already with the same value for root_window, and it worked each time previously (yes sync was enabled). I think this definitely used to work, so it feels like some WM rewrite regression to me. I could well be wrong though. This seems to affect all OpenGL+desktop mode apps. To make the game let you choose OpenGL in the setup program it has to be run in win2k/winxp mode. I do not know why. If you get it going, see if you can beat my best time (when playing on Linux) of 2:02. Have fun! :) thanks -mike

3 5

MSVCRT, OpenGL bugs to look at (and a WM rewrite regression?)
by Jesse Allen 23 Dec '04

23 Dec '04

On Thu, 23 Dec 2004 00:43:20 +0000, Mike Hearn <mh(a)codeweavers.com> wrote: > > 2) When racing, the sky is black. An OpenGL bug perhaps? Weirdly when it's > showing the pre-recorded demos the sky is just fine. The rest of the > graphics are perfect. What graphics card and driver do you use? This is important. I use a Radeon 9200 and DRI. In Warcraft III+opengl under wine, things would "disappear", but then re-appear under different conditions. I have screen shots I can upload that shows this in action. I used to use an nvidia card with the official driver. Comparatively, the nvidia graphics setup rendered everything perfectly. > > Finally if you put it in desktop mode, an X protocol error occurs > initialising OpenGL. The XGetWindowAttributes call complains of a bad > window. I debugged this for a bit and got nowhere, it wasn't as > straightforward as it looked. Suffice to say that at the point it died > opengl32.dll had been initialised several times already with the same > value for root_window, and it worked each time previously (yes sync was > enabled). > > I think this definitely used to work, so it feels like some WM rewrite > regression to me. I could well be wrong though. > > This seems to affect all OpenGL+desktop mode apps. You are correct, it used to work. I just tried it yesterday and it didn't work for me either. > > To make the game let you choose OpenGL in the setup program it has to be > run in win2k/winxp mode. I do not know why. > > If you get it going, see if you can beat my best time (when playing on > Linux) of 2:02. Have fun! :) > > thanks -mike > > Unfortunately I can't try your game at the moment cause it will take me too long to download -- 2 KB/s down only =( Jesse

2 1

Re: MSI: First go at thread safety for MSI records
by Alexandre Julliard 23 Dec '04

23 Dec '04

Mike McCormack <mike(a)codeweavers.com> writes: > Index: dlls/msi/msipriv.h > =================================================================== > RCS file: /home/wine/wine/dlls/msi/msipriv.h,v > retrieving revision 1.32 > diff -u -r1.32 msipriv.h > --- dlls/msi/msipriv.h 22 Dec 2004 15:05:07 -0000 1.32 > +++ dlls/msi/msipriv.h 23 Dec 2004 01:43:40 -0000 > @@ -54,6 +54,7 @@ > UINT magic; > UINT type; > UINT refcount; > + CRITICAL_SECTION cs; > msihandledestructor destructor; Do you really need a separate critical section for every single MSI object? That seems a bit overkill to me. -- Alexandre Julliard julliard(a)winehq.org

4 3

Going forward with fixing up tests failing because not run on visible desktop.
by Jakob Eriksson 23 Dec '04

23 Dec '04

Followup on tests failing because they are run as an invisible service on Windows: ---------------------------------------------------------------------------------- Now that we have bRunningOnVisibleDesktop=0 in the report, how do we make use of it? Do we mark on the server side which tests fail because of it, or should we add a flag to the ok() macro? I would like to have the information stored in the test code somehow. It would document implicitly which functions only work in visible mode. If we had a global variable named "running_on_visible_desktop", we would have code like this in the tests: if (running_on_visible_desktop) { ok(EnumEnhMetaFile(hdcDisplay, hMetafile, emf_enum_proc, dx, &rc), "EnumEnhMetaFile error %ld\n", GetLastError()); } Or we could mark them like this: expect_to_fail_if_running_on_visible_desktop { ok(EnumEnhMetaFile(hdcDisplay, hMetafile, emf_enum_proc, dx, &rc), "EnumEnhMetaFile error %ld\n", GetLastError()); } Where expect_to_fail_if.... should do some magic... regards, Jakob

1 0

Re: [OLE #10] Make out of process COM work with OXID based marshal ids
by Robert Shearman 23 Dec '04

23 Dec '04

1 0

Looking for a Wine consultant
by Raetus Egli 23 Dec '04

23 Dec '04

I am sending this message for a friend of mine. I am the head of a company that is trying to migrate a VB6 system on WinNT to Linux. We would like to use this application under Debian Sarge using Wine. If you have experience in porting VB6 applications using Wine and have some free time to consult with an in-house developer it would be greatly appreciated. We would like to get the project up and running as soon as possible. If you are interested please get back to me at pyadegar(a)honeymae.com as soon as possible. Thanks.

1 0

Re: Add ntoskrnl.exe.so
by Mike Hearn 23 Dec '04

23 Dec '04

On Wed, 22 Dec 2004 13:29:35 -0800, Steven Edwards wrote: > kernel32 can't be a dependancy on ntoskrnl. We are going to need to redesign Wine if we are going > to have a ntoskrnl implementation. Why not? This isn't ReactOS, ntoskrnl is just another DLL from the SafeDisc perspective. Its implementation details shouldn't matter.

3 5

Re: AppDB TODO update: Templates
by Stefan Pflüger 23 Dec '04

23 Dec '04

> Search engines don't like dynamic pages. So using the lostwages way > would really be preferred. > And we're trying to get rid of the tables and use CSS positioning. So > don't count on those. Al tough it won't change the main idea I think. > > Paul > > Well one could easily ship around the search engine problem by a) Using mod_rewrite or b) Setting a var and including index.php from those files I'd prefer getting any HTML code out of appdb into the templates to make it easy to fully change the design without touching any line of PHP code. Changes in the design won't change anything in the concept. Stefan

1 0

Looking for a Wine consultant.
by Pouya Yadegar 22 Dec '04

22 Dec '04

I am the head of a company that is trying to migrate a VB6 system on WinNT and would like to use that application under Debian Sarge using Wine. If you have experience in porting VB6 applications using Wine and have some free time to consult an in house developer it would be appreciated. We would like to get the project up and running as soon as possible. If your interested please get back to me at pyadegar(a)honeymae.com as soon as possible. Thanks.

1 0

Re: My "Helping Applications Work" Guide
by Dan Kegel 22 Dec '04

22 Dec '04

Mike Hearn wrote: > This quote: "An alternative option, perhaps more effective and expensive, is to pay wine > developers for their work on your application, either directly through a > negotiated contract or indirectly by posting a bounty" ... could it have a > link to CodeWeavers please? I think it's fair to say that we're the number > one provider of these sorts of services by a long way, but currently we're > still quite dependent on people being able to find us, so additional links > and publicity is needed. Yeah, a link to http://codeweavers.com would be appropriate. You might want to link to a list of vendors who are willing to help update Wine to work with particular apps and contribute the fixes back to the winehq tree per the LGPL, e.g. http://codeweavers.com http://www.macadamian.com http://www.itomig.de Itomig's a newcomer, but what the heck, they seem to be interested in helping the Wine community. (Also maybe Transgaming, but I don't know if they're willing to work on the winehq tree anyore). - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Re: [OLE #10] Make out of process COM work with OXID based marshal ids
by Robert Shearman 22 Dec '04

22 Dec '04

Mike Hearn wrote: >This patch makes InstallShield work again, and should let you get >further Bill. > >- Ensure all intermediate threads join the original apartment >- Make the listener thread fully apartment scoped (one per apt not per > process) >- Improve "already have mid" error message >- Rename _StubReaderThread to stub_dispatch_thread >- Improve tracing > > Sorry Mike, but we want to *remove* the current hacks for the RPC-runtime emulating named pipe code, not adding more. The correct approach for the crash in _LocalServerThread is to use table-strong marshaling once and then copy the contents of the stream to the pipe for each iteration in the loop, instead of marshaling each time. The correct approach for the crash in _StubReaderThread is to make it execute in the correct apartment - either by sending a window message to the STA window or by joining the MTA. I believe you had a patch for this in July or August when we last worked on this. Rob

4 12

Re: Add ntoskrnl.exe.so
by Steven Edwards 22 Dec '04

22 Dec '04

Hi, --- Ivan Leo Puoti <ivanleo(a)gmail.com> wrote: > Add ntoskrnl, only a few stub functions for now, so we have something to > work on. > All the functions needed by safedisc are in the spec, we can't implement > them all > as stubs ATM because for two of them we need defines from the ddk, > I'll be sending a patch to add ntddk.h in the near future. Check the ReactOS or w32api DDK. Its public domain. > +MODULE = ntoskrnl.exe > +IMPORTS = kernel32 > +DLLMODE = native kernel32 can't be a dependancy on ntoskrnl. We are going to need to redesign Wine if we are going to have a ntoskrnl implementation. > +BOOLEAN WINAPI PsGetVersion(PULONG MajorVersion OPTIONAL, PULONG MinorVersion OPTIONAL, > + PULONG BuildNumber OPTIONAL, PUNICODE_STRING CSDVersion > + OSVERSIONINFOA version; > + version.dwOSVersionInfoSize=sizeof(OSVERSIONINFOA); > + GetVersionExA(&version); We need to either duplicate or move the version code in to ntoskrnl.exe. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

1 0

Re: Re: AppDB TODO update: Templates
by Chris Morgan 22 Dec '04

22 Dec '04

I think you are covering the appropriate mailing lists. If you'd like to chat in real-time about hacking appdb, channel #winehackers on irc.freenode.net is a good place. Tony, Jon and myself are frequently there and chat at least every other day about appdb related things. About the templates, is this what Jeremy did in the lostwages archive(www.winehq.org/cvsweb/lostwages)? I wasn't too familiar with the changes he made and thought it would be good to discuss things prior to making such large changes to the appdb code. Anything that improves the design is more than welcome. Chris > > From: Stefan Pflüger <stefan(a)homepage4us.de> > Date: 2004/12/22 Wed PM 02:33:18 EST > To: wine-devel(a)winehq.org > CC: cmorgan(a)alum.WPI.EDU, appdb(a)winehq.org > Subject: Re: AppDB TODO update: Templates > > Basically, I'll implement a class that is able to read a template file > and that can assign content to special tags in there. > > The index.php would create an object of this class using a "main > template" that includes all parts of the page that are static (header, > footer, the main html tables). Depending on a GET variable, the > index.php calls a function whose returned data will be used as the main > content, it would be for example index.php?action=browseapps to get to > the "Browse Apps" page. > > The content of the sidebar, the banner ad etc. would also be created by > a function like it's already done (see banner_display() in > include/banner.php), but instead of just echo-ing this somewhere in the > right place, it would also be fed into the template engine that again > replaces the corresponding tags in the main template. Those functions > might also use the template class to implement their own sub-templates. > > In the end, the template class object in index.php should have the > complete output ready for sending it to the user. > > Hopefully, my short explanation was good enough to illustrate the concept. > > > Stefan > > PS.: What's the correct list/address to send mails concerning this > discussion to? I'm sending them to the wine-devel list atm, CCing to > Chris Morgan and appdb(a)winehq.org... > >

2 1

Re: AppDB TODO update: Templates
by Chris Morgan 22 Dec '04

22 Dec '04

Cool, thanks for claiming this so we don't have people stepping on each others toes. Would you mind showing a little bit of what you planned on changing? It would be nice to have agreement that this was the direction we wanted to go before a big patch was submitted. Chris > > From: Stefan Pflüger <stefan(a)homepage4us.de> > Date: 2004/12/22 Wed PM 01:05:06 EST > To: wine-devel(a)winehq.org > CC: appdb(a)winehq.org > Subject: AppDB TODO update: Templates > > Hello, > > the last update added > > +# incorporate templates into appdb to simplify code, Jeremy says we can > +borrow from lostwages(winehq.org/cvsweb/lostwages) for this > > to the TODO file. > > At the moment, I'm trying to use AppDB for another project and I already > planned on implementing templates. > If nobody else wants to do the job, I'll go ahead and send you a patch > as soon as I'm finished. > > Stefan Pflüger > >

2 1

Writing an app. using existing dll
by Per Arnold Blåsmo 22 Dec '04

22 Dec '04

Hi, I have a windows-dll and wants to make an app that runs on Linux under wine using this dll. I have the API description for this dll, but not the source code. I there any possibility for that using i.e. winelib and is there any howto to get me started. PerA.

2 1

AppDB TODO update: Templates
by Stefan Pflüger 22 Dec '04

22 Dec '04

Hello, the last update added +# incorporate templates into appdb to simplify code, Jeremy says we can +borrow from lostwages(winehq.org/cvsweb/lostwages) for this to the TODO file. At the moment, I'm trying to use AppDB for another project and I already planned on implementing templates. If nobody else wants to do the job, I'll go ahead and send you a patch as soon as I'm finished. Stefan Pflüger

2 1

Re: Implement DceErrorInqText
by Dmitry Timoshkov 22 Dec '04

22 Dec '04

"Bill Medland" <billmedland(a)mercuryspeed.com> wrote: > +RPC_STATUS RPC_ENTRY DceErrorInqTextW (unsigned long e, unsigned short *b) > +{ > + DWORD count; > + if (acceptable_rpc_code (e)) It would be much more natural to make FormatMessageW to decide whether a passed error code is valid or not, i.e. if it exists in the system message table. > + { > + count = FormatMessageW (FORMAT_MESSAGE_FROM_SYSTEM | > + FORMAT_MESSAGE_IGNORE_INSERTS, > + NULL, e, 0, b, /* I don't know!!! */ 65535, NULL); 256 (or 1024) is a reasonable margin I believe, at least messages in Wine are much shorter of even 256. > + } > + else > + count = 0; > + if (!count) > + { > + MultiByteToWideChar(CP_ACP, 0, cszInvalidCode, -1, b, 65535 /* ??? */); A message about invalid code should be localizable as well, so it should be either loaded by LoadString or even by FormatMessage for consistency IMO. winerror.h from PlatformSDK has the following definition which matches your error text ("The error specified is not a valid Windows RPC error code.\r\n"): // // MessageId: RPC_S_NOT_RPC_ERROR // // MessageText: // // The error specified is not a valid Windows RPC error code. // #define RPC_S_NOT_RPC_ERROR 1823L -- Dmitry.

3 5

Re: wine/dlls/cabinet cabextract.c
by Andreas Mohr 22 Dec '04

22 Dec '04

Hi, On Wed, Dec 22, 2004 at 11:11:32AM -0600, Alexandre Julliard wrote: > ChangeSet ID: 14986 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2004/12/22 11:11:32 > > Modified files: > dlls/cabinet : cabextract.c > > Log message: > Revert previous patch, that's not a leak. Nice, but... ;-) [get ready to read my usual "not commented" complaint] Why isn't there a comment nearby? 8 weeks later Joe Janitor 2's source code analyzer tool will strike gold again, and then you'll have fun with another patch "correcting" things that turn(ed) out shouldn't be corrected... Andreas Mohr

1 0

Re: Getting rid of async.h
by Alexandre Julliard 22 Dec '04

22 Dec '04

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > - we maintain on the client side whether there's still some pending > async op on the current thread (this is needed in optimizing some wait > operations) That part doesn't look right, you clear the flag when removing the last async operation on an fd, but this bears no relation to the number of async operations in the current thread. It seems to me this could instead be done entirely on the client side, since we need to allocate and free an async structure for each operation we should be able to maintain a counter of them on the client side. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll / kernel32: #52
by Alexandre Julliard 22 Dec '04

22 Dec '04

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > +/* FIXME: 0xFFFFFFFF is our shortcut for global table > + * we could also tweak init_atom_table request to get a handle to the > + * global table in wineserver > + */ > +#define GLOBAL_ATOM_TABLE ((void*)0xFFFFFFFF) Yes, you need to get a valid handle here, 0xffffffff is the current process pseudo-handle and we don't want to overload that meaning. Also your local table allocation is not thread-safe, it can potentially leak an atom table. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: test.h: problem with ok's argument evaluation order
by Alexandre Julliard 22 Dec '04

22 Dec '04

Rein Klazes <wijn(a)wanadoo.nl> writes: > --- wine/include/wine/test.h 2004-05-04 08:10:39.000000000 +0200 > +++ mywine/include/wine/test.h 2004-12-20 15:29:39.000000000 +0100 > @@ -53,7 +53,8 @@ extern void winetest_trace( const char * > > #endif /* __GNUC__ */ > > -#define ok_(file, line) (winetest_set_location(file, line), 0) ? 0 : winetest_ok > +#define winetest_ok_(cond, args...) (cond) ? winetest_ok(TRUE, args) : winetest_ok(FALSE, args) > +#define ok_(file, line) (winetest_set_location(file, line), 0) ? 0 : winetest_ok_ Unfortunately varargs macros are not portable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Merging the AppDB Documentation and the WineHQ documentation pages
by Scott Ritchie 21 Dec '04

21 Dec '04

Mike said this about my new "helping applications work" page: >Looks great! I'd suggest putting it in the Documentation section, and >then linking to it from the appdb page. This then prompted me to wonder "which documentation section?" This is kind of confusing: I click on documentation at the main wine page, and I get some useful stuff. I wander into the AppDB page, click on documentation, and I get some different stuff. Methinks we should just dump them all into one page. This has the added benefit of informing people without the wherewithal to click "Applications" that there is, in fact, an AppDB. On another note, it looks like the AppDB documentation is in PHP, rather than the normal template format like the rest of the website. Is this a good idea? Thanks, Scott Ritchie

1 0

Re: wine/dlls/cabinet cabextract.c
by Mike McCormack 21 Dec '04

21 Dec '04

This patch breaks IE6 install. Mike Alexandre Julliard wrote: > ChangeSet ID: 14647 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2004/12/02 11:55:41 > > Modified files: > dlls/cabinet : cabextract.c > > Log message: > James Hawkins <truiken(a)gmail.com> > Fix cabextract memory leak. > > Patch: http://cvs.winehq.org/patch.py?id=14647 > > Old revision New revision Changes Path > 1.15 1.16 +2 -0 wine/dlls/cabinet/cabextract.c

1 0

Some performance stats
by Dmitry Timoshkov 21 Dec '04

21 Dec '04

Hello all, while debugging one of applications I'm working on I noticed a lot of GetPrivateProfileString calls with the same file name but in different case causes profile code to open and parse system.ini again. I sent a patch which helps to find a cached file in that case and do not parse it again. I had a thought that another speed improvement might be to use FindFirstFileW instead of CreateFileW/GetFileTime to retrieve last modification time of a file. I wrote a test under Windows to see which of FindFirstFileW or CreateFileW is faster. The test is attached. Here are the results (for 10000 loops) running the same binaries in Wine and Windows 2000 SP4 (hard disks are the same in both systems): =================================================================== Win2k SP4/NTFS volume: test_CreateFileW: P3/1GHz time elapsed 363 ms test_FindFirstFileW: P3/1GHz time elapsed 547 ms Wine/ext3 volume: test_CreateFileW: P3/1GHz time elapsed 543 ms test_FindFirstFileW: P3/1GHz time elapsed 1650 ms =================================================================== CreateFileW is only 1.5 times slower in Wine than in Windows, that's really not bad (especially taking into account Wine boot time), but still there is a possibility for an improvement. FindFirstFileW is 3 times slower in Wine than CreateFileW, while it's only 1.5 times slower in Windows. This needs to be optimized. -- Dmitry.

1 0

Jump to page:

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