On Sun, 29 Aug 2004 13:26:37 +0100, Robert Shearman wrote:
> Use the attached patch and run with warn+module.
>
> Rob
There's no need, I debugged this in January. The problem is that the IE
installer contains its own copy of advapi32 but it doesn't actually
implement all the functions that ours does. In particular some are
exported but just forward to the CommonUnimpStub function which is a bit
like our code which throws an exception.
Our GDI32 implementation uses one of the registry APIs that is implemented
by our advapi32 implementation, but when IE is loaded the advapi32 inside
the installer package takes precendence with the result that the GDI is
linked to stub code. So things blow up.
The solution is to force advapi32 to builtin so the older native version
is never loaded.
thanks -mike
You should post one patch not four that depend upon each other.
Rule of Thumb:
* After each patch is applied, the CVS should build and work.
Mike
James Hawkins wrote:
> Changelog
> * cleanup cross calls in DirectDrawEnumerateEx
>
I want to send this through wine-devel first to see if there are any
problems with it. In gdi_private.h I had to change the parameters
that pStartDoc accepted from DOCINFOA to DOCINFOW. I know I shouldn't
change public api headers, but this one is private so the change seems
acceptable. If it's not let me know. Another problem that might
popup is the way the DOCINFOW struct is filled in the StartDocA
function:
len = MultiByteToWideChar( CP_ACP, 0, doc->lpszDocName, -1, NULL, 0 );
docName = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) );
MultiByteToWideChar( CP_ACP, 0, doc->lpszDocName, -1, docName, len );
docW.lpszDocName = docName; <--- is this assignment a problem?
if(docName)
HeapFree( GetProcessHeap(), 0, (LPWSTR)docName );
The reason why I had to make a docName variable is because
docW.lpszDocName is a LPCWSTR so there were warnings when i had
docW.lpszDocName directly in the call to MultiByteToWideChar.
Changelog
* cleanup w->a cross calls in StartDoc
--
James Hawkins
Hi,
We are currently porting Wine to Mac OS X. Currently Wine has a display
driver for X11, and we would like to continue to use it for the Mac OS
X port: to display the GUI interface, we don't need the Aqua UI
elements since we prefer to use Windows theming system, and given the
complexity and amount of work done in x11drv . But we also would like
to be able to build something that behaves like a normal Carbon or
Cocoa App, with a Dock Icon, and a Menu Bar, which would be managed by
some Carbon code in Wine itself.
I had a look to the X11CallCarbonAndCocoa [1] sample code, but the
trouble is that the X11 window still belongs to X11.app, a mouse click
in the Dock to get the App's Windows to the front doesn't work for the
X11 Window, and the menu bar for this Window is still the X11.app's
menu bar. So I'd like to know if there is a way for the Wine Carbon
instance to own the X11 Windows Wine created. At least it would be a
feature that we'd like to see :)
Thanks,
Pierre.
PS: I am not subscribed to the x11-users so please CC me. I am also
CC-ing the wine-devel and darwine-devel, sorry about that.
[1]
http://developer.apple.com/samplecode/X11CallCarbonAndCocoa/
X11CallCarbonAndCocoa.html
James wrote:
> The unknown class is one of the two control classes
> left to be implemented in commctrl:
> ICC_STANDARD_CLASSES. I would like to implement
> this class, but I have no idea where to start.
It doesn't look like you'd need to do anything special
for the ICC_STANDARD_CLASSES case. The standard
controls are all registered when user32 loads (see the
call to CLASS_RegisterBuiltinClasses in user32's
user_main.c). Comctl32 already imports user32, so
ICC_STANDARD_CLASSES ought to be able to be added to
the /* dummy initialization */ section of
InitCommonControlsEx.
While you're at it, the comment appears to be
incorrect. It says ICC_LINK_CLASS is unimplemented,
but in fact it is in the case statement below. The
comment at the top of the file is similarly out of
date.
At least, that's what I get by reading it. YMMV. Try
patching and seeing how kazaa lite does :)
--Juan
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
Vincent Beron wrote:
>I attach the smatch script to generate the results I have. It's still
>not perfect (the listview.c references are wrong, for example), but as
>it's tied to gcc it can detect some calls which otherwise would not be
>caught. For example, the calls to GetWindowLongA in header.c are in a
>macro.
>
>Not all of them are bugs: caution is needed when checking, although
>reducing the number of false positive would likely be welcome (either by
>modifying the script or patches).
I see many "xxxAW calls xxxA function" mainly in the shell related DLLs. This
is of course not something you can really get rid of, so the script should
be able to exclude those cases.
Rolf Kalbermatter
On Sat, Aug 28, 2004 at 12:17:27PM -0400, James Hawkins wrote:
> Changelog
> * change szDriver and szDescription from char to WCHAR in
> DDDEVICEIDENTIFIER and DDDEVICEIDENTIFIER2.
Well, this seems completely wrong to me. Why Unicodify an API that has no
Unicode equivalent in Microsoft code ?
If I look at the platform SDK, this structure is defined with a 'char', so I
wonder why you would choose to deviate from the standard ?
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
On Sat, Aug 28, 2004 at 12:20:24PM -0400, James Hawkins wrote:
> Changelog
> * cleanup cross calls in DirectDrawEnumerateEx
To continue with my other mail, you should have sent all this in one big
patch as (from what I can see) it cannot work if you do not apply all 4
parts in one go.
Anyway, the 'problem' in Wine is that it uses the DDDEVICEIDENTIFIER2
structure to hold driver information. But, as this information is also
exported via API calls like the 'GetDeviceIdentifier' method from the DDraw
COM object, you cannot just Unicodify it, you need to let it in ASCII (as
there are no, AFAIK, Unicode versions of any of the DirectX < 8 APIs).
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
Hi all,
Attached is a sample program, originally written to find out about the
impact of using epoll on performance.
However, the program doesn't run properly. When running it, I get
deadlocked.
Does anyone have any explanation? Is it a bug in my Win32 code?
> err:ntdll:RtlpWaitForCriticalSection section 0x4017fec0 "?" wait timed
> out in thread 0009, blocked by 0000, retrying (60 sec)
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
http://www.lingnu.com/
James Hawkins <truiken(a)gmail.com> writes:
> Changelog
> * make CryptSetProviderEx only delete the 'Name' value and not
> delete the entire 'Type XXX' key when deleting the default provider.
You are still leaking keys, and it doesn't even build (CryptCloseKey
is not a valid function). Please take your time, look over the code
carefully, fix all the leaks, then build and test it before
resubmitting. There's no hurry, you don't need to send a new patch
within 10 minutes of getting my mail <g>
--
Alexandre Julliard
julliard(a)winehq.org