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?
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
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
* 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. :)
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
* 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?
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
* 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.
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
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.
-
Lionel Ulmer -
Rob D -
Robert Shearman -
Saulius Krasuckas -
Vincent Béron