November 2003 - Wine-Devel - list.winehq.org

Re: Resolution switches in full screen mode

by Lionel Ulmer

> There are 2 ways to do it: > 1. Call SYSMETRICS_Set from x11drv when the resolution changes and update > the values of SM_CXSCREEN, SM_CYSCREEN etc. > Disadvantage: probably breaks DLL separation. I think something like that is in the work as parts of Alex' rework of the Desktop mode with the introduction of the winedesktop application. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Nov. 30, 2003

Re: FontDlg sample text

by Shachar Shemesh

Dmitry Timoshkov wrote: >"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote: > > > >>The main reason is that they are loaded based on encoding, rather than >>language. This has several implications that caused me not to go that route: >>1. The mapping between encoding and charcter encoding is not a >>straightforward one. The reverse mapping is even less so. >> >> > >Well, GetTextCharset() does exactly what you want. > > > I seem to have been totally misunderstood, possibly because of the wrong use of "locale" instead of "charset" in my previous mail. The situation is this: We have a font. This font supports several charsets. (Almost) each charset is used by several locales, but that is besides the point. We need to know which characters to use as a sample text demonstrating each charset. We need some kind of a table. This table does not depend on the current locale. You suggest resource. I say that this seems like the wrong tool for the job, as the resource information seems based on locale, and the locale does not play a role here. Maybe I misunderstood what you meant. Please explain: 1. What kind of a resource should I use, in your opinion? 2. How should I select which resource to load, given a specific locale? 3. What is the advantage of this mechanism? >>These two mean that placing the sample text in a resource will only >>server to confuse the issue. The first point is even harder - what if >>you want different sample text for Chinese BIG-5 and the other Chinese >>encoding? Which language should I try to load for centeral Europe? >>French? German? I can only load one. >> >> > >Exactly. GetTextCharset() is your friend here. Just have different >strings for different charsets in the resources and load them at >appropriate time. > > > You lost me there. How does GetTextCharset help me, in any way? I'll just remind you that thing I have given is the charset, and what I'm searching for is the text. >>In short, doing that through resources seems like an unnecessary >>complication to me. Add to that the fact that you still need the mapping >>table, and you get "ain't worth the hassle". >> >> > >I hope you will reconsider. > > I'll be happy to. Just let's try and understand the implications. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...

Nov. 30, 2003

Re: FontDlg sample text

by Shachar Shemesh

Alexandre Julliard wrote: >Shachar Shemesh <wine-devel(a)shemesh.biz> writes: > > >>Likewise, the Japanese sample text only has Aa (and not AaBb) of >>Romanji (latin characters). For similar reasons, I left AaBb in place >>(why remove it?). >> >> >The question should be why do we go to the trouble of having parts of >the string handled in two different places, when we could simply store >the full string in the sample text array. It would make the code >simpler, more flexible, and more compatible. Is there a good reason >for doing it the way it is now? > > The reason is the unicode version of the dialog. In Unicode, you may need to display several "character sets" simultaniously. When that happens, you don't want to repeat the AaBb string over and over. As for the strings themselves - they are 100% language independant, as far as I can tell. After all, they don't spell a word in any language that I actually speak (Arabic may be an exception here, as may Japanese). Even when they, do, it's a word in that language. I failed to understand how you wanted to make it into a resource. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...

Nov. 30, 2003

Re: FontDlg sample text

by Rein Klazes

On Sun, 30 Nov 2003 11:45:55 -0800, you wrote: > Shachar Shemesh <wine-devel(a)shemesh.biz> writes: > > > Likewise, the Japanese sample text only has Aa (and not AaBb) of > > Romanji (latin characters). For similar reasons, I left AaBb in place > > (why remove it?). > > The question should be why do we go to the trouble of having parts of > the string handled in two different places, when we could simply store > the full string in the sample text array. It would make the code > simpler, more flexible, and more compatible. Is there a good reason > for doing it the way it is now? This is what my patch is doing, I will submit it when I have put a few more sample strings in. And may be Shachar thinks it is not important: symbol files are sometimes scarcely populated, a diffferent sample string may look completely different, for instance not at all. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Nov. 30, 2003

Re: Mmsystem API timeGetTime

by Eric Pouech

Casper Hornstrup wrote: > >>-----Oprindelig meddelelse----- >>Fra: Eric Pouech [mailto:pouech-eric(a)wanadoo.fr] >>Sendt: 30. november 2003 16:39 >>Til: Casper Hornstrup >>Cc: wine-devel(a)winehq.com >>Emne: Re: Mmsystem API timeGetTime >> >>I see two ways of doing it: >>- either use a function pointer to ReleaseThunkLock & >>RestoreThunkLock >>which will be initialized if mmsystem is loaded (as we do for most of >>the 16 bit functions we need) >>- or load by hand these two function with GetProcAddress, and >>handle the >>case where they are not defined. >>I'd vote for the first one. > > > ReleaseThunkLock and RestoreThunkLock need only be called in > mmsystem.dll? How about this patch? not exactly, they need to be called when 16 bit support has been added to winmm, not only when called from 16 bit (we also need it if called from 32 bit with 16 bit support loaded). this patch should take care of it. A+ -- Eric Pouech Name: mm16p2 ChangeLog: - move usage of 16 bit specific functions (MapSL) in 16 bit code only License: X11 GenDate: 2003/11/30 20:04:40 UTC ModifiedFiles: dlls/winmm/winemm.h dlls/winmm/mmsystem.c dlls/winmm/time.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/winemm.h,v retrieving revision 1.48 diff -u -u -r1.48 winemm.h --- dlls/winmm/winemm.h 9 Nov 2003 01:19:58 -0000 1.48 +++ dlls/winmm/winemm.h 30 Nov 2003 20:00:13 -0000 @@ -305,7 +305,7 @@ extern LRESULT (*pFnCallMMDrvFunc16)(DWORD /* in fact FARPROC16 */,WORD,WORD,LONG,LONG,LONG); extern unsigned (*pFnLoadMMDrvFunc16)(LPCSTR,LPWINE_DRIVER, LPWINE_MM_DRIVER); extern LRESULT (*pFnMmioCallback16)(DWORD,LPMMIOINFO,UINT,LPARAM,LPARAM); - +extern void (*pFnYield16)(void); /* GetDriverFlags() returned bits is not documented (nor the call itself) * Here are Wine only definitions of the bits */ Index: dlls/winmm/mmsystem.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/mmsystem.c,v retrieving revision 1.101 diff -u -u -r1.101 mmsystem.c --- dlls/winmm/mmsystem.c 9 Nov 2003 01:19:58 -0000 1.101 +++ dlls/winmm/mmsystem.c 30 Nov 2003 20:01:50 -0000 @@ -53,6 +53,12 @@ static LRESULT DRIVER_SendMessage16(HDRVR16, UINT, LPARAM, LPARAM); static LRESULT MMIO_Callback16(SEGPTR, LPMMIOINFO, UINT, LPARAM, LPARAM); +static void MMSYSTEM_Yield(void) +{ + DWORD count; + ReleaseThunkLock(&count); + RestoreThunkLock(count); +} /* ################################################### * # LIBRARY # @@ -87,6 +93,7 @@ pFnCloseDriver16 = DRIVER_CloseDriver16; pFnSendMessage16 = DRIVER_SendMessage16; pFnMmioCallback16 = MMIO_Callback16; + pFnYield16 = MMSYSTEM_Yield; MMDRV_Init16(); break; case DLL_PROCESS_DETACH: Index: dlls/winmm/time.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/time.c,v retrieving revision 1.22 diff -u -u -r1.22 time.c --- dlls/winmm/time.c 9 Nov 2003 01:19:58 -0000 1.22 +++ dlls/winmm/time.c 30 Nov 2003 20:04:12 -0000 @@ -348,6 +348,8 @@ return 0; } +void (*pFnYield16)(void) /* = NULL */; + /************************************************************************** * timeGetTime [MMSYSTEM.607] * timeGetTime [WINMM.@] @@ -357,9 +359,7 @@ /* FIXME: releasing the win16 lock here is a temporary hack (I hope) * that lets mciavi.drv run correctly */ - DWORD count; - ReleaseThunkLock(&count); - RestoreThunkLock(count); + if (pFnYield16) pFnYield16(); TIME_MMTimeStart(); return WINMM_IData->mmSysTimeMS; }

Nov. 30, 2003

Re: debugger problems

by Mike Hearn

On Sun, 2003-11-30 at 19:51, Rein Klazes wrote: > Still the same here. It can be a bug in Debian Sid of course, and the > with the flow of updates stopped ... FWIW I see the same problem here now on RH9

Nov. 30, 2003

Re: Splitting out shared Win16/Win32 code

by Eric Pouech

> You're right. I should have written MMDRV_PhysicalFeatures. > See attached patch. ooops, I forgot to submit the fix I had for that back to wine... This should be a better fix, whithout code duplication A+ -- Eric Pouech Name: mm16 ChangeLog: - move usage of 16 bit specific functions (MapSL) in 16 bit code only License: X11 GenDate: 2003/11/30 19:56:12 UTC ModifiedFiles: dlls/winmm/lolvldrv.c dlls/winmm/mmsystem.c dlls/winmm/winemm.h dlls/winmm/winmm.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/lolvldrv.c,v retrieving revision 1.53 diff -u -u -r1.53 lolvldrv.c --- dlls/winmm/lolvldrv.c 9 Nov 2003 01:19:58 -0000 1.53 +++ dlls/winmm/lolvldrv.c 9 Nov 2003 10:15:24 -0000 @@ -461,25 +461,19 @@ * MMDRV_PhysicalFeatures [internal] */ UINT MMDRV_PhysicalFeatures(LPWINE_MLD mld, UINT uMsg, DWORD dwParam1, - DWORD dwParam2, BOOL bFrom32) + DWORD dwParam2) { WINE_MM_DRIVER* lpDrv = &MMDrvs[mld->mmdIndex]; - TRACE("(%p, %04x, %08lx, %08lx, %d)\n", mld, uMsg, dwParam1, dwParam2, bFrom32); + TRACE("(%p, %04x, %08lx, %08lx)\n", mld, uMsg, dwParam1, dwParam2); /* all those function calls are undocumented */ switch (uMsg) { case DRV_QUERYDRVENTRY: - if (bFrom32) - lstrcpynA((LPSTR)dwParam1, lpDrv->drvname, LOWORD(dwParam2)); - else - lstrcpynA((LPSTR)MapSL(dwParam1), lpDrv->drvname, LOWORD(dwParam2)); + lstrcpynA((LPSTR)dwParam1, lpDrv->drvname, LOWORD(dwParam2)); break; case DRV_QUERYDEVNODE: - if (bFrom32) - *(LPDWORD)dwParam1 = 0L; /* should be DevNode */ - else - *(DWORD*)MapSL(dwParam1) = 0L; + *(LPDWORD)dwParam1 = 0L; /* should be DevNode */ break; case DRV_QUERYNAME: WARN("NIY QueryName\n"); @@ -496,18 +490,12 @@ case DRVM_MAPPER_PREFERRED_GET: /* FIXME: get from registry someday */ - if (bFrom32) { - *((LPDWORD)dwParam1) = -1; /* No preferred device */ - break; - } - return MMSYSERR_INVALPARAM; + *((LPDWORD)dwParam1) = -1; /* No preferred device */ + break; case DRV_QUERYDEVICEINTERFACE: case DRV_QUERYDEVICEINTERFACESIZE: - if (bFrom32) - return MMDRV_Message(mld, uMsg, dwParam1, dwParam2, TRUE); - - return MMSYSERR_INVALPARAM; + return MMDRV_Message(mld, uMsg, dwParam1, dwParam2, TRUE); case DRV_QUERYDSOUNDIFACE: /* Wine-specific: Retrieve DirectSound interface */ case DRV_QUERYDSOUNDDESC: /* Wine-specific: Retrieve DirectSound driver description*/ Index: dlls/winmm/mmsystem.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/mmsystem.c,v retrieving revision 1.101 diff -u -u -r1.101 mmsystem.c --- dlls/winmm/mmsystem.c 9 Nov 2003 01:19:58 -0000 1.101 +++ dlls/winmm/mmsystem.c 9 Nov 2003 10:15:26 -0000 @@ -1485,7 +1485,9 @@ if ((wmld = MMDRV_Get(HWAVEOUT_32(hWaveOut), MMDRV_WAVEOUT, FALSE)) == NULL) { if ((wmld = MMDRV_Get(HWAVEOUT_32(hWaveOut), MMDRV_WAVEOUT, TRUE)) != NULL) { - return MMDRV_PhysicalFeatures(wmld, uMessage, dwParam1, dwParam2, FALSE); + if (uMessage == DRV_QUERYDRVENTRY || uMessage == DRV_QUERYDEVNODE) + dwParam1 = (DWORD)MapSL(dwParam1); + return MMDRV_PhysicalFeatures(wmld, uMessage, dwParam1, dwParam2); } return MMSYSERR_INVALHANDLE; } @@ -1726,7 +1728,9 @@ if ((wmld = MMDRV_Get(HWAVEIN_32(hWaveIn), MMDRV_WAVEIN, FALSE)) == NULL) { if ((wmld = MMDRV_Get(HWAVEIN_32(hWaveIn), MMDRV_WAVEIN, TRUE)) != NULL) { - return MMDRV_PhysicalFeatures(wmld, uMessage, dwParam1, dwParam2, FALSE); + if (uMessage == DRV_QUERYDRVENTRY || uMessage == DRV_QUERYDEVNODE) + dwParam1 = (DWORD)MapSL(dwParam1); + return MMDRV_PhysicalFeatures(wmld, uMessage, dwParam1, dwParam2); } return MMSYSERR_INVALHANDLE; } Index: dlls/winmm/winemm.h =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/winemm.h,v retrieving revision 1.48 diff -u -u -r1.48 winemm.h --- dlls/winmm/winemm.h 9 Nov 2003 01:19:58 -0000 1.48 +++ dlls/winmm/winemm.h 9 Nov 2003 10:15:27 -0000 @@ -243,7 +243,7 @@ LPWINE_MLD MMDRV_Get(HANDLE hndl, UINT type, BOOL bCanBeID); LPWINE_MLD MMDRV_GetRelated(HANDLE hndl, UINT srcType, BOOL bSrcCanBeID, UINT dstTyped); DWORD MMDRV_Message(LPWINE_MLD mld, WORD wMsg, DWORD dwParam1, DWORD dwParam2, BOOL bFrom32); -UINT MMDRV_PhysicalFeatures(LPWINE_MLD mld, UINT uMsg, DWORD dwParam1, DWORD dwParam2, BOOL bFrom32); +UINT MMDRV_PhysicalFeatures(LPWINE_MLD mld, UINT uMsg, DWORD dwParam1, DWORD dwParam2); BOOL MMDRV_Is32(unsigned int); void MMDRV_InstallMap(unsigned int, MMDRV_MAPFUNC, MMDRV_UNMAPFUNC, MMDRV_MAPFUNC, MMDRV_UNMAPFUNC, LPDRVCALLBACK); Index: dlls/winmm/winmm.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/winmm/winmm.c,v retrieving revision 1.25 diff -u -u -r1.25 winmm.c --- dlls/winmm/winmm.c 26 Nov 2003 03:39:13 -0000 1.25 +++ dlls/winmm/winmm.c 27 Nov 2003 19:32:22 -0000 @@ -1306,7 +1306,7 @@ return 0; } if ((wmld = MMDRV_Get(hMidiOut, MMDRV_MIDIOUT, TRUE)) != NULL) { - return MMDRV_PhysicalFeatures(wmld, uMessage, dwParam1, dwParam2, TRUE); + return MMDRV_PhysicalFeatures(wmld, uMessage, dwParam1, dwParam2); } return MMSYSERR_INVALHANDLE; } @@ -2619,7 +2619,7 @@ if ((wmld = MMDRV_Get(hWaveOut, MMDRV_WAVEOUT, FALSE)) == NULL) { if ((wmld = MMDRV_Get(hWaveOut, MMDRV_WAVEOUT, TRUE)) != NULL) { - return MMDRV_PhysicalFeatures(wmld, uMessage, dwParam1, dwParam2, TRUE); + return MMDRV_PhysicalFeatures(wmld, uMessage, dwParam1, dwParam2); } return MMSYSERR_INVALHANDLE; } @@ -2877,7 +2877,7 @@ if ((wmld = MMDRV_Get(hWaveIn, MMDRV_WAVEIN, FALSE)) == NULL) { if ((wmld = MMDRV_Get(hWaveIn, MMDRV_WAVEIN, TRUE)) != NULL) { - return MMDRV_PhysicalFeatures(wmld, uMessage, dwParam1, dwParam2, TRUE); + return MMDRV_PhysicalFeatures(wmld, uMessage, dwParam1, dwParam2); } return MMSYSERR_INVALHANDLE; }

Nov. 30, 2003

Resolution switches in full screen mode

by Ciprian Enache

My first post! Here we go: To make resolution switches work OK in Wine full-screen apps (mostly games) there are a couple of SYSMETRICS that need to be kept updated (SM_CYSCREEN, SM_CXSCREEN - the vertical and horizontal resolution) There are 2 ways to do it: 1. Call SYSMETRICS_Set from x11drv when the resolution changes and update the values of SM_CXSCREEN, SM_CYSCREEN etc. Disadvantage: probably breaks DLL separation. 2. Add 2 calls to USER_Driver GetWidth and GetHeight (in x11drv) - and dynamically call those when we are asked about SM_CXSCREEN and SM_CYSCREEN. I wrote a patch for this. Any feedback? Sentimente.ro - www.sentimente.ro Peste 50.000 de prieteni te asteapta!

Nov. 30, 2003

Re: debugger problems

by Rein Klazes

On Sun, 30 Nov 2003 12:36:25 -0500, you wrote: > Nope, still doesn't appear to work. Rein, you see the > same? > > Chris > > On Sunday 30 November 2003 11:08 am, Eric Pouech wrote: > > Chris Morgan wrote: > > > Still isn't working with build from todays cvs. Is this patch in there? > > > > it seems that AJ applied it after your mail had been sent > > A+ > Still the same here. It can be a bug in Debian Sid of course, and the with the flow of updates stopped ... Rein. -- Rein Klazes rklazes(a)xs4all.nl

Nov. 30, 2003

Re: FontDlg sample text

by Alexandre Julliard

Shachar Shemesh <wine-devel(a)shemesh.biz> writes: > Likewise, the Japanese sample text only has Aa (and not AaBb) of > Romanji (latin characters). For similar reasons, I left AaBb in place > (why remove it?). The question should be why do we go to the trouble of having parts of the string handled in two different places, when we could simply store the full string in the sample text array. It would make the code simpler, more flexible, and more compatible. Is there a good reason for doing it the way it is now? -- Alexandre Julliard julliard(a)winehq.com

Nov. 30, 2003