On Thursday 30 September 2004 23:35, Rolf Kalbermatter wrote:
I don't think this will work properly. The returned pointer from CRYPT_LMHash()
will never be passed out to the caller of the function. There should be
probably a function call before the return of the function along the lines
Ah
On Fri, 1 Oct 2004, Dmitry Timoshkov wrote:
Francois Gouget [EMAIL PROTECTED] wrote:
COBJMACROS is very C unfriendly as it requires the caller to define it
if it wants to use COM objects. The following check is much better as
it does the right thing automagically:
#if !defined
Hi:
Recently I've been having troubles with the GetVarDesc function. It's
supposed to return the description
of a COM server's property(given the property index), but instead, it
returns the description of one of the methods
of the COM server.
I've realized that the varlist list of the ITypeInfo
Francois Gouget [EMAIL PROTECTED] wrote:
But that change makes Wine code not compilable with SDK and Mingw headers,
I don't think it's an acceptable change.
Do you mean this change in particular (i.e. not using COBJMACROS for
protecting internal Wine structures) or the COBJMACROS change
On Fri, 1 Oct 2004, Dmitry Timoshkov wrote:
[...]
Why would it break compilation with the SDK and Mingw headers?
I wrongly formulated the problem: it will Wine internal COM interfaces
not follow the standard practice, be contradict and confuse the Wine code.
That's the thing, the standard
Jon Griffiths wrote:
I have to write a spec file so that a winelib application can use a third
party dll. The problem is that APIs in third party dll are written in C++.
As c++ names and parameters are mangled, how can i call them in spec file?
how can I call a class constructor (which is built
Hi,
how can I call a class constructor (which is built form
another class) in spec file? Can anyone provide me an example?
This is possible, although it is not immediately obvious. Here is the
solution I use (I will document this one day but I'm very busy ATM):
Scenario 1: App uses C++ dll,
On Fri, Oct 01, 2004 at 07:58:23AM -0700, Jon Griffiths wrote:
Hi,
A fairly large update to the tab control. This makes it work as per
native in my app.
Nice. While you're at it (and have it fresh in your mind), can you
please also provide an audit (and a list of TODOs) as per comctl 6.0?
Jon Griffiths wrote:
Hi,
A fairly large update to the tab control. This makes it work as per
native in my app.
Regards,
Jon
+dlls/comctl32/tab.c dlls/comctl32/tests/tab.c
Items can be variable sized; use an accessor to retrieve them
Send WM_NOTIFYFORMAT/WM_QUERYUISTATE to match native
Hi,
I think the original poster wanted to use a closed-source
third-party DLL
written in C++ and compiled with MSVC. AFAIK none of your
suggestions address that case.
If source for the dll isn't available then the only option i can
think of is as follows:
WARNING: Untested, but should
Jon Griffiths wrote:
Hi,
There is no point in sending WM_QUERYUISTATE. I believe it is only
really used for the toolbar control, but the native comctl32 has a
common framework that means it is sent for all controls.
Sure, it helps when diffing the traces of native and builtin though.
By
Hi,
There is no point in sending WM_QUERYUISTATE. I believe it is only
really used for the toolbar control, but the native comctl32 has a
common framework that means it is sent for all controls.
Sure, it helps when diffing the traces of native and builtin though.
By sending this and
Hi,
Nice. While you're at it (and have it fresh in your mind), can you
please also provide an audit (and a list of TODOs) as per comctl
6.0?
It will be a while afraid, I'm really busy with work ATM. My first
priorities when i get some free time are to finish clearing my patch
tree for
Are all SPI values in windows/sysparams.c,SystemInformationW() stored in the
registry somewhere?
If yes, is there a not to difficult way to find which registry key it is for a
given SPI value?
I have a few win boxes available to find this out.
Ivan.
If you want to get a glimpse at what a proxy driver should be, look
inside dlls/winmm/wavemap
Ok, thanks Eric. I'll take a look at what we have and see if I can
come up with something useful.
On Fri, 01 Oct 2004 21:29:44 +0200, Eric Pouech [EMAIL PROTECTED] wrote:
I remember working on this
I want to make sure I'm getting the right idea. So I would implement
a new audio driver like winealsa, wineoss etc but named something like
wineautodetect. This driver is actually a proxy that checks each of
the available drivers to see if they are available, and if so,
initialize that driver
Hi.
I got this communicat:
fixme:ntdll:TIME_GetTZAsStr Can't match system time zone name UTC to
an entry in TZ_INFO
fixme:ntdll:TIME_GetTZAsStr Please add appropriate entry to TZ_INFO and
submit as patch to wine-patches
so I wanted to send patch, but UTC is time convencion, not Local Time
James Hawkins a écrit :
I want to make sure I'm getting the right idea. So I would implement
a new audio driver like winealsa, wineoss etc but named something like
wineautodetect.
yes (I'd rather put a ref to sound or MM in the driver name)
This driver is actually a proxy that checks each of
they are more than that. they also implement wave in, midi, mixer type
of interface... You need to proxy all of that.
Ok, well I think I have enough information to start churning out this
driver. Does the name winemmautodetect work?
On Fri, 01 Oct 2004 23:24:13 +0200, Eric Pouech [EMAIL
I stopped concentrating for quite a few months and now the whole config system
has changed.!! Any chance of some help?
When we released the previous version of our product on Linux we included a
couple of perl scripts etc. for setting up the Wine suitably, including
adding a couple of drives,
20 matches
Mail list logo
