GetLastError() and Winelib startup
Currently, when Winelib application startup finishes, GetLastError() returns 6, or ERROR_INVALID_HANDLE. Under Windows NT 4, when applications start up, GetLastError() returns 0. Because SetLastError() is used only sporadically throughout the Wine code, it will be very difficult to track down why this error code is being set. Even if it is possible to figure out why, the functions involved may be behaving as documented. An easy way to fix this problem would be to call SetLastError(0) immediately before calling WinMain() of the Winelib application. Is this the correct solution? Trivial patch to implement this follows. Index: spec32.c === RCS file: /home/wine/wine/tools/winebuild/spec32.c,v retrieving revision 1.2 diff -u -r1.2 spec32.c --- spec32.c2000/06/24 13:37:06 1.2 +++ spec32.c2000/08/23 02:49:09 @@ -402,6 +402,7 @@ "if (*cmdline) cmdline++;\n" "GetStartupInfoA( &info );\n" "if (!(info.dwFlags & STARTF_USESHOWWINDOW)) info.wShowWindow = 1;\n" +"SetLastError(0);\n" "ExitProcess( %s( GetModuleHandleA(0), 0, cmdline, info.wShowWindow ) );\n" "}\n\n", init_func, init_func ); fprintf( outfile, -- James Juran [EMAIL PROTECTED]
Re: Code page stuff is broken
Alexandre Julliard <[EMAIL PROTECTED]> wrote: >> 2. Then app displays the text using ExtTextOutA. Here the problems begin. >> Now ExtTextOutA assumes, that ANSI code page and code page of currently >> selected font is the same. It is wrong assumption. As it was many times >> pointed out (at least by me). > >It's not assuming they are the same, it's assuming that the app wants >TextOutA to display the string using the font codepage, which is not >entirely unreasonable (though I agree you can also argue that it >should assume CP_ACP instead). Of course, I can :-). ExtTextOutA at wine/objects/text.c takes non-unicode text and translates it to unicode using wrong code page. That's all. The used code page will be always wrong, if currently selected font will have another code page rather then current ANSI code page. Theoretically, the system could have fonts with three different code pages: ANSI, OEM, MAC. I have even more in addition to the mentioned ones: iso8859-1, iso8859-5, koi8-r, symbol. In my case ANSI = 1251, OEM = 866, MAC = 10007. So, the question: Can the fonts with the different code pages easy break everything?! >Maybe the problem is that we should always try to use the right font >charset for the current codepage unless specified explicitly? Would a >patch like this improve the situation? Unfortunately, the problem persist. Dmitry.
Re: patch to remove sysmenu on toolwindow ...
Francois Methot <[EMAIL PROTECTED]> wrote:
>This patch prevent a system menu from appearing on a docker by filtering the
>Style and ExStyle of a window.
>The system menu won't be displayed if a given window has the following
>style:
>WS_EX_TOOL_WINDOW
>
>However to display it, it requires those:
>WS_SYSMENU &
>WS_CAPTION
>
>I choosed these styles based on test I made with Window.
...
-if (pt.x <= rect.left) return HTSYSMENU;
+if (pt.x < rect.left) {
+if ((wndPtr->dwStyle & WS_CAPTION) && !(wndPtr->dwExStyle &
+WS_EX_TOOLWINDOW))
+return HTSYSMENU;
+else
+return HTCAPTION;
+}
...
in winuser.h WS_CAPTION defined as
#define WS_CAPTION 0x00C0L /* WS_BORDER | WS_DLGFRAME */
so, test "if (wndPtr->dwStyle & WS_CAPTION)" is not correct. Everywhere in Wine
the construction like "if ((wndPtr->dwStyle & WS_CAPTION) == WS_CAPTION)" is widely
used.
Dmitry.
Re: patch for animate.c
Francois Methot <[EMAIL PROTECTED]> wrote: >For the transparency issue, this patch implement a switch-case for the >bitcount (bit per pixel) of the animation files. With this switch different >line of code is executed for getting and setting the transparency color >whenever it's 2, 4, 8, 16, 24 or 32 bpp because different operation is >needed for each of those cases. For now, the switch-case implementation has >been made only for 8, 16, 24 and 32 bpp. Just curious, I have never seen 2 bpp DIBs, only 1 (monochrome), 4 and so on. Dmitry.
Re: Sources of information
On Tue, 22 Aug 2000, Dave Pickles wrote: > On Tue, 22 Aug 2000, you wrote: > > > >Alternatively, there's the Win2k source code, which could be of interest > >if you can get your hands on it :-) > > Hmmm thanks. I was looking for some information on functions exported from > NT's KERNEL.DLL which don't appear in any documentation. For example, > CmdBatNotification(), GetConsoleCommandHistory() and ConsoleSubst(). Well, I don't have the source ATM - have you tried looking at the entry point in the code with a disassembler? That should give a few hints about what's going on... James.
Re: Sources of information
On Tue, 22 Aug 2000, Douglas Ridgway wrote: > Don't forget Windows 95 System Programming Secrets: it also has a few > tidbits. Now out of print, unfortunately. Good point - a couple of online bookstores can sometimes get hold of out of print editions if asked. Alternatively, being a Win95 book (hence a bit dated), perhaps the author would consider putting the text online?? > On Tue, 22 Aug 2000, James Sutherland wrote: > > > Alternatively, there's the Win2k source code, which could be of interest > > if you can get your hands on it :-) > > Windows source code isn't that hard to get -- there are many licensees, > including various universities. It's never been clear to me precisely what > you'd use it for, but I'd be glad to be enlightened. There's a copy of the Win2k source in Cambridge somewhere, certainly. I haven't read the license myself, but I've discussed it with one of those with access, and it seems quite permissive: AIUI, you can use the source to create your own software, and you're free to do what you want; alternatively, you can create software containing their source, and talk to them about royalties. Limited use for Wine purposes - you wouldn't be allowed to release the source to bits written using their proprietary information - but still helpful in some instances, I suspect. James.
Re: Toolhelp stuff
Andreas Mohr <[EMAIL PROTECTED]> writes: > Extended THHOOK in order to let some program start up. Do we really need 512 bytes here? Seems a bit wasteful, especially if it requires adding a new winebuild keyword just for a single entry point. Also do you really have an app that needs the BurgerMaster structure (apart from the Undocumented Windows examples)? If so you should probably consider a GlobalAlloc instead, using HIWORD(SEGPTR_GET) cannot possibly do the right thing. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Sources of information
On Tue, 22 Aug 2000, you wrote: >On Tue, 22 Aug 2000, Dave Pickles wrote: > >> Are there any sources of 'undocumented' information about Win32 useful for >> Wine? >> >> I have Schulman's "Undocumented Windows" book, but that covers 16-bit >> Windows only. I assumed there would be a similar book covering Win32 but a >> search in Foyles (London's largest technical bookshop) failed to find one. >> There is an "Undocumented NT" but it doesn't cover the gaps in the Win32 >> API information. > >He also wrote "Unauthorized Windows '95", which makes quite interesting >reading. It was written before the final builds were out, so there are a >couple of features which have changed (WINBOOT.SYS reverted to being >IO.SYS, for example, except on the installation media), but quite a good >discussion of Win95's underside. Possibly a bit too low-level, though. > >IIRC, there were four books - Undocumented DOS and Undocumented Windows, >and DOS Internals and Windows Internals. All four would be of use for the >low-level aspects of Windows, but only as far as 3.1. > >The Win32 SDK could also be of use - it has a great big .HLP file >documenting much of the API. There's a link to it somewhere on WineHQ; >it's also included with Borland's development tools. > >Alternatively, there's the Win2k source code, which could be of interest >if you can get your hands on it :-) Hmmm thanks. I was looking for some information on functions exported from NT's KERNEL.DLL which don't appear in any documentation. For example, CmdBatNotification(), GetConsoleCommandHistory() and ConsoleSubst(). Dave Pickles
Re: Sources of information
Don't forget Windows 95 System Programming Secrets: it also has a few tidbits. Now out of print, unfortunately. On Tue, 22 Aug 2000, James Sutherland wrote: > Alternatively, there's the Win2k source code, which could be of interest > if you can get your hands on it :-) Windows source code isn't that hard to get -- there are many licensees, including various universities. It's never been clear to me precisely what you'd use it for, but I'd be glad to be enlightened. doug. [EMAIL PROTECTED]
Re: Code page stuff is broken
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> 1. My app loads resources (russian text) from resources. Resources are in unicode,
> loaded text is in ANSI (LoadStringA was used).
>
> 2. Then app displays the text using ExtTextOutA. Here the problems begin.
> Now ExtTextOutA assumes, that ANSI code page and code page of currently
> selected font is the same. It is wrong assumption. As it was many times
> pointed out (at least by me).
It's not assuming they are the same, it's assuming that the app wants
TextOutA to display the string using the font codepage, which is not
entirely unreasonable (though I agree you can also argue that it
should assume CP_ACP instead).
Maybe the problem is that we should always try to use the right font
charset for the current codepage unless specified explicitly? Would a
patch like this improve the situation?
Index: graphics/x11drv/xfont.c
===
RCS file: /opt/cvs-commit/wine/graphics/x11drv/xfont.c,v
retrieving revision 1.55
diff -u -r1.55 xfont.c
--- graphics/x11drv/xfont.c 2000/08/20 20:08:35 1.55
+++ graphics/x11drv/xfont.c 2000/08/22 19:38:13
@@ -2243,8 +2243,15 @@
{
if( pfm->internal_charset == DEFAULT_CHARSET )
{
- if (pfi->internal_charset != ANSI_CHARSET)
- penalty += 0x200;
+ static WORD user_codepage;
+ if (!user_codepage)
+ {
+ char buf[32];
+ if (GetLocaleInfoA( GetUserDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE,
+ buf, sizeof(buf) )) user_codepage = atoi(buf);
+ }
+ if (pfi->codepage != user_codepage)
+ penalty += 0x200;
}
else if (pfm->internal_charset != pfi->internal_charset)
{
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Sources of information
On Tue, 22 Aug 2000, Dave Pickles wrote: > Are there any sources of 'undocumented' information about Win32 useful for > Wine? > > I have Schulman's "Undocumented Windows" book, but that covers 16-bit > Windows only. I assumed there would be a similar book covering Win32 but a > search in Foyles (London's largest technical bookshop) failed to find one. > There is an "Undocumented NT" but it doesn't cover the gaps in the Win32 > API information. He also wrote "Unauthorized Windows '95", which makes quite interesting reading. It was written before the final builds were out, so there are a couple of features which have changed (WINBOOT.SYS reverted to being IO.SYS, for example, except on the installation media), but quite a good discussion of Win95's underside. Possibly a bit too low-level, though. IIRC, there were four books - Undocumented DOS and Undocumented Windows, and DOS Internals and Windows Internals. All four would be of use for the low-level aspects of Windows, but only as far as 3.1. The Win32 SDK could also be of use - it has a great big .HLP file documenting much of the API. There's a link to it somewhere on WineHQ; it's also included with Borland's development tools. Alternatively, there's the Win2k source code, which could be of interest if you can get your hands on it :-) James.
Sources of information
Are there any sources of 'undocumented' information about Win32 useful for Wine? I have Schulman's "Undocumented Windows" book, but that covers 16-bit Windows only. I assumed there would be a similar book covering Win32 but a search in Foyles (London's largest technical bookshop) failed to find one. There is an "Undocumented NT" but it doesn't cover the gaps in the Win32 API information. Dave Pickles
Re: Code page stuff is broken
Hello. Unquestionably, this patch should be improved. (special handling of ANSI_CHARSET should be added.) > 2. Then app displays the text using ExtTextOutA. Here the problems begin. > Now ExtTextOutA assumes, that ANSI code page and code page of currently > selected font is the same. It is wrong assumption. As it was many times > pointed out (at least by me). If you use default fonts like 'System' etc with ANSI_CHARSET, CP_ACP should be assumed. but at least, if charset is not ANSI_CHARSET, this should not be assumed! Suggested fix is: - to treat ANSI_CHARSET as a special case. use CP_ACP for ANSI_CHARSET. - If CP_ACP is one of DBCS codepages, ANSI_CHARSET should be treated as a DBCS charset. - to improve DEFAULT_CHARSET(don't care) handling. > Suggested fix: > Wine should always treat non-unicode text as it is in current ANSI code page. > Code page of font is an internal problem of display driver and hacks for > internal support of several code pages simultaneously should not be introduced. At least this assumption is wrong in TextOutA with codepage 949(Korean) in original Windows 98(Far east version). Windows 98 handle codepage 949 correctly if we create font with lf.lfCharSet=HANGEUL_CHARSET. (Maybe) this problem is caused from wine's ANSI_CHARSET handling. ANSI_CHARSET should be handled as a CHARSET with CP_ACP (at least far east version of windows treats so), but wine don't handle this special case. -- Hidenori Takeshima
Code page stuff is broken
Hello. This patch broke correct displaying of cyrillic characters: revision 1.28 date: 2000/08/20 20:08:35; author: julliard; state: Exp; lines: +20 -14 Hidenori Takeshima <[EMAIL PROTECTED]> Handle the codepage of fonts if supported by the graphics driver. because of: 1. My app loads resources (russian text) from resources. Resources are in unicode, loaded text is in ANSI (LoadStringA was used). 2. Then app displays the text using ExtTextOutA. Here the problems begin. Now ExtTextOutA assumes, that ANSI code page and code page of currently selected font is the same. It is wrong assumption. As it was many times pointed out (at least by me). Suggested fix: Wine should always treat non-unicode text as it is in current ANSI code page. Code page of font is an internal problem of display driver and hacks for internal support of several code pages simultaneously should not be introduced. Please, remove that patch! Dmitry.
Re: Graphic problems
At 03:59 PM 8/21/00 -0700, you wrote: >> This error message seems recent : >>if (dc->w.flags & DC_DIRTY) ERR( "DC is dirty. Please report this.\n" ); > >This is because the DC update stuff is now done only in DC_GetDCUpdate >to play correctly with GDI locking. This should fix the problem: Indeed. Gerard
