August 2004 - Wine-Devel - list.winehq.org

Re: Wrong call convention for SHAllocShared & co?

by Francois Gouget

Still looking in undocshell.h, I see we have: BOOL WINAPI GetFileNameFromBrowse( HWND hwndOwner, LPSTR lpstrFile, DWORD nMaxFile, LPCSTR lpstrInitialDir, LPCSTR lpstrDefExt, LPCSTR lpstrFilter, LPCSTR lpstrTitle); But in the Platform SDK's the prototype is: SHSTDAPI_(BOOL) GetFileNameFromBrowse(HWND hwnd, LPWSTR pszFilePath, UINT cbFilePath,LPCWSTR pszWorkingDir, LPCWSTR pszDefExt, LPCWSTR pszFilters, LPCWSTR pszTitle); So is this an Ansi or a Unicode function? Or maybe it's one of these AW Ansi/Unicode functions? In that case the implementation is wrong because it definitely expects to receive Ansi strings. Same question for PickIconDlg(). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

Aug. 21, 2004

Wrong call convention for SHAllocShared & co?

by Francois Gouget

In the platform SDK's shlobj.h I find: HANDLE _SHAllocShared(LPCVOID pvData, DWORD dwSize, DWORD dwDestinationProcessId); Notice the lack of a WINAPI and the leading underscore. So this would indicate a cdecl API. But in dlls/shell32/undocshell.h I see: HANDLE WINAPI SHAllocShared(LPVOID pv, ULONG cb, DWORD pid); This really looks like the same function, just without the underscore. Furthermore shell32.spec says: 520 stdcall SHAllocShared (long long long) So who's right? The platform SDK that says this is a cdecl function or Wine's headers? There's the same issue for SHFreeShared, SHLockShared and SHUnlockShared. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

Aug. 21, 2004

Re: MS Visio 2000 not working with wine.

by Tom

James Courtier-Dutton wrote: > Tom wrote: > >> James Courtier-Dutton wrote: >> >>> Has anyone got MS Visio 2000 working with wine? >>> >>> James >>> >>> >>> >> >> Yes. >> >> Tom >> >> > > I am using the current cvs of wine. Without any Windows OS already > installed. > I attach a debug trace of trying to install Visio2000. > wine Visio2000.EXE > > Can anyone give me advice on how to diagnose this further? > > James > > > Hi James, Well it will install and run but your going to have to put some work into it :) I just installed it again in a clean .wine and this is what I did. 1) install dcom98 2) install native windows installer 3) install IE 6.0 4) remove conflicting dll's from IE 6 install that halts the Visio update. 5) install a couple native dlls so the installer will run 6) install visio 7) replace dlls that I removed from IE 6 install 8) tweak the config a little 9) run Visio Regards, Tom A proof shot that it works with wine :-)

Aug. 21, 2004

Re: Re: make CryptSetProviderEx update the provider Name and TypeName to registry

by James Hawkins

I just ran a test programming in windows to see how the registry is changed by called CryptSetProviderEx with the CRYPT_DELETE_DEFAULT flag. When the CRYPT_DELETE_DEFAULT flag is used, the Name value of the Type XXX key is removed, but not the TypeName, which solves the problem of not being able to get to the TypeName. I will rewrite this patch with the new behavior and send it shortly. On Fri, 20 Aug 2004 13:11:12 -0700, James Hawkins <truiken(a)gmail.com> wrote: > I'm working on a test app that I hope wil shine some light on how > windows gets the Name and TypeName values back in the registry after > they've been deleted. The problem is that the only instance of the > Name and TypeName data is in the DllRegisterServer function of the > provider dll. I couldn't think of any other way to get to that data > to get it in the registry, but I will be testing this in windows. > What im thinking is that windows might not even delete the key at all. > If you have any suggestions it would help a lot. > > > > On Fri, 20 Aug 2004 12:48:07 -0700, Alexandre Julliard > <julliard(a)winehq.org> wrote: > > James Hawkins <truiken(a)gmail.com> writes: > > > > >> Changelog > > >> * Call provider.dll's DllRegisterServer from CryptSetProviderEx to > > >> update the Name and TypeName values in the registry properly when > > >> setting the default provider > > > > It doesn't seem right to call DllRegisterServer from there, IMO it > > should only be called when the dll is installed. Do you have evidence > > that Windows does it this way? > > > > -- > > Alexandre Julliard > > julliard(a)winehq.org > > > > > -- > James Hawkins > -- James Hawkins

Aug. 21, 2004

Re: Optimize Critical Section Functions

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Yes, I agree. In fact the patch actually decreases performance. > Test: 10,000,000 calls to EnterCriticalSection & LeaveCriticalSection, > simulating fast path on critical sections. > Results: > Win2k - 1000ms > Wine w/ patch - 1346ms > Wine w/o patch - 1294ms > > I think the best way to improve performance of the critical section > functions is to rewrite them in assembly and I will submit a patch > doing so when I have a spare moment. I don't think that's necessary either, unless you have good evidence that the critical section non-contention path represents a significant amount of the total time spent by an application. IMO we have much bigger performance issues to solve first, before we make the critical section code unreadable just to save a couple of cycles. -- Alexandre Julliard julliard(a)winehq.org

Aug. 21, 2004

Re: MS Project 2000 not working in wine.

by Tom

James Courtier-Dutton wrote: > Has anyone got MS Project 2000 working in wine? > > James > > > I tried it a couple times and get about 80% into the install. It stops at the same spot each time. fixme:powermgnt:SetThreadExecutionState (0x0): stub, harmless. fixme:ntdll:NtAdjustPrivilegesToken (0x4c,0x00000000,0x4055e0e8,0x00000000,(nil),(nil)),stub! I/O operation aborted Tom

Aug. 21, 2004

Re: Optimize Critical Section Functions

by Robert Shearman

Alexandre Julliard wrote: >Michael Stefaniuc <mstefani(a)redhat.com> writes: > > > >>Andreas Mohr wrote: >> >> >>>Umm, this should go into a global header file, right? >>>The theory being that it would be useful at many more performance critical >>>Wine places... >>>But I have to admit that I don't know which header file this should >>>be... >>> >>> >>Like in the Linux kernel (where this seems to come from) in compiler.h >>or something like that. >> >> > >No, I don't think we want to do that, it would only encourage people >to sprinkle this stuff all over the place believing they are >"optimizing" the code. This should only be added in places where it >makes a significant difference, demonstrated with benchmark results. > > Yes, I agree. In fact the patch actually decreases performance. Test: 10,000,000 calls to EnterCriticalSection & LeaveCriticalSection, simulating fast path on critical sections. Results: Win2k - 1000ms Wine w/ patch - 1346ms Wine w/o patch - 1294ms I think the best way to improve performance of the critical section functions is to rewrite them in assembly and I will submit a patch doing so when I have a spare moment. Rob

Aug. 21, 2004

Re: MS Visio 2000 not working with wine.

by Tom

James Courtier-Dutton wrote: > Has anyone got MS Visio 2000 working with wine? > > James > > > Yes. Tom

Aug. 21, 2004

MS Project 2000 not working in wine.

by James Courtier-Dutton

Has anyone got MS Project 2000 working in wine? James

Aug. 21, 2004

MS Visio 2000 not working with wine.

by James Courtier-Dutton

Has anyone got MS Visio 2000 working with wine? James

Aug. 21, 2004

Re: Added path settings to winecfg

by Marcelo Duarte

Jacek Caban escreveu: > But what about other languages, which nobody updates as you do? > I have one more question: where can I find this script? I see that > polish translation is far from complete and I thought I could work > aroun dit. > > Thanks, > Jacek Sorry for the delay. Atached is the patch to create a trans.sh in in wine/tools. To run in wine directory run tools/trans.sh and it creates tools/trans_html/index.html This is a modified version of the original patch that Vincent Beron send in January.

Aug. 21, 2004

[Fwd: Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]]

by Mike Hearn

-------- Forwarded Message -------- From: Con Kolivas <kernel(a)kolivas.org> To: Mike Hearn <mike(a)navi.cx> Cc: ck(a)vds.kolivas.org Subject: Re: [ck] Re: Threading issues? [ck-request(a)vds.kolivas.org: ck Digest, Vol 3, Issue 16] Date: Sat, 21 Aug 2004 10:39:21 +1000 Mailer: Mozilla Thunderbird 0.7.1 (X11/20040626) Mike Hearn wrote: > On Tue, 17 Aug 2004 10:06:46 +0200, Andreas Mohr wrote: > >>Are we doing some big no-nos in the threading area here? >>(or maybe it's just done the way it is because we cannot do it a >>different, better way?) >> >>For the whole discussion, please see >>http://bhhdoa.org.au/pipermail/ck/2004-August/000428.html > > > Well, apparently we don't use sched_yield, so the problem must > lie somewhere else. Maybe Con can help us out here? Alexandre says he > doesn't know what the issue is either and somebody needs to investigate. I > guess we do need to concern ourselves over the details :) Interesting. Probably the most valuable information is that it seems to work fine if we artificially limit the threads to exactly the same timeslice _or_ we put them at such a low priority that they are forced to be guaranteed to round robin one task at a time. This is the way 2.4 used to work which is why with the new 2.6 schedulers which do far more out-of-order rescheduling some applications have a problem; particularly under load. I suspect it's actually the latter issue. Locking between threads should prevent that being a problem, though. You already mentioned that you dont use sched_yield() and I couldn't even begin to look at the wine code myself so perhaps you know something more. The other (useful?) bit of information is that one person solved his issue with this: >I had a similar problem with Cedega. I fixed it by editing the >Cedega/WineX config file and specifying that I wanted to use ALSA >instead of WineOSS, then disable mmap for ALSA. I'm not sure if that fixes all the problems but perhaps that helps. I'm interested in getting this resolved so please keep me informed. Cheers, Con P.S. Sorry I had trouble posting to your newsgroup.

Aug. 21, 2004

Re: Limit number of DirectDrawClipper_SetClipList FIXMEs

by James Hawkins

> the program starts, but the difference between this and a regular > non-static variable is that this static variable holds whatever value > it contains That wasnt very clear so I'll try to explain better. The bottom line is that the value of the static variable is retained between repeated function calls to the same function. See http://www-ee.eng.hawaii.edu/Courses/EE150/Book/chap14/subsection2.1.1.6.ht… for more information. On Sat, 21 Aug 2004 02:52:31 -0700, James Hawkins <truiken(a)gmail.com> wrote: > Tobias wrote: > > > + if (warned++ < 10 && lprgn != NULL) > > Stefan wrote: > > for me this looks like > > > > if (0 < 10 && lprgn != NULL) > > The variable 'warned' doesn't actually turn out to be zero all of the > time. It is a static variable, so it is initialized once to zero when > the program starts, but the difference between this and a regular > non-static variable is that this static variable holds whatever value > it contains. If this code snippet runs then warned will increase by > one each time and this new value will not be set back to zero the next > time the block runs. > > > > On Sat, 21 Aug 2004 11:08:09 +0200, Stefan Leichter > <stefan.leichter(a)camline.com> wrote: > > Am Freitag, 20. August 2004 18:37 schrieb Tobias Burnus: > > > + > > > HRESULT WINAPI Main_DirectDrawClipper_SetClipList( > > > - LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwSize > > > + LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwFlag > > > ) { > > > ICOM_THIS(IDirectDrawClipperImpl,iface); > > > - FIXME("(%p,%p,%ld),stub!\n",This,lprgn,pdwSize); > > > + static int warned = 0; > > > + if (warned++ < 10 && lprgn != NULL) > > Hello, > > > > for me this looks like > > > > if (0 < 10 && lprgn != NULL) > > > > what is the same like > > > > if (lprgn != NULL) > > > > I thing you meant something different > > > > Bye Stefan > > > > > > > -- > James Hawkins > -- James Hawkins

Aug. 21, 2004

Re: Limit number of DirectDrawClipper_SetClipList FIXMEs

by James Hawkins

Tobias wrote: > > + if (warned++ < 10 && lprgn != NULL) Stefan wrote: > for me this looks like > > if (0 < 10 && lprgn != NULL) The variable 'warned' doesn't actually turn out to be zero all of the time. It is a static variable, so it is initialized once to zero when the program starts, but the difference between this and a regular non-static variable is that this static variable holds whatever value it contains. If this code snippet runs then warned will increase by one each time and this new value will not be set back to zero the next time the block runs. On Sat, 21 Aug 2004 11:08:09 +0200, Stefan Leichter <stefan.leichter(a)camline.com> wrote: > Am Freitag, 20. August 2004 18:37 schrieb Tobias Burnus: > > + > > HRESULT WINAPI Main_DirectDrawClipper_SetClipList( > > - LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwSize > > + LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwFlag > > ) { > > ICOM_THIS(IDirectDrawClipperImpl,iface); > > - FIXME("(%p,%p,%ld),stub!\n",This,lprgn,pdwSize); > > + static int warned = 0; > > + if (warned++ < 10 && lprgn != NULL) > Hello, > > for me this looks like > > if (0 < 10 && lprgn != NULL) > > what is the same like > > if (lprgn != NULL) > > I thing you meant something different > > Bye Stefan > > -- James Hawkins

Aug. 21, 2004

Re: Limit number of DirectDrawClipper_SetClipList FIXMEs

by Andreas Mohr

Hi, On Sat, Aug 21, 2004 at 11:08:09AM +0200, Stefan Leichter wrote: > Am Freitag, 20. August 2004 18:37 schrieb Tobias Burnus: > > + > > HRESULT WINAPI Main_DirectDrawClipper_SetClipList( > > - LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwSize > > + LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwFlag > > ) { > > ICOM_THIS(IDirectDrawClipperImpl,iface); > > - FIXME("(%p,%p,%ld),stub!\n",This,lprgn,pdwSize); > > + static int warned = 0; > > + if (warned++ < 10 && lprgn != NULL) > Hello, > > for me this looks like > > if (0 < 10 && lprgn != NULL) > > what is the same like > > if (lprgn != NULL) > > I thing you meant something different Note that warned is defined to be static. Maybe go back in your corner and find out what that means? :-) (or it might just be that you missed the static part) Andreas Mohr

Aug. 21, 2004

Re: Limit number of DirectDrawClipper_SetClipList FIXMEs

by Stefan Leichter

Am Freitag, 20. August 2004 18:37 schrieb Tobias Burnus: > + > HRESULT WINAPI Main_DirectDrawClipper_SetClipList( > - LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwSize > + LPDIRECTDRAWCLIPPER iface,LPRGNDATA lprgn,DWORD pdwFlag > ) { > ICOM_THIS(IDirectDrawClipperImpl,iface); > - FIXME("(%p,%p,%ld),stub!\n",This,lprgn,pdwSize); > + static int warned = 0; > + if (warned++ < 10 && lprgn != NULL) Hello, for me this looks like if (0 < 10 && lprgn != NULL) what is the same like if (lprgn != NULL) I thing you meant something different Bye Stefan

Aug. 21, 2004

Re: Compile on AMD Opetron

by Steven Edwards

Hi Chuck, --- chall(a)bcrl.stcloudstate.edu wrote: > If you need access to a AMD Opetron box I can setup remote access > (via > SSH) so you can test the code, or I can try the patches (if any) > sent. I have quite a few patches for native Opertron x86-64 support on my account at sourceforge but I doubt you want a 64bit wine as it wont let you run any normal Windows apps. Try passing -m32 to gcc to see if it clears up. Thanks Steven __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

Aug. 21, 2004

New Darwine Binary Released

by Sanjay Connare

Hey All, I am proud and happy to announce the release of a new binary labeled Darwine 20040820 DP. This binary is based upon the 20040813 wine release. The majority of changes for this release can be viewed: http://cvs.winehq.org/cvsweb/wine/ChangeLog It is being released as a DEVELOPER PREVIEW so USE AT YOUR OWN RISK! It is not yet suited for mass distribution or general user use. This release in addition to all of the fixes from the wine team includes many Mac OS X optimizations and fixes. It also includes WineHelper a native Mac OS X application that helps launch .exe's. It allows for .exe's to be double clicked in the finder like any other application and essentially bypasses the need to run wine via the command line. The Darwine libraries have been moved from their default installation location of /usr/local to a more Mac OS X friendly location /Library/Darwine. Applications and WineHelper are installed in /Applications/Darwine. This new binary also automatically uninstalls the previous binary if it is found to be installed. For uninstall to occur the user must enter an administrator's password. If the correct password is entered the uninstaller will return some errors however the old version of Darwine will be removed and the install of this new binary can commence by reopening the installer package. A new uninstaller is included with this release that simplifies the uninstall process thanks to the new location of libraries. The binary has been split into two releases one being this release and a soon to be released Darwine SDK. The Darwine SDK will contain the source for both wine and WineHelper, all of the header files, winegcc, winebuild tools and many examples and scripts that will allow open source apps to be compiled using these tools. Please report bugs to the darwine SourceForge Bug Tracking System, and to the darwine-devel mailing-list. Also any comments, questions or concerns can also be posted to the darwine-devel mailing-list. Enjoy this new release. Thanks, ~Sanjay Connare

Aug. 21, 2004

Compile on AMD Opetron

by chall＠bcrl.stcloudstate.edu

I tried to compile wine-2004813 on a AMD Opetron this is what I found. ./configure No Problems found. make depend No Problems found. make **FAILS** chuck(a)sniper wine-20040813 $ make make[1]: Entering directory `/home/chuck/src/wine/wine-20040813/libs' make[2]: Entering directory `/home/chuck/src/wine/wine-20040813/libs/port' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o interlocked.o interlocked.c interlocked.c:248:3: #error You must implement the interlocked* functions for your CPU make[2]: *** [interlocked.o] Error 1 make[2]: Leaving directory `/home/chuck/src/wine/wine-20040813/libs/port' make[1]: *** [port] Error 2 make[1]: Leaving directory `/home/chuck/src/wine/wine-20040813/libs' make: *** [libs] Error 2 chuck(a)sniper wine-20040813 $ After looking at the file libs/port/interlocked.c I noticed that there are special instructions for the UltraSPARC proc. Since I do not read or know asm, I looked at the #include for for Solaris (/usr/include/synch.h). pulled from solaris 9 on sparc. (/usr/include/synch.h) /* * synch.h: * definitions needed to use the thread synchronization interface */ I then looked through a number of other include files and noticed that all this seems to be is a control for threads. Under linux on the AMD Opetron could you not use the pthreads.h #include file? If you need access to a AMD Opetron box I can setup remote access (via SSH) so you can test the code, or I can try the patches (if any) sent. Have Fun! Chuck Hall

Aug. 21, 2004

Suggestion for wine-user

by Geoffrey Leach

Perhaps some "worked examples"? It would be helpful to be able to have a set of examples that would illustrate the basic features of Wine. For example: o A "Hello World" .exe that used only the .dll files in the dist. o A script that executed a Windoze app that required only minimal configuration -- for example, just the mount point used for C: o A script that executed a (local) .exe that had its own (local) .dll files (both on the Unix side) Kudos to whoever put together the rpm. Regards.

Aug. 20, 2004

Re: IShellLink and non-existant exe files

by Christian Costa

Hi, I don't know much about this code but some line below there is: Stream_WriteLocationInfo( stm, exePath ); In our case exePath is still empty. Shouldn't we set exePath to the same value as This->sPath ? Christian Aric Stewart wrote: > It is possible under windows to create a .Lnk file to an exe file > before it exists. Office 2000 does this, Scientific Word does this as > do other apps as well. > > So a quick fix so that in IPersistFile_Save if the exe file is not > found, trust the path we are given and allow creation of the link. > > ------------------------------------------------------------------------ > > Index: dlls/shell32/shelllink.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/shelllink.c,v > retrieving revision 1.70 > diff -u -w -r1.70 shelllink.c > --- dlls/shell32/shelllink.c 12 Aug 2004 23:00:53 -0000 1.70 > +++ dlls/shell32/shelllink.c 20 Aug 2004 13:27:38 -0000 > @@ -683,9 +683,14 @@ > /* if there's no PIDL, generate one */ > if( ! This->pPidl ) > { > + /* + * windows can create lnk files to executables > that do not exist yet > + * so if the executable does not exist the just trust the > path they > + * gave us > + */ > if( !*exePath ) > - return E_FAIL; > - > + This->pPidl = ILCreateFromPathW(This->sPath); > + else > This->pPidl = ILCreateFromPathW(exePath); > } > > >

Aug. 20, 2004

Re: Optimize Critical Section Functions

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.com> writes: > Andreas Mohr wrote: >> Umm, this should go into a global header file, right? >> The theory being that it would be useful at many more performance critical >> Wine places... >> But I have to admit that I don't know which header file this should >> be... > Like in the Linux kernel (where this seems to come from) in compiler.h > or something like that. No, I don't think we want to do that, it would only encourage people to sprinkle this stuff all over the place believing they are "optimizing" the code. This should only be added in places where it makes a significant difference, demonstrated with benchmark results. -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2004

Document an API difference

by Shachar Shemesh

Hi list, I'm documenting a probable API result difference between Wine and Windows. At the moment, this is no longer a problem as far as I'm concerned, so there is no point for me to write regression tests and fix it, but this may be stopping someone else. It seems that if you call "select" with a FD set that holds the same file descriptor more than once, Wine's and Window's responses are different. Under windows, you get a statement saying that only one FD is active. Under Wine, you get as many as the number of times the repeating FD is in the set. Like I said, this does not affect, as far as I know, any program, so I'm not sure we need to fix it. I just wanted the list's archive to have a mention of this issue. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 20, 2004

Re: Re: make CryptSetProviderEx update the provider Name and TypeName to registry

by James Hawkins

I'm working on a test app that I hope wil shine some light on how windows gets the Name and TypeName values back in the registry after they've been deleted. The problem is that the only instance of the Name and TypeName data is in the DllRegisterServer function of the provider dll. I couldn't think of any other way to get to that data to get it in the registry, but I will be testing this in windows. What im thinking is that windows might not even delete the key at all. If you have any suggestions it would help a lot. On Fri, 20 Aug 2004 12:48:07 -0700, Alexandre Julliard <julliard(a)winehq.org> wrote: > James Hawkins <truiken(a)gmail.com> writes: > > >> Changelog > >> * Call provider.dll's DllRegisterServer from CryptSetProviderEx to > >> update the Name and TypeName values in the registry properly when > >> setting the default provider > > It doesn't seem right to call DllRegisterServer from there, IMO it > should only be called when the dll is installed. Do you have evidence > that Windows does it this way? > > -- > Alexandre Julliard > julliard(a)winehq.org > -- James Hawkins

Aug. 20, 2004

Re: make CryptSetProviderEx update the provider Name and TypeName to registry

by Alexandre Julliard

James Hawkins <truiken(a)gmail.com> writes: >> Changelog >> * Call provider.dll's DllRegisterServer from CryptSetProviderEx to >> update the Name and TypeName values in the registry properly when >> setting the default provider It doesn't seem right to call DllRegisterServer from there, IMO it should only be called when the dll is installed. Do you have evidence that Windows does it this way? -- Alexandre Julliard julliard(a)winehq.org

Aug. 20, 2004