Looking at shell32.dll I do see that it is the intention to get rid
completely of any link time dependencies to ole32.dll for DLL separation.
There are several late bound dependencies but I guess these are not any
issue as they can not possible cause circular dependencies at load time.
I have identified following direct dependencies from shell32 on ole32.
location resolution
pidl.c
CLSIDFromString change to SHCLSIDFromString
shell32_main.c
CoCreateInstance change to internal late bound __CoCreateInstance
shellole.c
CoCreateInstance change to internal late bound __CoCreateInstance
CLSIDFromString SHCLSIDFromString either link or forward to
SHLWAPI_436 or create late bound CLSIDFromString
shellord.c
CoCreateInstance change to internal late bound __CoCreateInstance
CoUninitialize create late bound CoUninitialize
CoInitialize create late bound CoInitialize
shellstring.c
CoTaskMemFree create late bound CoTaskMemFree
shlfldr_desktop.c
CLSIDFromString change to SHCLSIDFromString
The questions I have is, is it desirable to change those dependencies to late bound calls
to OLE32, as there are already several in shell32.dll to remove any direct load dependency
or does this only create additional problems?
Also the remark in shlwapi.ordinal.c about SHLWAPI_436 that it must recode the function
as the native DLL seems not to import ole32 or vice versa seems a bit strange. What if
native also uses late binding for those functions?
Rolf Kalbermatter
Eric Pouech wrote:
> this patch by Dan Kegel fixes a hang up while finishing playing wave
> files on the OSS driver
Eric's pretty liberal with credit. I just pinpointed the
regression without understanding the code, and he wrote the proper fix.
That was fun, by the way! I enjoyed learning how to
hunt through CVS for what caused a problem to appear,
and it was really gratifying to see an official patch
so quickly as a result.
Is there a list of other known application regressions?
I might want to tackle one more. This seems like a good
way for newbies to contribute.
- Dan
Hi,
I have an app here, which uses locale 407, for which we do not implement
LHashValOfNameSys yet...
It reports:
err:ole:LHashValOfNameSysA No hash for LCID 407, returning '0x00424242', please report
If someone wants to fix it :)
Ciao, Marcus
Before I waste hours on searching through the code can someone answer this?
The way I like to run Wine is to have a single copy of system.reg and
userdef.reg in a central location and then each user has a symbolic link to
them (and the cached metrics) but a true copy of the user.reg. (I know that
this is not going to work if multiple users simultaneously access it).
However the ownership and permissions on the system.reg and userdef.reg change
each time the wineserver runs.
Presumably wine is actually creating new copies and relinking and this is why
the ownership etc. changes. Would it be resonable at least to attempt to
preserve the group permissions if not the whole ownership etc.
--
Bill Medland
> I hoped to hear an improvement but there was no difference
there's only a gain which is less than 0,4%, so I don't think you can
hear it. and btw, some sounds package also do it this way (it's just a
slighly faster than your proposal)
so there's no urge to switch, but not harm either
A+
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
> Here is the problem:
> A. The msvcrt files include other msvcrt files, but they should
> do so *without* explicitly asking for them. That is, they should
> #include "stdio.h"
> instead of:
> #include "msvcrt/stdio.h"
Do we actually need to include other headers from the msvcrt includes?
My Windows headers don't include anything, but they are from an old
VC++ version. Could someone with a newer VC++ check if this is still
the case?
--
Alexandre Julliard
julliard(a)winehq.com
Not that we need winewrap to port a windows apps to linux under mingw so I guess it could just be
removed from the build process.
gcc -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK -Wall -mpreferred-stack-boundary=2
-o mingwrap mingwrap.o
gcc -c -I. -I. -I../include -I../include -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOC
K -Wall -mpreferred-stack-boundary=2 -DNO_LIBWINE -DLEX_OUTPUT_ROOT="\"lex.yy\"
" -DINCLUDEDIR="\"/usr/local/include/wine\"" -D_REENTRANT -o winewrap.o winewrap
.c
winewrap.c:28:22: sys/wait.h: No such file or directory
winewrap.c: In function `spawn':
winewrap.c:122: warning: implicit declaration of function `fork'
winewrap.c:123: warning: implicit declaration of function `wait'
winewrap.c:125: warning: implicit declaration of function `WEXITSTATUS'
winewrap.c: In function `main':
winewrap.c:258: `S_IRGRP' undeclared (first use in this function)
winewrap.c:258: (Each undeclared identifier is reported only once
winewrap.c:258: for each function it appears in.)
winewrap.c:258: `S_IXGRP' undeclared (first use in this function)
winewrap.c:258: `S_IROTH' undeclared (first use in this function)
winewrap.c:258: `S_IXOTH' undeclared (first use in this function)
make[1]: *** [winewrap.o] Error 1
make[1]: Leaving directory `/g/src/wine-dev/wine/tools'
make: *** [tools] Error 2
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Had any users had any unhandled acceptions in oleaut32.dll? Specifically:
Unhandled Acception: unimplemented function oleaut32.dll.VarOr called
in 32 bit code.
Any assistance would be really great!!
Ben
ok I see here my kernel32.spec.def if forwarding the HeapAlloc call to
ntdll and this seems to be hosed. Mabey something with my binutils is
hosed. I will upgrade and try again tonight.
HeapAlloc=ntdll.RtlAllocateHeap @638
HeapCompact@8 @639
HeapCreate@12 @640
HeapDestroy@4 @642
HeapFree=ntdll.RtlFreeHeap @644
HeapLock@4 @645
HeapReAlloc=ntdll.RtlReAllocateHeap @647
HeapSize=ntdll.RtlSizeHeap @649
Thanks
Steven