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