September 2006 - Wine-Devel

Re: clusapi: [RESEND] Implements stub dll for clusapi

by Benjamin Arai

When I was creating the stub I looked around in several dll's and some of the them export DllMain. ./advpack/advpack.spec:@ stdcall -private DllMain(long long ptr) ./dciman32/dciman32.spec:@ stdcall -private DllEntryPoint(long long ptr) DllMain ./itss/itss.spec:@ stdcall -private DllMain(long long ptr) ./msimg32/msimg32.spec:@ stdcall -private DllInitialize(long long ptr) DllMain Then in what case do you need to export? Benjamin On 9/28/06, Robert Shearman <rob(a)codeweavers.com> wrote: > Benjamin Arai wrote: > > +@ stdcall -private DllMain(long long ptr) > > > > There's no need to export DllMain. > > -- > Rob Shearman > > -- Benjamin Arai http://www.benjaminarai.com

Sept. 28, 2006

Yesterday's (6/28) Git (gdi32) updates break 64-bit compilation.

by Evil Jay

The updates in yesterday's Git tree have broken compilation under 64-bit. Previously, it was working. I entered a bugzilla entry for it (http://bugs.winehq.org/show_bug.cgi?id=6304) but thought I would mention it here too - since I think it's a pretty big deal and it doesn't seem that many of the developers here are working under 64-bit (and therefore wouldn't notice the issue). ------------------------ ../../tools/winegcc/winegcc -B../../tools/winebuild -shared ./gdi32.spec dispdib.spec.o gdi.exe.spec.o wing.spec.o bidi16.o dispdib.o env.o gdi16.o metafile16.o wing.o bidi.o bitblt.o bitmap.o brush.o clipping.o dc.o dib.o driver.o enhmetafile.o enhmfdrv/bitblt.o enhmfdrv/dc.o enhmfdrv/graphics.o enhmfdrv/init.o enhmfdrv/mapping.o enhmfdrv/objects.o font.o freetype.o gdi_main.o gdiobj.o icm.o mapping.o metafile.o mfdrv/bitblt.o mfdrv/dc.o mfdrv/graphics.o mfdrv/init.o mfdrv/mapping.o mfdrv/objects.o mfdrv/text.o painting.o palette.o path.o pen.o printdrv.o region.o version.res -o gdi32.dll.so -ladvapi32 -lkernel32 -lntdll /usr/lib/libsicuuc.a /usr/lib/libsicudata.a -lstdc++ -lgcc_s ../../libs/port/libwine_port.a -L/lib32 -L/usr/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32 ld: Relocatable linking with relocations from format elf64-x86-64 (/usr/lib/libsicuuc.a(ubidi.ao)) to format elf32-i386 (gdi32.n0hnjc.o) is not supported winebuild: ld -m elf_i386 -r failed with status 256 winegcc: ../../tools/winebuild/winebuild failed. make[2]: *** [gdi32.dll.so] Error 2 make[2]: Leaving directory `/data/install/wine/dlls/gdi' make[1]: *** [gdi] Error 2 make[1]: Leaving directory `/data/install/wine/dlls' make: *** [dlls] Error 2 -J

Sept. 28, 2006

RE: Can't open DLL's without sudo

by Paul Wilkinson

What's the point of giving new people attitude? Of course I read the error messages. Are you okay? -----Original Message----- From: Vitaliy Margolen [mailto:wine-devel(a)kievinfo.com] Sent: Thursday, September 28, 2006 5:47 AM To: Paul Wilkinson Cc: wine-devel(a)winehq.org Subject: Re: Can't open DLL's without sudo This e-mail belongs in wine-user not here. Please read error messages yourself first. Vitaliy Paul Wilkinson wrote: > I'm running wine v 0.9.20 under Fedora Core 5. > > > > I'm trying to get the Syncrosoft License Control Center to run under > wine. for some reason it can only load MFC42.DLL and MSVCRT.DLL if I > put 'sudo' on the command line: > > > > [paul(a)localhost LCC]$ wine LCC.exe > err:module:import_dll Library MFC42.DLL (which is needed by > L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found > err:module:import_dll Library MSVCRT.dll (which is needed by > L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found > err:module:import_dll Library MSVCRT.dll (which is needed by > L"C:\\windows\\system32\\MSVCP60.dll") not found > err:module:import_dll Library MSVCP60.dll (which is needed by > L"C:\\Program Files\\Syncrosoft\\LCC\\LCC.exe") not found > err:module:LdrInitializeThunk Main exe initialization for L"C:\\Program > Files\\Syncrosoft\\LCC\\LCC.exe" failed, status c0000135 > [paul(a)localhost LCC]$ > > > > The NtOpenFile that tries to open the DLL (in loader.c) is returning > c00000022 (ACCESS_DENIED). But the permissions for these DLL's are wide > open. > > > > Any idea what's going on? > > > > - Paul > > > > > ------------------------------------------------------------------------ > >

Sept. 28, 2006

Re: Governance Ideas

by Dimi Paun

On Thu, September 28, 2006 9:24 am, Chris Morgan wrote: > I'm of the opinion that code is "art" as its implementation is > subjective. The idea that you could document when a patch is > acceptable or not seems like an impossibility. I wholeheartedly subscribe to this. We are far away (as a profession) to document what is a good/bad patch even when that is fairly obvious to a good maintainer, let alone document exactly the thought process for more complicated cases. This is a waste of time. Alexandre is an amazing judge of patches, we should be happy we have him. More to the point, I think this is missing the point. If we are good at something, it is in evaluating patches on their techincal merit. This doesn't need improvement. What we may be erring a bit is putting the techincal aspects above and beyond other considerations, such as desire for a feature at the expense of a little quality. We are delaying patch inclusion waiting for the 'right' solution, which in part is good, but when that means keeping desired features away for years on end, i think it hurts us more than it helps us being relevant to our users. Maybe there's a way to help Alexandre better understand how much people want something, maybe that can be factored in a bit? -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Sept. 28, 2006

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype (2nd attempt)

by Vitaliy Margolen

Vitaliy Margolen wrote: > Thomas Weidenmueller wrote: >> The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, >> not unsigned int. >> >> - Thomas >> > It's been discussed numerous times, you should avoid use of 'long' in > Wine. On win64 sizeof(long) == 4. On Linux64 sizeof(long) == 8. > I will answer myself: it is declared as 'unsigned long' in SDK. Sorry for the noise. Vitaliy

Sept. 28, 2006

Scrambled VB Fonts improving.

by Joe Baker

Sept. 28, 2006

Re: Anybody have a RegDeleteTree[A|W] implementation lying around?

by Frank Richter

On 28.09.2006 15:26, Paul Vriens wrote: > I'll have a few hours tomorrow and will have a look. The cleanest > solution for now seems to create RegDeleteTree[A|W] in advapi32 and use > that wherever possible (unless we find that it forwards to shlwapi). > Most DLL's already import advapi32. Hmm... isn't advapi32 "lower level" than shlwapi? I'd expect that if forwarding takes place then it'd be shlwapi->advapi32. -f.r.

Sept. 28, 2006

Re: Patchwork (was Re: Governance revisited)

by Jakob Eriksson

Ge van Geldorp wrote: > Actually, that's not how I intended things to work. The automatic removal > from the queue would only happen if the patch had a RFC status, i.e. if > action is expected from the patch submitter. If the patch is unopposed and > just waiting in the queue, it should stay there. > It's reasonable to tell a submitter "you seem to have lost interest in this > patch, it has been waiting on action from you for [a month, whatever] but > nothing has happened, therefore it will be removed from the queue". Sending > a warning message "your patch is going to be dropped without explanation" is > no improvement over the current situation. > Ok, I misunderstood. These things are tricky to comprehend and even harder to discuss. :) // Jakob

Sept. 28, 2006

Re: Anybody have a RegDeleteTree[A|W] implementation lying around?

by Paul Vriens

On Thu, 2006-09-28 at 07:01 -0600, Vitaliy Margolen wrote: > Paul Vriens wrote: > > Hi, > > > > I was browsing some code and found that we have several places where we > > made our own implementation of a recursive delete of registry > > keys/value. > See winecfg. > > Vitaliy. > Do you mean winecfg has it's implementation, or winecfg has the solution? I had another look, apparently shlwapi has SHDeleteKey[A|W]. It does the same thing. I'll have a few hours tomorrow and will have a look. The cleanest solution for now seems to create RegDeleteTree[A|W] in advapi32 and use that wherever possible (unless we find that it forwards to shlwapi). Most DLL's already import advapi32. Cheers, Paul.

Sept. 28, 2006

Re: Governance Ideas

by Chris Morgan

> 2. Alexandre documents the exact logic he uses to determine patch > acceptability which becomes the patch acceptance policy in the interim. This > should be done to the point that someone else could take over from Alexandre > and achieve the same result. This opens the way to multiple maintainers as > well as allowing Alexandre to take more holidays. > I'm of the opinion that code is "art" as its implementation is subjective. The idea that you could document when a patch is acceptable or not seems like an impossibility. You might be able to set a series of ground rules, no c++ comments, shouldn't contain asm unless necessary, but even a patch that fits these requirements isn't necessarily an acceptable patch. I've almost never been unhappy with AJ's judgement except in cases like the safedisc patches where it seemed like no one really knew what was "good" and more effort wasn't put into at least providing development guidance. Chris

Sept. 28, 2006