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

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Uwe Bonnes

>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)baikal.ru> writes: Dmitry> "Dan Kegel" <dank(a)kegel.com> wrote: >> Backtrace: =>0 0x409e5873 (BeginPaint+0x9f(hwnd=0x10029, lps=0x0) >> [painting.c:200] in user32.dll.so) (ebp=40892bc4) Dmitry> Attached patch should help a bit. Dmitry> -- Dmitry. Protect BeginPaint and EndPaint from lps being NULL. Dmitry> --- cvs/hq/wine/dlls/user/painting.c Thu Jan 09 03:41:30 2003 Dmitry> +++ painting.c Mon Apr 28 10:15:46 2003 @@ -159,6 +159,8 @@ HWND Dmitry> full_handle; WND *wndPtr; Dmitry> + if (!lps) return 0; + if (!(full_handle = WIN_IsCurrentThread( Dmitry> hwnd ))) { if (IsWindow(hwnd)) @@ -239,6 +241,8 @@ */ BOOL Dmitry> WINAPI EndPaint( HWND hwnd, const PAINTSTRUCT *lps ) { + if Dmitry> (!lps) return FALSE; + ReleaseDC( hwnd, lps->hdc ); ShowCaret( Dmitry> hwnd ); return TRUE; Is lps==NULL an argument that BeginPaint() and EndPaint() should cope with or is it a result for errors hidden deeper? -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

April 28, 2003

Re: slovene keyboard without dead keys

by Shachar Shemesh

Dmitry Timoshkov wrote: >Yes, that's one of the cases when our current scheme doesn't work. But one >excuse for us is that XFree86 4.3.0 is fairly new. > > All I was saying was that we NEED to support it. We can no longer hide behind X's inability to do so, as it now does. The new X keyboard layouts make much more sense, and making people effectively revert to the old one is an incorrect solution, IMHO. >>Excellent. Please bear in mind, however, that sometimes it is >>desireable, and even crucial, to have more than one layout and switch. >> >> > >That should be fairly easy to implement, since under XFree86 4.3 every international >layout is not mixed with any other, even with an en_US one. > > I was meaning for X 4.3.0. I have no problem that people working with earlier versions will register under wine as having two keyboards (i.e. - US+another one). >>Also, the keyboard switching messages are crucial to some BiDi applications. >> >> >Do you mean WM_INPUTLANGCHANGEREQUEST and WM_INPUTLANGCHANGE messages? > > That's what I mean. >>Also important is an ability by the system to change keyboards. One such >>requirement is for BiDi text editing, where the algorithm includes, >>among other things, instances where it is necessary to change the >>current keyboard layout. >> >> >I'm not sure XFree86 supports this feature. Without support from X we couldn't >implement keyboard layout changes on application request. > Can't you set the current group? How are you planning on implementing "INPUTLANGCHANGEREQUEST" otherwise? > Also I don't know >whether XFree has a layout enumeration facility. > > We use it today for comparing the keyboards. >Windows knows nothing about a KOI8-R based locale. 20866 is just one of >the code page numbers. Of course in order to support it we may introduce >new, Wine specific LCID with SUBLANG_RUSSIAN_KOI8R. > > We may have to. I feel really bad about this, especially as I cannot perform any useful task myself at the moment, but there is one more question. Can we shorten the current path each key takes? Current path: 1. User presses key. 2. X sends virtual key to app (wine) 3. Wine translates virtual key to ascii. 4. Wine looks up the ascii in the currently selected keymap. 5. Wine translates ascii to virtual key 6. Virtual key is sent to Windows application, which translates it back to ascii (usually). This is broken on two very hurting points. 1. If the current locale doesn't allow for the ascii for the key pressed, it will not pass on to the application, even if the app is a UNICODE app. 1. In particular - if the locale codepage is UTF-8, I cannot type any non-latin key, as the keyboard layouts are in ANSI codepages. 2. There is no chance in hell in supporting a English+Hebrew+Russian application, as the last two languages use two distinct codepages, which cannot, technically, be loaded simultaniously (see 1.1 above for why UTF-8 will not work). Last, there is a problem that does not hurt so much, but is still a problem 3. There is great uncertanty regarding the matter of whose responsibility it is to mirror characters on right to left language keyboards. Mirroring is the process of emiting "(" when shift-0 is pressed, despite it being the character opposite the one engravd on the keyboard, and trusting the BiDi display to mirror it back. Some say the X keyboard layout should do it, while others say the infrastructure should do it. What I suggest (and what I was planning on doing myself, should I ever have any free time again) was to leave the current keyboard detection routine as is (seperating the different keyboards, of course), but not translate the VKey to ascii, but send it on as is. When the application asks to translate, then we look it up in what we know to be the current keyboard. This way, if the keyboard layout has ( and ) non-switched, we will switch them ourselves. This means that Wine has a different keyboard than the rest of X, but that's on purpose. Shachar

April 28, 2003

New patch for WINE support in valgrind uploaded to sourceforge

by Adam Gundy

A new version of the patch to valgrind needed to support WINE has been uploaded to Sourceforge: http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46… It should apply cleanly to current valgrind CVS. This version of the patch will now work with an unmodified WINE CVS version. This is because it now _fully_ implements clone() support - ie it really does create system level threads. Currently only one thread can run at a time, so there are no locking issues in the main valgrind code. To use with WINE, you need to get a CVS checkout of valgrind, then apply the patch using: export CVSROOT=:pserver:anonymous(a)cvs.sourceforge.net:/cvsroot/valgrind cvs login cvs co valgrind patch -p0 < valgrind-wine.patch.13 then build and install valgrind: autogen.sh ./configure make install Get a CVS checkout of WINE by following the instructions at: http://www.winehq.com/?page=cvs then configure (for debugging) and build: CFLAGS=-g ./configure make depend && make install now you can start looking for bugs in WINE, and bugs in your own (debug) Windows code. Copy any DLLs/EXEs to somewhere WINE can get to them, plus copy any .PDB files that go with them into the same directory. Run WINE under valgrind using eg: valgrind --num-callers=30 --workaround-gcc296-bugs=yes wine notepad.exe or even: valgrind --num-callers=30 --workaround-gcc296-bugs=yes --gdb-attach=yes wine notepad.exe enjoy. Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.

April 28, 2003

Re: Crash in BeginPaint running Sams Photofact index, a free VB app

by Mike Hearn

Try this patch: --- painting.c.old 2003-04-28 10:44:52.000000000 +0100 +++ painting.c 2003-04-28 10:44:55.000000000 +0100 @@ -159,6 +159,9 @@ HWND full_handle; WND *wndPtr; + /* sanity check */ + if (!lps) return 0; + if (!(full_handle = WIN_IsCurrentThread( hwnd ))) { if (IsWindow(hwnd)) On Mon, 2003-04-28 at 07:26, Dan Kegel wrote: > Wine is coming along! It can *almost* run a real world VB app > I downloaded tonight. I'm trying to fix an old TV, and I wanted > to see if Sams has a manual for it, so I downloaded their > index program (http://www.servicesoftware.com/sams/) > and was happy to discover it installed properly under a > recent Wine (once I copied in the msiexec stuff, stdole2.tlb, etc.). > > However, it didn't quite run properly. Here's what I got running > it under wine-20030408: > > Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x409e5873). > In 32-bit mode. > 0x409e5873 (BeginPaint+0x9f [painting.c:200] in user32.dll.so): movl %eax,0x0(%edx) > 203 if (!lps->hdc) > Wine-dbg>bt > Backtrace: > =>0 0x409e5873 (BeginPaint+0x9f(hwnd=0x10029, lps=0x0) [painting.c:200] in user32.dll.so) (ebp=40892bc4) > 1 0x52195475 (GRIDX.OCX..text+0x14475 in C:\WINDOWS\SYSTEM\GRIDX.OCX) (ebp=40892c18) > 2 0x52194fe0 (GRIDX.OCX..text+0x13fe0 in C:\WINDOWS\SYSTEM\GRIDX.OCX) (ebp=40892c40) > 3 0x5218b961 (GRIDX.OCX..text+0xa961 in C:\WINDOWS\SYSTEM\GRIDX.OCX) (ebp=40892c88) > 4 0x409cc817 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=40892cac) > 5 0x409cc875 (WINPROC_CallWndProc+0x55(proc=0x41855438, hwnd=0x10029, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:185] in user32.dll.so) (ebp=40892cd8) > 6 0x409d1535 (CallWindowProcA+0xf9(func=0x40df0908, hwnd=0x10029, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2812] in user32.dll.so) (ebp=40892d0c) > 7 0x409b5a3e (DispatchMessageA+0x96(msg=0x40892d68) [message.c:794] in user32.dll.so) (ebp=40892d50) > 8 0x66014979 (MSVBVM60.DLL.__vbaInStr+0x3b7 in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=40892d90) > 9 0x660148b2 (MSVBVM60.DLL.__vbaInStr+0x2f0 in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=40892dd4) > 10 0x66014790 (MSVBVM60.DLL.__vbaInStr+0x1ce in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=6601a360) > 11 0x66010e00 (MSVBVM60.DLL.BASIC_CLASS_QueryInterface+0x17 in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=660d3526) > 12 0x0c2474ff (SAMSINDX.exe..rsrc+0xbe334ff) (ebp=0424448b) > *** Invalid address 0x0424448b (SAMSINDX.exe..rsrc+0x3e3048b) > > I can run this app under real Windows, but this is such a juicy little > testcase I bet someone will want to take a look at it :-) > - Dan -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 28, 2003

Re: slovene keyboard without dead keys

by Dmitry Timoshkov

"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote: > >I don't see why explicitly adding a "us" keyboard layout would hurt people, > >since before 4.3.0 release en_US was a mandatory layout existing whether > >the user wanted it or not. > > > > > Ok, how about this. A Russian immegrant to Israel (and there are lots of > those), would want his keyboard settings to be "us,il,ru". Windows > supports this. X now supports this. Why shouldn't Wine? Yes, that's one of the cases when our current scheme doesn't work. But one excuse for us is that XFree86 4.3.0 is fairly new. > >Actually I have a plan to implement support for keyboard layout Win32 APIs > >and that anyway requires rewrite of big chunks of the existing keyboard code > >in x11drv, and as a part of that rewrite I'm going to decouple all existing > >keyboard layout tables with a US English one and build new tables with LCID > >and a layout id, > > > Excellent. Please bear in mind, however, that sometimes it is > desireable, and even crucial, to have more than one layout and switch. That should be fairly easy to implement, since under XFree86 4.3 every international layout is not mixed with any other, even with an en_US one. > Also, the keyboard switching messages are crucial to some BiDi applications. Do you mean WM_INPUTLANGCHANGEREQUEST and WM_INPUTLANGCHANGE messages? > Also important is an ability by the system to change keyboards. One such > requirement is for BiDi text editing, where the algorithm includes, > among other things, instances where it is necessary to change the > current keyboard layout. I'm not sure XFree86 supports this feature. Without support from X we couldn't implement keyboard layout changes on application request. Also I don't know whether XFree has a layout enumeration facility. > > but so far I don't know how to support several layouts for > >single locale but with different code pages (for instance for Russian locale > >we need to support 20866 (KOI8-R) and 1251 code pages). > > > > > Don't they have different sub-langs? How does Win32 hadle this? Windows knows nothing about a KOI8-R based locale. 20866 is just one of the code page numbers. Of course in order to support it we may introduce new, Wine specific LCID with SUBLANG_RUSSIAN_KOI8R. -- Dmitry.

April 28, 2003

WineHQ: different pages with same content

by Stefan Leichter

Hello, during browsing WineHQ offline (via wwwoffle) i noticed that the links in the left column of the current WWN are different to the links on the main page and some other (have not tested all) e.g. in the development section of the WWN the CVS link is: http://www.winehq.com/index.php?page=cvs on the main page (and other) the link is http://www.winehq.com/?page=cvs Any reason for this? Bye Stefan

April 28, 2003

Crash in BeginPaint running Sams Photofact index, a free VB app

by Dan Kegel

Wine is coming along! It can *almost* run a real world VB app I downloaded tonight. I'm trying to fix an old TV, and I wanted to see if Sams has a manual for it, so I downloaded their index program (http://www.servicesoftware.com/sams/) and was happy to discover it installed properly under a recent Wine (once I copied in the msiexec stuff, stdole2.tlb, etc.). However, it didn't quite run properly. Here's what I got running it under wine-20030408: Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x409e5873). In 32-bit mode. 0x409e5873 (BeginPaint+0x9f [painting.c:200] in user32.dll.so): movl %eax,0x0(%edx) 203 if (!lps->hdc) Wine-dbg>bt Backtrace: =>0 0x409e5873 (BeginPaint+0x9f(hwnd=0x10029, lps=0x0) [painting.c:200] in user32.dll.so) (ebp=40892bc4) 1 0x52195475 (GRIDX.OCX..text+0x14475 in C:\WINDOWS\SYSTEM\GRIDX.OCX) (ebp=40892c18) 2 0x52194fe0 (GRIDX.OCX..text+0x13fe0 in C:\WINDOWS\SYSTEM\GRIDX.OCX) (ebp=40892c40) 3 0x5218b961 (GRIDX.OCX..text+0xa961 in C:\WINDOWS\SYSTEM\GRIDX.OCX) (ebp=40892c88) 4 0x409cc817 (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=40892cac) 5 0x409cc875 (WINPROC_CallWndProc+0x55(proc=0x41855438, hwnd=0x10029, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:185] in user32.dll.so) (ebp=40892cd8) 6 0x409d1535 (CallWindowProcA+0xf9(func=0x40df0908, hwnd=0x10029, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2812] in user32.dll.so) (ebp=40892d0c) 7 0x409b5a3e (DispatchMessageA+0x96(msg=0x40892d68) [message.c:794] in user32.dll.so) (ebp=40892d50) 8 0x66014979 (MSVBVM60.DLL.__vbaInStr+0x3b7 in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=40892d90) 9 0x660148b2 (MSVBVM60.DLL.__vbaInStr+0x2f0 in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=40892dd4) 10 0x66014790 (MSVBVM60.DLL.__vbaInStr+0x1ce in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=6601a360) 11 0x66010e00 (MSVBVM60.DLL.BASIC_CLASS_QueryInterface+0x17 in C:\WINDOWS\SYSTEM\MSVBVM60.DLL) (ebp=660d3526) 12 0x0c2474ff (SAMSINDX.exe..rsrc+0xbe334ff) (ebp=0424448b) *** Invalid address 0x0424448b (SAMSINDX.exe..rsrc+0x3e3048b) I can run this app under real Windows, but this is such a juicy little testcase I bet someone will want to take a look at it :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

April 28, 2003

Re: Wine, WIDE & Unix (was: Support for pkgconfig)

by Dimitrie O. Paun

On April 27, 2003 05:32 pm, Francois Gouget wrote: > Bah, I don't really care. Maybe because I use neither Gnome nor KDE. > I see your point but I can't help but think that it's a bit of a stretch > to say Trolltech could become another monopoly when there is a GPL > implementation available, which is why I said the above. I really don't understand you. It seems to me obviously clear that a GPLed platform is as useful as a GPLed Wine. This is not something minor, and it's no stretch -- the Trolls would have the monopoly over all commercial apps, which is where the money is. You may not use either, but that's no solution. People will have to choose one or the other, they can't go back to Xaw or Motif. > Now if you think WIDE is portable, tell us how. Well, we do have Winelib working on non-i386 platforms, don't we? But bottom line, people worried about portability should program to the Gnome/Gtk API, I haven't suggested for a moment we drop Gtk and code everything to the Win32 API. For people like the emule guys that like to code to the Win32 API, they can continue to do so if they so wish. > So the situation will remain the same: we will haev KDE applications and > WIDE applications and they will not be interoperable. I.e. it won't be > possible to insert an Excel spreadsheet in a KWord document. No, it will be better: you will be able to have deep integration between Win32 apps and Gnome apps, no small feat. > Does that include interoperability with OLE/COM/DCOM or just the look > and feel integration? Well, the OLE/COM/DCOM bit is the interesting one, the look and feel is simple and has other solutions, as we discussed. > I believe where we differ is on the method: > * I think we should work on Wine to make that possible (though > there may be some work to do in Gnome and KDE). For sure. But this will work for things like L&F. The difficult things aren't even considered by anyone at this point. So no, we are quite in violent agreement here. > * You think that it is mostly Gnome that must be modified to use the > Wine APIs and you are ready to drop/ignore KDE. I believe you also > proposed to replace Nautilus/Konqueror with Explorer, and to develop > a new window manager. No, I'm not dropping/ignoring KDE. It's just that right now we're talking about some deep integration issues that no one even considered before. Right now, integration is used to describe L&F. It's fairly clear we need to be able to integrate with things like BlueCurve so Wine integrates as much as possible in both Gnome and KDE. Wide doesn't change that. In fact, being based on Wine, it will implicitly benefit from all the integration work we do on the Wine side. But at that point, people will ask: what is the difference between Wide, and just Wine running in Gnome? And it's a good question. Part of the answer is that Wide may choose to use Wine's OLE implementation to integrate Bonobo/Win32/OpenOffice apps. But that's really wishfull thinking, I'm not even sure that's at all possible. The real answer is that Wide is just like Gnome, but with a different set of mentalities. Instead of picking the default apps only based on religious things like 'is it using Gtk?', I propose we choose the default apps from the set of all Gnome and free Win32 apps (and any other platform that integrates nicely). I am sorry I can't include KDE here as well, but it's because their platform is not free enough, not because I don't like the Qt framework. If tomorrow we have a LGPL Qt implementation, they would be added to the pool of possible apps. This should answer your Nautilus/Konqueror/Explorer. I have to religious affiliation to Nautilus or Konqueror. If the ReactOS people build a better (and free) browser, it goes in as the default browser. Apps should compete on features and user experience, not on irrelevant implementation details. -- Dimi.

April 28, 2003

Re: slovene keyboard without dead keys

by Shachar Shemesh

Dmitry Timoshkov wrote: >I don't see why explicitly adding a "us" keyboard layout would hurt people, >since before 4.3.0 release en_US was a mandatory layout existing whether >the user wanted it or not. > > Ok, how about this. A Russian immegrant to Israel (and there are lots of those), would want his keyboard settings to be "us,il,ru". Windows supports this. X now supports this. Why shouldn't Wine? >>I would volunteer to do it, except I'm unusually busy of late. I know >>that you have messed around with the keyboard code at some time. If you >>have time, I recommend you look at it. >> >> > >Actually I have a plan to implement support for keyboard layout Win32 APIs >and that anyway requires rewrite of big chunks of the existing keyboard code >in x11drv, and as a part of that rewrite I'm going to decouple all existing >keyboard layout tables with a US English one and build new tables with LCID >and a layout id, > Excellent. Please bear in mind, however, that sometimes it is desireable, and even crucial, to have more than one layout and switch. Also, the keyboard switching messages are crucial to some BiDi applications. Also important is an ability by the system to change keyboards. One such requirement is for BiDi text editing, where the algorithm includes, among other things, instances where it is necessary to change the current keyboard layout. > but so far I don't know how to support several layouts for >single locale but with different code pages (for instance for Russian locale >we need to support 20866 (KOI8-R) and 1251 code pages). > > Don't they have different sub-langs? How does Win32 hadle this? Shachar

April 28, 2003

Re: Patch to get Borland's bcc 5.5 (free beer compiler) to work

by Dimitrie O. Paun

On April 27, 2003 08:15 pm, Troy Rollo wrote: > The only problem in the head code appears to be in the linker, which it > turns out has a problem when it's told there's 3GB of user address space. This is pretty cool. I've added you to the Fun page: http://63.138.153.104/wine/Wine-Fun.html#source Few questions: * Do you build on Windows? * Could we run bcc in Wine on Linux to build on Linux using bcc? * How far do you get? Do you actually get an executable? * Does it run? * What are the steps you need to take? A concise list of instructions would be nice :) I can post it on the Fun page, so other can play with it was well. -- Dimi.

April 28, 2003