DirectDrawEnumerateExW calls DirectDrawEnumerateExA

[Saulius Krasuckas]

DirectDrawEnumerateExW (dlls/ddraw/main.c) calls 
DirectDrawEnumerateExA, which uses 
ddraw_driver struct (dlls/ddraw/ddraw_private.h), which has a member
DDDEVICEIDENTIFIER2 struct (include/ddraw.h), which is defined this way:

typedef struct tagDDDEVICEIDENTIFIER2 {
    char    szDriver[MAX_DDDEVICEID_STRING];
    char    szDescription[MAX_DDDEVICEID_STRING];
    LARGE_INTEGER  liDriverVersion;
    DWORD   dwVendorId;
    DWORD   dwDeviceId;
    DWORD   dwSubSysId;
    DWORD   dwRevision;
    GUID    guidDeviceIdentifier;
    DWORD   dwWHQLLevel;
} DDDEVICEIDENTIFIER2, * LPDDDEVICEIDENTIFIER2;

As this struct keeps base information about a driver and it uses char 
strings, I guess %Subject% cross call should be marked invalid in the 
wiki.  Right?

[Lionel Ulmer]

On Wed, Oct 26, 2005 at 10:03:36PM +0300, Saulius Krasuckas wrote:
> As this struct keeps base information about a driver and it uses char 
> strings, I guess %Subject% cross call should be marked invalid in the 
> wiki.  Right?

Well, we could move the DDraw code to Unicode and do the opposite (have the
A function call the W one). But as the only strings we report to the
application are in English anyway and are not planned to be localized
anytime soon, it's a bit overkill to do this work for no gain at all.

If one day someone wants to have the DirectX driver name reported in
Chinese, let him to the work of unicodification of DDraw :-)

        Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

[Vincent Béron]

Le mer 26/10/2005 à 16:26, Lionel Ulmer a écrit :
> On Wed, Oct 26, 2005 at 10:03:36PM +0300, Saulius Krasuckas wrote:
> > As this struct keeps base information about a driver and it uses char 
> > strings, I guess %Subject% cross call should be marked invalid in the 
> > wiki.  Right?
>
> Well, we could move the DDraw code to Unicode and do the opposite (have the
> A function call the W one). But as the only strings we report to the
> application are in English anyway and are not planned to be localized
> anytime soon, it's a bit overkill to do this work for no gain at all.
>
> If one day someone wants to have the DirectX driver name reported in
> Chinese, let him to the work of unicodification of DDraw :-)

I started work on this already (but only to get rid of the corresponding
item in the output of winapi_check). I don't know when it'll be ready
for submission (I have a couple others to resubmit as well).

Maintaining a list of "invalid" finds by winapi_check is a PITA as if
don't have access to said list, you'll have to check some items which
are already determined as "don't worry". It's much better to fix the
offending code, or in some specific cases winapi_check itself (like some
HAVE_ macros which are not in config.h), or if a check doesn't make any
sense.

Vincent

[Saulius Krasuckas]

* On Thu, 26 Oct 2005, Vincent [ISO-8859-1] B�ron wrote:
> * Le mer 26/10/2005 � 16:26, Lionel Ulmer a �crit :
> > * On Wed, Oct 26, 2005 at 10:03:36PM +0300, Saulius Krasuckas wrote:
> > > As this struct keeps base information about a driver and it uses 
> > > char strings, I guess %Subject% cross call should be marked invalid 
> > > in the wiki.  Right?
> >
> > Well, we could move the DDraw code to Unicode and do the opposite 
> > (have the A function call the W one). But as the only strings we 
> > report to the application are in English anyway and are not planned to 
> > be localized anytime soon, it's a bit overkill to do this work for no 
> > gain at all.
>
> I started work on this already (but only to get rid of the corresponding 
> item in the output of winapi_check).

What exact changes do you mean? (I just may don't understand some 
sentences in english by a first look)
> I don't know when it'll be ready for submission (I have a couple others 
> to resubmit as well).

Can you, please, mention them.  If you are gonna finish all of them, then 
OK, tell me and I'll drop my idea of doing the same. :)

[Vincent Béron]

Le jeu 27/10/2005 à 02:32, Saulius Krasuckas a écrit :
> * On Thu, 26 Oct 2005, Vincent [ISO-8859-1] Béron wrote:
> > * Le mer 26/10/2005 à 16:26, Lionel Ulmer a écrit :
> > > * On Wed, Oct 26, 2005 at 10:03:36PM +0300, Saulius Krasuckas wrote:
> > > > As this struct keeps base information about a driver and it uses 
> > > > char strings, I guess %Subject% cross call should be marked invalid 
> > > > in the wiki.  Right?
> > >
> > > Well, we could move the DDraw code to Unicode and do the opposite 
> > > (have the A function call the W one). But as the only strings we 
> > > report to the application are in English anyway and are not planned to 
> > > be localized anytime soon, it's a bit overkill to do this work for no 
> > > gain at all.
> >
> > I started work on this already (but only to get rid of the corresponding 
> > item in the output of winapi_check).
>
> What exact changes do you mean? (I just may don't understand some 
> sentences in english by a first look)

dlls/hhctrl.ocx/hhctrl.c has a call to MessageBoxA from HtmlHelpW.

dlls/shell32/systray.c has a call to Shell_NotifyIconA from
Shell_NotifyIconW.

dlls/version/install.c has a call to VerInstallFileA from
VerInstallFileW.

dlls/wininet/internet.c has a call to InternetCheckConnectionA from
InternetCheckConnectionW.

dlls/winsock/socket.c has a call to WSAStringToAddressA from
WSAStringToAddresW.

I have patches for the above, which I need to resubmit. The hhctrl one
is supposed to be replaced by properly launching our help engine.

I also started work on the dlls/ddraw/main.c call to
DirectDrawEnumerateExA from DirectDrawEnumerateExW.
> > I don't know when it'll be ready for submission (I have a couple others 
> > to resubmit as well).
>
> Can you, please, mention them.  If you are gonna finish all of them, then 
> OK, tell me and I'll drop my idea of doing the same. :)

See above. There are a couple ones in winspool which I haven't check and
don't plan to (I don't have a printer to verify).

Vincent

[Saulius Krasuckas]

* On Wed, 26 Oct 2005, Lionel Ulmer wrote:
> * On Wed, Oct 26, 2005 at 10:03:36PM +0300, Saulius Krasuckas wrote:
> > As this struct keeps base information about a driver and it uses char 
> > strings, I guess %Subject% cross call should be marked invalid in the 
> > wiki.  Right?
>
> If one day someone wants to have the DirectX driver name reported in 
> Chinese, let him to the work of unicodification of DDraw :-)

You mean, if some day M$ changes ddraw.h so that szDescription type 
becomes WCHAR, right?

[Lionel Ulmer]

> You mean, if some day M$ changes ddraw.h so that szDescription type 
> becomes WCHAR, right?

Well, the API is like this:

HRESULT WINAPI DirectDrawEnumerateExW( LPDDENUMCALLBACKEXW lpCallback, LPVOID lpContext, DWORD dwFlags);

With:

typedef BOOL (CALLBACK *LPDDENUMCALLBACKEXW)(GUID *, LPWSTR, LPWSTR, LPVOID, HMONITOR);

The question now is wether it is guaranteed to have the string returned by
'DirectDrawEnumerateExW' be the same than the one returned by
'DDRAW->GetDeviceIdentifier()'.

       Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/

[Saulius Krasuckas]

* On Thu, 27 Oct 2005, Lionel Ulmer wrote:
> > You mean, if some day M$ changes ddraw.h so that szDescription type 
> > becomes WCHAR, right?
>
> Well, the API is like this:
> HRESULT WINAPI DirectDrawEnumerateExW( LPDDENUMCALLBACKEXW lpCallback, LPVOID lpContext, DWORD dwFlags);
>
> With:
> typedef BOOL (CALLBACK *LPDDENUMCALLBACKEXW)(GUID *, LPWSTR, LPWSTR, LPVOID, HMONITOR);

But this doesn't say anything about a type of a string, based on which 
dll/ddraw code works (or should work).
> The question now is wether it is guaranteed to have the string returned 
> by 'DirectDrawEnumerateExW' be the same than the one returned by 
> 'DDRAW->GetDeviceIdentifier()'.

Here I probably stopped following you.  GetDeviceIdentifier() fills a 
struct named DDDEVICEIDENTIFIER2:

| typedef struct tagDDDEVICEIDENTIFIER2 {
|   char    szDriver[MAX_DDDEVICEID_STRING];      /* user readable driver name */
|   char    szDescription[MAX_DDDEVICEID_STRING]; /* user readable description */
|   LARGE_INTEGER  liDriverVersion;               /* driver version */

This way strings cannot be the same, as one is widechar (passed as LPWSTR 
to DDENUMCALLBACKEXW) while another is multibyte (defined as char in 
DDDEVICEIDENTIFIER2).  I guess DX SDK headers may not be wrong here.

WM_SIZING

[Rob D]

I Finally got Wine working on Solaris 9 and tweaked the Makefiles to get my 
250k lines of code app to compile on Winelib!!
Of course it crashes immediately and core dumps but that is (apparently 
known) issue that I will investigate later.

Due to the extensive amount of time it took to get 3 monitors and Wine 
working on Solaris 9, I am just running the Win32 executable with Wine.

I found a few really weird things in Wine that differ from Windows. Running 
on Wine exposed a bug in my code that was calling a function in a member 
class of a class that had a NULL pointer.
foo->bar->doStuff ran just fine in windows when foo == 0. The windows 
debugger stepped into the function, through it, and worked fine. Really 
bizarre?!?!?!?

There were a couple other things that were slightly different on Wine than 
Windows, and were easily fixed or reworked. The only thing that is not 
easily work-around-able, is that it seems that there are no WM_SIZING 
messages sent when running on Wine. WM_SIZE messages are sent just fine, 
but not a single WM_SIZING, ever. This is a major problem.

Is this a known issue or something that needs extra setup to work?

The only other major issue that I have is the creation of dialogs on a 
specific monitor in a 3 monitor (has to be non Xinerama) setup. I dont 
think this is a Wine specific issue, but since it has to do with setting of 
$DISPLAY before creating the dialog, it is further complicated from running 
in Wine.

Fun fun
Rob Done

WM_SIZING

[Robert Shearman]

Rob D wrote:
> There were a couple other things that were slightly different on Wine 
> than Windows, and were easily fixed or reworked. The only thing that 
> is not easily work-around-able, is that it seems that there are no 
> WM_SIZING messages sent when running on Wine. WM_SIZE messages are 
> sent just fine, but not a single WM_SIZING, ever. This is a major 
> problem.
>
> Is this a known issue or something that needs extra setup to work?

Unfortunately, it is one of the features that we can't implement 
properly because of differences with the X11 protocol as opposed to 
Windows. Window managers don't notify windows when a user resizes it by 
dragging the window borders, so we can't send an appropriate message. I 
bet your app will get the messages, however, when running in desktop mode.

-- 
Rob Shearman