wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Problems with rsaenh/advapi32 and 'Myst Uru Demo'
by Paul Vriens 20 Feb '05

20 Feb '05

Hi, I've download a bunch of demo-apps and this one (http://www.gamershell.com/news/10306.html) has some problems with the builtin rsaenh.dll/advapi32.dll. The trace (+crypt,+loaddll) shows: fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x77e39320): not verifying image trace:crypt:RSAENH_CPAcquireContext (phProv=0x77e3941c, pszContainer="{07EC3FFA-8373-11D9-C687-000CF1342294}", dwFlags=00000010, pVTable=0x77e394d0) trace:crypt:CryptReleaseContext (0x77e38c68, 00000000) trace:crypt:RSAENH_CPReleaseContext (hProv=00000001, dwFlags=00000000) trace:loaddll:MODULE_FlushModrefs Unloaded module L"c:\\windows\\system\\rsaenh.dll" : builtin trace:crypt:CryptDestroyHash (0x77e38c48) wine: Unhandled exception (thread 000d), starting debugger... Is this due to the 'lack' of reference counting in the advapi32 crypt stuff? It looks like RSAENH_CPReleaseContext released 'everything' where it shouldn't, hence the failure of CryptDestroyHash. Cheers, Paul.

2 1

wpp
by Ge van Geldorp 20 Feb '05

20 Feb '05

wpp will currently silently drop non-preprocessor stuff (typedefs, function prototypes etc.) when #including a .c or .h file. However, if you preprocess e.g. a .rc file externally and then feed it to wrc (which in turn will feed it through wpp) the non-preprocessor stuff isn't removed. The patch below changes that, by looking at the filename on the #line directive. If it ends in .c or .h, no output is generated (but the file is still parsed for preproc statements ofcourse). We need this for ReactOS, it doesn't hurt Wine (yes, I've tested it <g>) and including it in Wine would make my monthly job of merging Wine and ReactOS a tad easier. If there are no objections I'll submit to wine-patches in a few days. We also have another change in wpp, which adds support for #include_next (can't take credit for that, Filip Navara wrote it). Since you can't use that #include_next in Wine anyway (not every compiler supports it) I'm not going to bother creating and testing a Wine patch for it. If I misjudged and there is interest in this from the Wine side just let me know. Ge van Geldorp. Index: libs/wpp/ppl.l =================================================================== RCS file: /home/wine/wine/libs/wpp/ppl.l,v retrieving revision 1.4 diff -u -r1.4 ppl.l --- libs/wpp/ppl.l 21 Oct 2003 23:57:25 -0000 1.4 +++ libs/wpp/ppl.l 20 Feb 2005 15:12:10 -0000 @@ -232,6 +232,7 @@ static void newline(int); static int make_number(int radix, YYSTYPE *val, const char *str, int len); static void put_buffer(const char *s, int len); +static int is_c_h_include(char *fname, int quoted); /* Buffer management */ static void push_buffer(pp_entry_t *ppp, char *filename, char *incname, int pop); static bufferstackentry_t *pop_buffer(void); @@ -551,11 +552,15 @@ case pp_define: case pp_mbody: case pp_inc: - case pp_line: case RCINCL: if (yy_current_state()==RCINCL) yy_pop_state(); pplval.cptr = get_string(); return tDQSTRING; + case pp_line: + pplval.cptr = get_string(); + if (is_c_h_include(pplval.cptr, 1)) pass_data=0; + else pass_data=1; + return tDQSTRING; default: put_string(); } @@ -1404,12 +1409,12 @@ * Include management *------------------------------------------------------------------------- */ -static int is_c_h_include(char *fname) +static int is_c_h_include(char *fname, int quoted) { int sl=strlen(fname); - if (sl < 2) return 0; - if ((toupper(fname[sl-1])!='H') && (toupper(fname[sl-1])!='C')) return 0; - if (fname[sl-2]!='.') return 0; + if (sl < 2 + 2 * quoted) return 0; + if ((toupper(fname[sl-1-quoted])!='H') && (toupper(fname[sl-1-quoted])!='C')) return 0; + if (fname[sl-2-quoted]!='.') return 0; return 1; } @@ -1448,7 +1453,7 @@ pp_incl_state.seen_junk = 0; pp_incl_state.state = 0; pp_incl_state.ppp = NULL; - if (is_c_h_include(newpath)) pass_data=0; + if (is_c_h_include(newpath, 0)) pass_data=0; else pass_data=1; if(pp_status.debug)

1 0

press -- eweek, Microsoft Seeks to Bottle Up Open Source Wine
by Tom 20 Feb '05

20 Feb '05

Hello All, I just ran across this at eweek: http://www.eweek.com/article2/0,1759,1766843,00.asp Ivan you are now famous can I get your autograph ;) Tom

4 7

idea to spot regressions
by Jonathan Ernst 19 Feb '05

19 Feb '05

Hi everyone, I'd like to know what you people think about this idea for the application database: When an application version goes from gold to silver or silver to bronze for example, the AppDB asks the maintainer if he wants to inform wine developpers about this regression and if yes the maintainer has a field where he can enter some comments about the regression and the AppDB sends an e-mail to wine-devel with links to the AppDB entry and the maintainer's comments. This would ease the task for maintainer to report regressions and for developpers to know about them. Looking forward to reading your comments. Jonathan

1 0

Re: Microsoft genuine downloads looking for wine
by Sam Lauber 19 Feb '05

19 Feb '05

Agreed. Can't we just delete HKEY_CLASSES_ROOT/Software/Wine or move it to another name? > >> In any case, at least from a technical point of view, going > >> around such test ought to be fairly simple > If the mere existence of this key makes the validation fail, what's > to stop a virus from simply adding this key as a way to stop > legitimate users from downloading the security fix for that same > virus? If MS is really doing what we think they may be doing here, > I don't think they are going to be enjoying it for long. They are > (what else is new?) shooting themselves in the foot (again?). They're probably famous for that already ;-). > > I don't think we want to go there. I demonstrated a way of checking for > > Wine to Rob last night that we really cannot fix or workaround, and if I > > can think of it they certainly can too. > I think I know what way you are thinking of. Not sure someone less > versed in the way Wine works (it's an emulator, right?) would > figure that one out, but I guess you are right. I'll try to catch > you on IRC and see if we are, indeed, talking about the same thing. > > > Basically if we start integrating workarounds into Wine, it'll lead to an > > arms race we cannot possibly win. > > > Technically, it will probably cost them more than it will cost us. > Then again, they also have more resources. I'll just point out that > I don't think there is anything inherently wrong with MS wishing to > keep the parts that truly are core Windows for Windows legal > license users only. The main problem with MS is that what they call > "core OS" can get quite absurd. > > > Better to ensure our users don't need > > anything from that website. > Amen to that. So, opengl, dcom, what else do we need? :-) Write our own replacement. Try OpenGL first. We might have to clean-room reverse-engineer DCOM. IMO, the `core' operating system (besides the CD!) is the main installation disks and service packs. Anything else is what I call a `program'. Samuel Lauber -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

2 1

Re: Making builtin OLE32 work right
by Mike Hearn 19 Feb '05

19 Feb '05

Here is a brain dump of what I already know we need to fix for the CW supported apps: 1) InstallShield: RPC call re-entrancy 2) Lotus Notes: OLE drag/drop leaves an image of the window behind when it closes. Native does this functionality very differently to us. 3) VB apps: As Holly Bostick discovered to her cost, we can't load all OLEPicture resources correctly. Our OLEFont code also has misc bugs in, but we don't have any tests and code which uses these objects is rare so the full extent of the work here is an unknown 4) OLE Storage: IIRC misc things break in Office when this is pulled 5) Office embedding: We need marshallers for IOleObject for this, I think ... possibly a lot more. I do not know the details. 6) iTunes/iPod: Not fully investigated yet but I think we need to drop the typelib marshaller hack (this stands a good chance of breaking InstallShield for a short time as well) And one thing we probably don't care about: 7) Microsoft Transaction Server needs the typelib marshaller to generate RPC marshal-ops (format strings) instead of using custom marshalling like we do right now. But who cares about MTS while InstallShield and Office still aren't there? :) thanks -mike On Sat, 19 Feb 2005 10:58:27 +0900, Mike McCormack wrote: > Hi All, > > I'd like to compile a list of all applications that don't work correctly > without native ole32 (aka dcom95), then go through and try fix them. > > I think bugzilla is probably the right place to save the list, and that > alot of the information we're looking for is already in the appdb. > > How can we extract if easily? Maybe the appdb guys can provide a check > box that app maintainers can click on to indicate that builtin ole32 > works fine? > > any ideas? > > Mike

1 0

modem
by Hartmut Haase 19 Feb '05

19 Feb '05

I'm not sure if this is the right address, but you can certainly forward it to the right person(s): I'm using an analog modem, and as it is not easy to select the appropriate cal-by-call provider, I tried to use web.de's SmartSurfer which works fine with windows. But wine gives me only the choice to select some 'WINE virtmodem' which is certainly not the right one. Yast tells me that my modem is device ppp0. What can I do? -- Viele Grüße, Hartmut Haase Hungerhilfe: http://www.thehungersite.com Das heutige Motto: The most exhausting thing in life is being insincere

2 1

Re: Making builtin OLE32 work right
by Tony Lambregts 19 Feb '05

19 Feb '05

Mike McCormack wrote: > > Hi All, > > I'd like to compile a list of all applications that don't work correctly > without native ole32 (aka dcom95), then go through and try fix them. > > I think bugzilla is probably the right place to save the list, and that > alot of the information we're looking for is already in the appdb. > > How can we extract if easily? Maybe the appdb guys can provide a check > box that app maintainers can click on to indicate that builtin ole32 > works fine? > Well If I can get around to submitting my "new bugzilla integration" patch this could work right. The idea is to be able to attach multiple apps (versions) to the same bug. Right now we use "url" in Bugzilla to attach a bug to an app and that limits us to on app per bug. The feature you want is to be able to click on a link in a bug and see all the applications that that bug affects. I know exactly what I want it to do. I even have a bit rotted (almost) working version on my old machine. The problem I currently have is trying to keep up with the changes that Jon has been doing ( I don't work nearly as fast as him) so I have been waiting for the database to stablize a bit ... -- Tony Lambregts

3 3

Re: Add LPDWORD typedef to wtypes.idl
by Dmitry Timoshkov 19 Feb '05

19 Feb '05

"Vincent Béron" <vberon(a)mecano.gme.usherb.ca> wrote: > There are probably more pointer types missing from our wtypes.idl. > > Changelog: > Add LPDWORD definition to wtypes.idl. > --- include/wtypes.idl 8 Dec 2004 13:59:52 -0000 1.22 > +++ include/wtypes.idl 19 Feb 2005 00:41:55 -0000 > @@ -48,6 +48,8 @@ typedef float FLOAT; > > typedef void *PVOID, *LPVOID; > > +typedef unsigned long *LPDWORD; This introduces a potential miscompilation on 64-bit platforms. I'd suggest to use a base type instead of unsigned long: typedef DWORD *LPDWORD; -- Dmitry.

1 0

unable to maintain application despite of maintainer status
by Udo Rader 19 Feb '05

19 Feb '05

hi, I've just become the maintainer of an application (http://appdb.winehq.org/appview.php?appId=2002) and tried to do something meaningful with my new status but either I get "insufficient privileges" (eg. when trying to "add notes") or nothing useful happens. I am also not able to post screenshots for the apps, instead I (and certain other wine-related people) are emailed that somebody (me in fact!) has submitted a screenshot for the application. Sorry if this is a repost or something, but the maintainer guidelines for this on winehq.com just are not correct. Udo Rader -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ udo rader technischer leiter/CEM mobile ++43 660 5263642 ------------------------------------------------------------------------ eduard-bodem-gasse 8/3 A-6020 innsbruck fax ++43 512 935833 http://www.bestsolution.at phone ++43 512 935834

4 4

Re: wine/dlls/shell32 shell32.spec
by Christian Costa 19 Feb '05

19 Feb '05

Alexandre Julliard wrote: >ChangeSet ID: 16182 >CVSROOT: /opt/cvs-commit >Module name: wine >Changes by: julliard(a)wine.codeweavers.com 2005/02/18 14:13:01 > >Modified files: > dlls/shell32 : shell32.spec > >Log message: > Hans Leidekker <hans(a)it.vu.nl> > Mark exports -noname when they are exported by ordinal only on > win98/2k. > >Patch: http://cvs.winehq.org/patch.py?id=16182 > >Old revision New revision Changes Path > 1.91 1.92 +191 -191 wine/dlls/shell32/shell32.spec > > > > This patch causes regression in an app that searches for DragQueryPoint and DragQueryFileA. Christian

1 0

Re: World Of Warcraft
by Juan Lang 18 Feb '05

18 Feb '05

Alex wrote: > It all looks very promising until it patches itself up to version > 1.2.3, when it just crashes at startup. Does this patch help? Index: dlls/ntdll/nt.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/nt.c,v retrieving revision 1.72 diff -u -r1.72 nt.c --- dlls/ntdll/nt.c 11 Feb 2005 11:52:07 -0000 1.72 +++ dlls/ntdll/nt.c 18 Feb 2005 22:16:28 -0000 @@ -520,9 +520,12 @@ OUT PLARGE_INTEGER Frequency) { LARGE_INTEGER time; + + if (!Counter) return STATUS_ACCESS_VIOLATION; NtQuerySystemTime( &time ); Counter->QuadPart = time.QuadPart; - Frequency->QuadPart = 10000000; + if (Frequency) + Frequency->QuadPart = 10000000; return 0; } __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com

2 1

Re: [shell32tests/shelllink.c] Use aliases for ordinals (resend/rediff)
by Francois Gouget 18 Feb '05

18 Feb '05

Paul Vriens wrote: > Hi, > > to ease Alexandre's work I re-diffed the patch. The consensus on > wine-devel was that this patch is fine. > > This patch makes the crosstest compile work again for shell32. Result > tested on win98/winxp/Wine/W2KProf. > > Changelog: > Use aliases for calls to ordinals. I don't think that's what the consensus says, if a consensus there is in the first place. If I understand Filip Navara's patch correctly, it shows that the fix belongs in MinGW's shell32.def file. And if that's the case then I'm arguing this test should remain as is. As I understand it, once MinGW's file is fixed, the compiler sees that there is an ordinal associated to SHSimpleIDListFromPath and then generates an executable which imports SHSimpleIDListFromPath by ordinal. This seems to be exactly what Visual C++ does on Windows. It's perfectly acceptable to import SHSimpleIDListFromPath by name in programs compiled using Visual C++, and the resulting executable works even if shell32.dll exports this API by ordinal only. Our conformance tests should reflect that. That's because they are meant to reflect the Windows behavior (not the MinGW one), including where compilation and linking are concerned. -- Francois Gouget fgouget(a)codeweavers.com

6 9

Re: distcc and wine-installer
by Damian Dimmich 18 Feb '05

18 Feb '05

Ah, it helps to attach the patch.... On Friday 18 February 2005 18:34, Damian Dimmich wrote: > Hi, > > Just made a little patch to the wine installer script which allows the user > to specify a commandline flag to enable distcc support (using --distcc). > > This makes compiling loads faster if you have more than one machine to > compile on. > > Let me know if it does not work for you. > > Thanks, > Damian

1 0

dll/shell32/shlfileop.c cleanup questions
by Rolf Kalbermatter 18 Feb '05

18 Feb '05

Joris Huizer <jorishuizer(a)planet.nl> wrote: >I'm looking at the dll/shell32/shlfileop.c file; the function >SHFileOperationW is still huge but in order to split off sections (some >are clear to see but difficult to seperate from the rest) >I'd either have to use huge parameter lists, or put parts together in >structs (some vars are used everywhere in combination) What is your >opinion about this? > >Also, I found something weird, the line at the top of the while loop: > nFileOp.wFunc = ((level + 1) << 4) + FuncSwitch; >seems to be equivalent to > nFileOp.wFunc = (((lpFileOp->wFunc >> 4) + 1) << 4) + >(lpFileOp->wFunc & FO_MASK); >and > nFileOp.wFunc = (((lpFileOp->wFunc >> 4) + 1) << 4) + >(lpFileOp->wFunc & 0xF); >and > nFileOp.wFunc = (lpFileOp->wFunc & (~(0xF))) + (1 << 4) + >(lpFileOp->wFunc & 0xF); >and > nFileOp.wFunc = (lpFileOp->wFunc & (~(0xF))) + (0x10) + >(lpFileOp->wFunc & 0xF); >and > nFileOp.wFunc = lpFileOp->wFunc + 0x10; /* what's this 0x10? */ Well, Dietrich Teickner from whom I got that code implemented in this way a method to detect the nesting level of SHFileOperation calls as they can get called recursively. I have currently a version of the SHFileOperation lying around here which is still huge but I did start to place some parts in separate functions already. It is a considerably extended version of SHFileOperation than what is in CVS at the moment. It implements a few more features and also fixes some not so common cases where the current function can go havok with certain parameter combinations. But it was rejected for its sheer size, which I wasn't happy myself with but I inherited most of that and hadn't time until now to finish the cleanup and won't be able to do that in a short term either. My next step was to actually create a custom structure with some more parameters and implement a core file_operation() function which is eventually called recursively when necessary. The current SHFileOperation then will do some parameter checks and then prepare the new structure and call that file_operation(). When I get home, I will send the current code in an archive to you together with a tool I wrote to make a very thorough test of several thousend parameter combinations. The way I implemented that test tool was to simply dump the results of all those tests into a file to be able to make a diff with a known log from W2K. As it is at the moment it would not be good to include in the test framework because of the necessary comparison to a good log file and also because it takes about 90 seconds alone to run on my computer. (Well on Windows it takes actually at least double that but there the function also does Undo/Recycle Bin which I guess will take some time to do). Rolf Kalbermatter

1 0

Halflife II
by Roderick Colenbrander 18 Feb '05

18 Feb '05

Hi, The past few weeks I have been experimenting a bit with Wine's d3d9. After new updates appeared in cvs I tried games like halife2. Yesterday I tried (a cracked) halflife2 and cstrike:source again using Oliver's latest d3d9 patch and it now shows stuff! For shots check http://roderick.student.utwente.nl/hl2.png and http://roderick.student.utwente.nl/cstrike.png. Both games come to the menu screens I think (not sure what it all has to look like) but from then on not much happens. In case of halfife2 I see some birds flying on the background so the game isn't stuck. I think the menus aren't drawn and I guess that might be related to the fixme "d3d:IWineD3DDeviceImpl_SetSamplerState out of range sampler 0" which I'm seeing hundreds of times. Below is a small log of this: trace:d3d:IWineD3DDeviceImpl_SetSamplerState (0x403e08b0) Sampler(0), Type(7) Value(0) fixme:d3d:IWineD3DDeviceImpl_SetSamplerState out of range sampler 0 trace:d3d:IWineD3DDeviceImpl_SetSamplerState (0x403e08b0) Sampler(0), Type(8) Value(0) fixme:d3d:IWineD3DDeviceImpl_SetSamplerState out of range sampler 0 trace:d3d:IWineD3DDeviceImpl_SetSamplerState (0x403e08b0) Sampler(0), Type(9) Value(0) fixme:d3d:IWineD3DDeviceImpl_SetSamplerState out of range sampler 0 trace:d3d:IWineD3DDeviceImpl_SetSamplerState (0x403e08b0) Sampler(0), Type(10) Value(1) fixme:d3d:IWineD3DDeviceImpl_SetSamplerState out of range sampler 0 trace:d3d:IWineD3DDeviceImpl_SetSamplerState (0x403e08b0) Sampler(0), Type(11) Value(0) fixme:d3d:IWineD3DDeviceImpl_SetSamplerState out of range sampler 0 trace:d3d:IWineD3DDeviceImpl_SetSamplerState (0x403e08b0) Sampler(0), Type(12) Value(0) fixme:d3d:IWineD3DDeviceImpl_SetSamplerState out of range sampler 0 trace:d3d:IWineD3DDeviceImpl_SetSamplerState (0x403e08b0) Sampler(0), Type(13) Value(0) fixme:d3d:IWineD3DDeviceImpl_SetSamplerState out of range sampler 0 trace:d3d:IWineD3DDeviceImpl_SetSamplerState (0x403e08b0) Sampler(0), Type(14) Value(0) fixme:d3d:IWineD3DDeviceImpl_SetSamplerState out of range sampler 0 trace:d3d:IWineD3DDeviceImpl_SetSamplerState (0x403e08b0) Sampler(0), Type(15) Value(1) fixme:d3d:IWineD3DDeviceImpl_SetSamplerState out of range sampler 0 I'm amazed with the progress made on the d3d9 front. During the weekend I will try to get halflife2 working on windows to see what it has to look like and I might also have time to fix this problem if it is trivial. Just wanted to let you know that some major d3d9 game is now starting to work. Regards, Roderick

1 1

Re: [shell32tests/shelllink.c] Use aliases for ordinals (resend/rediff)
by Rolf Kalbermatter 18 Feb '05

18 Feb '05

Alexandre Julliard <julliard(a)winehq.org> wrote: >Hans Leidekker <hans(a)it.vu.nl> writes: > >> Filip's patch was not quite right, these functions need to be exported >> ordinal *only*, otherwise the resulting test binary won't link at >> runtime on systems older than xp. With the patch below I am able to >> produce binaries that run on xp as well as 2k and 98. > >And actually the same thing should be done in the Wine spec file (in fact most of >the shell32 functions should probably be marked noname). I think "most" is in this case quite overexagerating. There certainly are quite some functions which should be always imported by ordinal, as they were exported that way before they were documented by MS, but a lot of the rest of shell32 is simply exported by name only. Thinking a little about this I think exporting the ordinals by name too is not a problem at all, as long as the import libraries which get generated from the .spec file or .def file import all APIs with a defined ordinal through their ordinal instead. This way the DLLs are forgiving about someone trying to import by name and the newest Windows versions seem to allow linking to those functions by name too, but the import libraries will also work on older systems where the functions Are exported as ordinals only. This may require a modification to the import library generation to make sure that for defined ordinals the apropriate code to import that function by ordinal is Generated, instead of prefering import by name if both are present. Rolf Kalbermatter

2 1

dll/shell32/shlfileop.c cleanup questions
by Joris Huizer 18 Feb '05

18 Feb '05

Hello, I'm looking at the dll/shell32/shlfileop.c file; the function SHFileOperationW is still huge but in order to split off sections (some are clear to see but difficult to seperate from the rest) I'd either have to use huge parameter lists, or put parts together in structs (some vars are used everywhere in combination) What is your opinion about this? Also, I found something weird, the line at the top of the while loop: nFileOp.wFunc = ((level + 1) << 4) + FuncSwitch; seems to be equivalent to nFileOp.wFunc = (((lpFileOp->wFunc >> 4) + 1) << 4) + (lpFileOp->wFunc & FO_MASK); and nFileOp.wFunc = (((lpFileOp->wFunc >> 4) + 1) << 4) + (lpFileOp->wFunc & 0xF); and nFileOp.wFunc = (lpFileOp->wFunc & (~(0xF))) + (1 << 4) + (lpFileOp->wFunc & 0xF); and nFileOp.wFunc = (lpFileOp->wFunc & (~(0xF))) + (0x10) + (lpFileOp->wFunc & 0xF); and nFileOp.wFunc = lpFileOp->wFunc + 0x10; /* what's this 0x10? */ and in turn, no tests go off when changing that to: nFileOp.wFunc = lpFileOp->wFunc; Am I missing something here? regards, Joris

1 0

Grid And GetFocus()
by George Ginden 18 Feb '05

18 Feb '05

Hi, I've noticed, a wrong behavior in a simple program that has a grid implementation. Basically you can move around the grid with the direction keys. If you press enter, the cell lets you enter text. (just as excel works.). Also a mouse click on the cell does the same thing. The problem is that when you write something into the cell then you cannot move around the grid with the arrows anymore. (the GetFocus() function returns "nil" everytime you hit a arrow key...) To make the grid work again a mouse click out of the cell is necessary. I'd like to try and fix this, what have I to start with first ? Maybe it's the edit control ? PS: part of the strace log is attacched. trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event ButtonRelease for hwnd/window 0x3002e/3c00043, GetFocus()=0x20048 trace:event:EVENT_ProcessEvent returns. trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyPress for hwnd/window 0x3002e/3c00043, GetFocus()=0x20048 trace:event:EVENT_ProcessEvent returns. trace:win:WIN_CreateWindowEx (null) "EDIT" ex=00000000 style=50000000 122,136 55x12 parent=0x20048 menu=(nil) inst=0x400000 params=(nil) trace:win:dump_window_styles style: WS_CHILD WS_VISIBLE trace:win:dump_window_styles exstyle: trace:win:WIN_CreateWindowEx winproc type is 2 (WIN_PROC_32A) trace:win:WIN_SetWindowLong 0x30046 -12 0 3 trace:edit:EditWndProc_common hwnd=0x30046 msg=81 (WM_NCCREATE) wparam=0 lparam=4061eb3c trace:edit:EDIT_WM_NCCreate Creating ANSI edit control, style = 50000000 trace:win:WIN_SetWindowLong 0x30046 0 40378cf0 3 trace:edit:EditWndProc_common hwnd=0x30046 msg=83 (WM_NCCALCSIZE) wparam=0 lparam=4061e93c trace:edit:EditWndProc_common hwnd=0x30046 msg=83 (WM_NCCALCSIZE) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=1 (WM_CREATE) wparam=0 lparam=4061eb3c trace:edit:EDIT_WM_Create (null) trace:edit:EDIT_EM_SetMargins left=0, right=0 trace:edit:EDIT_SetCaretPos 0 - 0x0 trace:edit:EditWndProc_common hwnd=0x30046 msg=1 (WM_CREATE) -- 0x00000001 trace:edit:EditWndProc_common hwnd=0x30046 msg=5 (WM_SIZE) wparam=0 lparam=c0037 trace:edit:EDIT_WM_Size width = 55, height = 12 trace:edit:EDIT_SetCaretPos 0 - 0x0 trace:edit:EditWndProc_common hwnd=0x30046 msg=5 (WM_SIZE) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=3 (WM_MOVE) wparam=0 lparam=88007a trace:edit:EditWndProc_common hwnd=0x30046 msg=3 (WM_MOVE) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=18 (WM_SHOWWINDOW) wparam=1 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=18 (WM_SHOWWINDOW) -- 0x00000000 trace:win:SetWindowPos hwnd 0x30046, after (nil), 0,0 (0x0), flags 00000057 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOMOVE SWP_NOZORDER SWP_NOACTIVATE SWP_SHOWWINDOW trace:edit:EditWndProc_common hwnd=0x30046 msg=46 (WM_WINDOWPOSCHANGING) wparam=0 lparam=4061e8cc trace:edit:EditWndProc_common hwnd=0x30046 msg=46 (WM_WINDOWPOSCHANGING) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=47 (WM_WINDOWPOSCHANGED) wparam=0 lparam=4061e8cc trace:edit:EditWndProc_common hwnd=0x30046 msg=47 (WM_WINDOWPOSCHANGED) -- 0x00000000 trace:win:WIN_CreateWindowEx created window 0x30046 trace:win:WIN_SetWindowLong 0x30046 -4 6023f150 2 trace:win:WINPROC_AllocProc reusing 0x40720ac0 for 0x6023f150/2 trace:edit:EditWndProc_common hwnd=0x30046 msg=30 (WM_SETFONT) wparam=12be lparam=0 trace:edit:EDIT_EM_SetMargins left=1, right=1 trace:edit:EDIT_SetCaretPos 0 - 1x0 trace:edit:EditWndProc_common hwnd=0x30046 msg=30 (WM_SETFONT) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=d3 (EM_SETMARGINS) wparam=3 lparam=0 trace:edit:EDIT_EM_SetMargins left=0, right=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=d3 (EM_SETMARGINS) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=c (WM_SETTEXT) wparam=0 lparam=40364be0 trace:edit:EDIT_WM_SetText L"" trace:edit:EDIT_EM_ReplaceSel L"", can_undo 0, send_update 0 trace:edit:EDIT_WM_SetText notification EN_CHANGE sent to hwnd=0x20048 trace:edit:EDIT_WM_SetText notification EN_UPDATE sent to hwnd=0x20048 trace:edit:EditWndProc_common hwnd=0x30046 msg=c (WM_SETTEXT) -- 0x00000001 trace:win:RedrawWindow 0x30046 whole window flags: RDW_INVALIDATE RDW_ERASE trace:win:SetFocus 0x30046 prev 0x20048 trace:win:RedrawWindow 0x20048 rect (117,130)-(182,154) flags: RDW_INVALIDATE trace:win:SetFocus 0x30046 prev 0x30046 trace:edit:EditWndProc_common hwnd=0x30046 msg=b1 (EM_SETSEL) wparam=0 lparam=ffffffff trace:edit:EditWndProc_common hwnd=0x30046 msg=b1 (EM_SETSEL) -- 0x00000001 trace:edit:EditWndProc_common hwnd=0x30046 msg=7 (WM_SETFOCUS) wparam=20048 lparam=0 trace:edit:EDIT_SetCaretPos 0 - 1x0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EDIT_WM_SetFocus notification EN_SETFOCUS sent to hwnd=0x20048 trace:edit:EditWndProc_common hwnd=0x30046 msg=7 (WM_SETFOCUS) -- 0x00000000 trace:win:RedrawWindow 0x20048 rect (117,130)-(182,154) flags: RDW_INVALIDATE trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) wparam=46 lparam=210001 trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) -- 0x00000000 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyPress for hwnd/window 0x3002e/3c00043, GetFocus()=0x30046 trace:event:EVENT_ProcessEvent returns. trace:edit:EditWndProc_common hwnd=0x30046 msg=102 (WM_CHAR) wparam=66 lparam=210001 trace:edit:EDIT_EM_ReplaceSel L"f", can_undo 1, send_update 1 trace:edit:EDIT_EM_ReplaceSel inserting stuff (tl 0, strl 1, selstart 0 ('L""'), text 'L""') trace:edit:EDIT_UpdateText notification EN_UPDATE sent to hwnd=0x20048 trace:win:RedrawWindow 0x30046 whole window flags: RDW_INVALIDATE RDW_ERASE trace:edit:EDIT_SetCaretPos 1 - 4x0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EDIT_EM_ReplaceSel notification EN_CHANGE sent to hwnd=0x20048 trace:edit:EditWndProc_common hwnd=0x30046 msg=102 (WM_CHAR) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) wparam=44 lparam=200001 trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=102 (WM_CHAR) wparam=64 lparam=200001 trace:edit:EDIT_EM_ReplaceSel L"d", can_undo 1, send_update 1 trace:edit:EDIT_EM_ReplaceSel inserting stuff (tl 1, strl 1, selstart 1 ('L""'), text 'L"f"') trace:edit:EDIT_UpdateText notification EN_UPDATE sent to hwnd=0x20048 trace:win:RedrawWindow 0x30046 whole window flags: RDW_INVALIDATE RDW_ERASE trace:edit:EDIT_SetCaretPos 2 - 11x0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EDIT_EM_ReplaceSel notification EN_CHANGE sent to hwnd=0x20048 trace:edit:EditWndProc_common hwnd=0x30046 msg=102 (WM_CHAR) -- 0x00000000 trace:win:RedrawWindow 0x3002e whole window flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:win:BeginPaint hdc = 0x9e0 box = (129,149 - 184,161), fErase = 0 trace:win:RedrawWindow 0x30030 whole window flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:win:GetWindowRect hwnd 0x30030 (318,101)-(798,401) trace:win:BeginPaint hdc = 0x9e0 box = (129,149 - 184,161), fErase = 0 trace:win:RedrawWindow 0x20048 whole window flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:win:GetWindowRect hwnd 0x20048 (324,113)-(792,304) trace:win:BeginPaint hdc = 0x9e0 box = (117,130 - 182,154), fErase = 0 trace:win:RedrawWindow 0x30046 whole window flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:edit:EditWndProc_common hwnd=0x30046 msg=f (WM_PAINT) wparam=0 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=85 (WM_NCPAINT) wparam=1 lparam=0 trace:win:GetWindowRect hwnd 0x30046 (447,250)-(502,262) trace:edit:EditWndProc_common hwnd=0x30046 msg=85 (WM_NCPAINT) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=14 (WM_ERASEBKGND) wparam=74 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=14 (WM_ERASEBKGND) -- 0xffffffff trace:win:BeginPaint hdc = 0x74 box = (0,0 - 55,12), fErase = 0 trace:edit:EDIT_PaintLine line=0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EditWndProc_common hwnd=0x30046 msg=f (WM_PAINT) -- 0x00000000 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyPress for hwnd/window 0x3002e/3c00043, GetFocus()=0x30046 trace:event:EVENT_ProcessEvent returns. trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) wparam=47 lparam=220001 trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=102 (WM_CHAR) wparam=67 lparam=220001 trace:edit:EDIT_EM_ReplaceSel L"g", can_undo 1, send_update 1 trace:edit:EDIT_EM_ReplaceSel inserting stuff (tl 2, strl 1, selstart 2 ('L""'), text 'L"fd"') trace:edit:EDIT_UpdateText notification EN_UPDATE sent to hwnd=0x20048 trace:win:RedrawWindow 0x30046 whole window flags: RDW_INVALIDATE RDW_ERASE trace:edit:EDIT_SetCaretPos 3 - 18x0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EDIT_EM_ReplaceSel notification EN_CHANGE sent to hwnd=0x20048 trace:edit:EditWndProc_common hwnd=0x30046 msg=102 (WM_CHAR) -- 0x00000000 trace:win:RedrawWindow 0x30046 whole window flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:edit:EditWndProc_common hwnd=0x30046 msg=f (WM_PAINT) wparam=0 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=14 (WM_ERASEBKGND) wparam=9e0 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=14 (WM_ERASEBKGND) -- 0xffffffff trace:win:BeginPaint hdc = 0x9e0 box = (0,0 - 55,12), fErase = 0 trace:edit:EDIT_PaintLine line=0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EditWndProc_common hwnd=0x30046 msg=f (WM_PAINT) -- 0x00000000 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyRelease for hwnd/window 0x3002e/3c00043, GetFocus()=0x30046 trace:event:EVENT_ProcessEvent returns. trace:edit:EditWndProc_common hwnd=0x30046 msg=101 (WM_KEYUP) wparam=46 lparam=c0210001 trace:edit:EditWndProc_common hwnd=0x30046 msg=101 (WM_KEYUP) -- 0x00000000 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyRelease for hwnd/window 0x3002e/3c00043, GetFocus()=0x30046 trace:event:EVENT_ProcessEvent returns. trace:edit:EditWndProc_common hwnd=0x30046 msg=101 (WM_KEYUP) wparam=44 lparam=c0200001 trace:edit:EditWndProc_common hwnd=0x30046 msg=101 (WM_KEYUP) -- 0x00000000 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyRelease for hwnd/window 0x3002e/3c00043, GetFocus()=0x30046 trace:event:EVENT_ProcessEvent returns. trace:edit:EditWndProc_common hwnd=0x30046 msg=101 (WM_KEYUP) wparam=47 lparam=c0220001 trace:edit:EditWndProc_common hwnd=0x30046 msg=101 (WM_KEYUP) -- 0x00000000 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyPress for hwnd/window 0x3002e/3c00043, GetFocus()=0x30046 trace:event:EVENT_ProcessEvent returns. trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) wparam=44 lparam=200001 trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=102 (WM_CHAR) wparam=64 lparam=200001 trace:edit:EDIT_EM_ReplaceSel L"d", can_undo 1, send_update 1 trace:edit:EDIT_EM_ReplaceSel inserting stuff (tl 3, strl 1, selstart 3 ('L""'), text 'L"fdg"') trace:edit:EDIT_UpdateText notification EN_UPDATE sent to hwnd=0x20048 trace:win:RedrawWindow 0x30046 whole window flags: RDW_INVALIDATE RDW_ERASE trace:edit:EDIT_SetCaretPos 4 - 25x0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EDIT_EM_ReplaceSel notification EN_CHANGE sent to hwnd=0x20048 trace:edit:EditWndProc_common hwnd=0x30046 msg=102 (WM_CHAR) -- 0x00000000 trace:win:RedrawWindow 0x30046 whole window flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:edit:EditWndProc_common hwnd=0x30046 msg=f (WM_PAINT) wparam=0 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=14 (WM_ERASEBKGND) wparam=74 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=14 (WM_ERASEBKGND) -- 0xffffffff trace:win:BeginPaint hdc = 0x74 box = (0,0 - 55,12), fErase = 0 trace:edit:EDIT_PaintLine line=0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EditWndProc_common hwnd=0x30046 msg=f (WM_PAINT) -- 0x00000000 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyPress for hwnd/window 0x3002e/3c00043, GetFocus()=0x30046 trace:event:EVENT_ProcessEvent returns. trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) wparam=46 lparam=210001 trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=102 (WM_CHAR) wparam=66 lparam=210001 trace:edit:EDIT_EM_ReplaceSel L"f", can_undo 1, send_update 1 trace:edit:EDIT_EM_ReplaceSel inserting stuff (tl 4, strl 1, selstart 4 ('L""'), text 'L"fdgd"') trace:edit:EDIT_UpdateText notification EN_UPDATE sent to hwnd=0x20048 trace:win:RedrawWindow 0x30046 whole window flags: RDW_INVALIDATE RDW_ERASE trace:edit:EDIT_SetCaretPos 5 - 28x0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EDIT_EM_ReplaceSel notification EN_CHANGE sent to hwnd=0x20048 trace:edit:EditWndProc_common hwnd=0x30046 msg=102 (WM_CHAR) -- 0x00000000 trace:win:RedrawWindow 0x30046 whole window flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:edit:EditWndProc_common hwnd=0x30046 msg=f (WM_PAINT) wparam=0 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=14 (WM_ERASEBKGND) wparam=9e0 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=14 (WM_ERASEBKGND) -- 0xffffffff trace:win:BeginPaint hdc = 0x9e0 box = (0,0 - 55,12), fErase = 0 trace:edit:EDIT_PaintLine line=0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EditWndProc_common hwnd=0x30046 msg=f (WM_PAINT) -- 0x00000000 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyPress for hwnd/window 0x3002e/3c00043, GetFocus()=0x30046 trace:event:EVENT_ProcessEvent returns. trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) wparam=47 lparam=220001 trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=102 (WM_CHAR) wparam=67 lparam=220001 trace:edit:EDIT_EM_ReplaceSel L"g", can_undo 1, send_update 1 trace:edit:EDIT_EM_ReplaceSel inserting stuff (tl 5, strl 1, selstart 5 ('L""'), text 'L"fdgdf"') trace:edit:EDIT_UpdateText notification EN_UPDATE sent to hwnd=0x20048 trace:win:RedrawWindow 0x30046 whole window flags: RDW_INVALIDATE RDW_ERASE trace:edit:EDIT_SetCaretPos 6 - 35x0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EDIT_EM_ReplaceSel notification EN_CHANGE sent to hwnd=0x20048 trace:edit:EditWndProc_common hwnd=0x30046 msg=102 (WM_CHAR) -- 0x00000000 trace:win:RedrawWindow 0x30046 whole window flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:edit:EditWndProc_common hwnd=0x30046 msg=f (WM_PAINT) wparam=0 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=14 (WM_ERASEBKGND) wparam=74 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=14 (WM_ERASEBKGND) -- 0xffffffff trace:win:BeginPaint hdc = 0x74 box = (0,0 - 55,12), fErase = 0 trace:edit:EDIT_PaintLine line=0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EditWndProc_common hwnd=0x30046 msg=f (WM_PAINT) -- 0x00000000 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyRelease for hwnd/window 0x3002e/3c00043, GetFocus()=0x30046 trace:event:EVENT_ProcessEvent returns. trace:edit:EditWndProc_common hwnd=0x30046 msg=101 (WM_KEYUP) wparam=46 lparam=c0210001 trace:edit:EditWndProc_common hwnd=0x30046 msg=101 (WM_KEYUP) -- 0x00000000 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyRelease for hwnd/window 0x3002e/3c00043, GetFocus()=0x30046 trace:event:EVENT_ProcessEvent returns. trace:edit:EditWndProc_common hwnd=0x30046 msg=101 (WM_KEYUP) wparam=44 lparam=c0200001 trace:edit:EditWndProc_common hwnd=0x30046 msg=101 (WM_KEYUP) -- 0x00000000 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyRelease for hwnd/window 0x3002e/3c00043, GetFocus()=0x30046 trace:event:EVENT_ProcessEvent returns. trace:edit:EditWndProc_common hwnd=0x30046 msg=101 (WM_KEYUP) wparam=47 lparam=c0220001 trace:edit:EditWndProc_common hwnd=0x30046 msg=101 (WM_KEYUP) -- 0x00000000 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyPress for hwnd/window 0x3002e/3c00043, GetFocus()=0x30046 trace:event:EVENT_ProcessEvent returns. trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) wparam=d lparam=1c0001 trace:edit:EditWndProc_common hwnd=0x30046 msg=100 (WM_KEYDOWN) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=d (WM_GETTEXT) wparam=800 lparam=40364be0 trace:edit:EditWndProc_common hwnd=0x30046 msg=d (WM_GETTEXT) -- 0x00000006 trace:win:DestroyWindow (0x30046) trace:edit:EditWndProc_common hwnd=0x30046 msg=18 (WM_SHOWWINDOW) wparam=0 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=18 (WM_SHOWWINDOW) -- 0x00000000 trace:win:SetWindowPos hwnd 0x30046, after (nil), 0,0 (0x0), flags 00000097 trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOMOVE SWP_NOZORDER SWP_NOACTIVATE SWP_HIDEWINDOW trace:edit:EditWndProc_common hwnd=0x30046 msg=46 (WM_WINDOWPOSCHANGING) wparam=0 lparam=4061ec18 trace:edit:EditWndProc_common hwnd=0x30046 msg=46 (WM_WINDOWPOSCHANGING) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=47 (WM_WINDOWPOSCHANGED) wparam=0 lparam=4061ec18 trace:edit:EditWndProc_common hwnd=0x30046 msg=47 (WM_WINDOWPOSCHANGED) -- 0x00000000 trace:win:SetFocus 0x20048 prev 0x30046 trace:edit:EditWndProc_common hwnd=0x30046 msg=8 (WM_KILLFOCUS) wparam=20048 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=8 (WM_KILLFOCUS) -- 0x00000000 trace:win:RedrawWindow 0x20048 rect (117,130)-(182,154) flags: RDW_INVALIDATE trace:win:SetFocus 0x30046 prev 0x20048 trace:win:RedrawWindow 0x20048 rect (117,130)-(182,154) flags: RDW_INVALIDATE trace:win:SetFocus 0x30046 prev 0x30046 trace:edit:EditWndProc_common hwnd=0x30046 msg=b1 (EM_SETSEL) wparam=0 lparam=ffffffff trace:edit:EDIT_SetCaretPos 6 - 35x0 trace:edit:EditWndProc_common hwnd=0x30046 msg=b1 (EM_SETSEL) -- 0x00000001 trace:edit:EditWndProc_common hwnd=0x30046 msg=7 (WM_SETFOCUS) wparam=20048 lparam=0 trace:edit:EDIT_SetCaretPos 6 - 35x0 trace:win:WINPROC_AllocProc reusing 0x40720aac for 0x406959e8/2 trace:edit:EDIT_WM_SetFocus notification EN_SETFOCUS sent to hwnd=0x20048 trace:edit:EditWndProc_common hwnd=0x30046 msg=7 (WM_SETFOCUS) -- 0x00000000 trace:edit:EditWndProc_common hwnd=0x30046 msg=2 (WM_DESTROY) wparam=0 lparam=0 trace:win:WIN_DestroyWindow 0x30046 trace:edit:EditWndProc_common hwnd=0x30046 msg=82 (WM_NCDESTROY) wparam=0 lparam=0 trace:edit:EditWndProc_common hwnd=0x30046 msg=82 (WM_NCDESTROY) -- 0x00000000 trace:win:RedrawWindow 0x20048 rect (117,130)-(182,154) flags: RDW_INVALIDATE trace:win:RedrawWindow 0x3002e whole window flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:win:BeginPaint hdc = 0x74 box = (129,149 - 184,161), fErase = 0 trace:win:RedrawWindow 0x30030 whole window flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:win:GetWindowRect hwnd 0x30030 (318,101)-(798,401) trace:win:BeginPaint hdc = 0x74 box = (129,149 - 184,161), fErase = 0 trace:win:RedrawWindow 0x20048 whole window flags: RDW_NOINTERNALPAINT RDW_NOCHILDREN trace:win:GetWindowRect hwnd 0x20048 (324,113)-(792,304) trace:win:BeginPaint hdc = 0x74 box = (117,130 - 182,154), fErase = 0 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyRelease for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyPress for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyRelease for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyPress for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyRelease for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyPress for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event KeyRelease for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event MotionNotify for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:win:GetWindowRect hwnd 0x20048 (324,113)-(792,304) trace:win:WINPOS_WindowFromPoint scope 0x3002e (463,246) returning 0x20048 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event MotionNotify for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:win:GetWindowRect hwnd 0x20048 (324,113)-(792,304) trace:win:WINPOS_WindowFromPoint scope 0x3002e (469,226) returning 0x20048 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event MotionNotify for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:win:GetWindowRect hwnd 0x20048 (324,113)-(792,304) trace:win:WINPOS_WindowFromPoint scope 0x3002e (473,198) returning 0x20048 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event MotionNotify for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:win:GetWindowRect hwnd 0x20048 (324,113)-(792,304) trace:win:WINPOS_WindowFromPoint scope 0x3002e (475,168) returning 0x20048 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event MotionNotify for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:win:GetWindowRect hwnd 0x20048 (324,113)-(792,304) trace:win:WINPOS_WindowFromPoint scope 0x3002e (473,136) returning 0x20048 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event MotionNotify for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_ProcessEvent returns. trace:win:GetWindowRect hwnd 0x30030 (318,101)-(798,401) trace:win:WINPOS_WindowFromPoint scope 0x3002e (471,102) returning 0x30030 trace:event:EVENT_ProcessEvent called. trace:event:EVENT_ProcessEvent Got event FocusOut for hwnd/window 0x3002e/3c00043, GetFocus()=(nil) trace:event:EVENT_FocusOut win 0x3002e xwin 3c00043 detail=NotifyNonlinear trace:event:EVENT_FocusOut lost focus, setting fg to 0 trace:win:SetForegroundWindow (nil) trace:event:EVENT_ProcessEvent returns.

1 0

LPRECT parameters for Main_DirectDrawSurface_Lock
by Andreas Eckstein 18 Feb '05

18 Feb '05

Good morning, wine devs! When playing Icewind Dale II (using wine-20050111), the game sometimes crashed with these messages: trace:ddraw:Main_DirectDrawSurface_Lock lprect: 0x0-0x0 err:ddraw:Main_DirectDrawSurface_Lock Invalid values in LPRECT !!! or, on another occasion: trace:ddraw:Main_DirectDrawSurface_Lock lprect: 0x0-2x0 err:ddraw:Main_DirectDrawSurface_Lock Invalid values in LPRECT !!! As you notice, the game tries to lock a surface with width and/or height equal to zero. Frankly I have no idea what the expected behavior is in this case, however playing the critical passages on Windows worked without crash. A quick patch to let Main_DirectDrawSurface_Lock not choke on zero-width or -height LPRECTs solved the problem with wine. Since I don't plan to dig into wine hacking any time soon, could someone merge it into cvs for me (if the new behavior of the function is acceptable, that is)? Thanks in advance! Andreas Eckstein --- The patch: --- dlls/ddraw/dsurface/main.c 2005-01-09 18:35:44.000000000 +0100 +++ dlls/ddraw/dsurface/main.c 2005-02-14 21:03:36.511738080 +0100 @@ -1111,8 +1111,8 @@ (prect->left < 0) || (prect->bottom < 0) || (prect->right < 0) || - (prect->left >= prect->right) || - (prect->top >= prect->bottom) || + (prect->left > prect->right) || + (prect->top > prect->bottom) || (prect->left >= This->surface_desc.dwWidth) || (prect->right > This->surface_desc.dwWidth) || (prect->top >= This->surface_desc.dwHeight) ||

2 1

Re: advapi32: Add RegOpen/CloseKey test and fixes
by Alexandre Julliard 18 Feb '05

18 Feb '05

James Hawkins <truiken(a)gmail.com> writes: > + ret = RegOpenKeyA(HKEY_CURRENT_USER, "Software\\Wine\\Test", &hkHandle); > + hkPreserve = hkHandle; > + ret = RegCloseKey(hkHandle); > + ok(ret == ERROR_SUCCESS, "expected ERROR_SUCCESS, got %ld\n", ret); > + ok(hkHandle == hkPreserve, "expected hkHandle != hkPreserve\n"); This test is meaningless, since the handle is passed by value to RegCloseKey it cannot possibly be modified. -- Alexandre Julliard julliard(a)winehq.org

1 0

WINE on x86-64 Fedora Core 4 Prerelease Kernels (2.6.10) [Workaround]
by Erich Hoover 18 Feb '05

18 Feb '05

Haven't been able to use WINE for quite a while and have been getting the error: err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0xffffe403 So I finally found a workaround, hopefully it can help someone else: LD_ASSUME_KERNEL=2.4 setarch i386 -X wine <program>

1 0

Re: advapi32: Add RegOpen/CloseKey test and fixes
by Dmitry Timoshkov 18 Feb '05

18 Feb '05

"James Hawkins" <truiken(a)gmail.com> wrote: > + static const WCHAR emptyW[] = {0}; > + > + if (!name || !strcmpW(name, emptyW)) { > + *retkey = hkey; > + return ERROR_SUCCESS; > + } > + if (!name || !strcmp(name, "")) { > + *retkey = hkey; > + return ERROR_SUCCESS; > + } Instead of introducing emptyW and calling strcmp[W] with an empty string it's much simpler and more readable to use in both cases: if (!name || !*name) { *retkey = hkey; return ERROR_SUCCESS; } -- Dmitry.

1 0

Re: OLEAUT32: Implementation of OleFontImpl_QueryTextMetrics
by Dmitry Timoshkov 18 Feb '05

18 Feb '05

"Alex Villacis Lasso" <a_villacis(a)palosanto.com> wrote: > --- wine-20050211/dlls/oleaut32/olefont.c 2005-01-31 06:34:10.000000000 -0500 > +++ wine-20050211-patch/dlls/oleaut32/olefont.c 2005-02-16 22:56:18.865553128 -0500 > @@ -1068,8 +1068,16 @@ > IFont* iface, > TEXTMETRICOLE* ptm) > { > - FIXME("(%p, %p), stub!\n",iface,ptm); > - return E_NOTIMPL; > + HDC hdcRef; > + HFONT hOldFont, hNewFont; I's suggest to replace a FIXME with a TRACE, not remove it altogether. More logging never hurts. -- Dmitry.

1 0

Winelib and SCons
by Scott Ritchie 18 Feb '05

18 Feb '05

Ok, to be up front and honest I haven't used SCons at all yet, but if it really is an honest to god replacement for autoconf, make, and friends then I'm really excited. Why? Because this has some serious importance for Winelib. Currently, in order to port a program to Linux via Winelib, a developer needs to first make it work in MinGW (a nontrivial amount to do if you use Visual Studio). Then, the developer needs to run some Wine scripts on it to make the code compatible with GCC on Linux - this isn't so hard, and mostly involves things like switching out backslashes for forward ones. Then, the developer needs to write his own makefiles and hammer autoconf and stuff into working right. This is the hard part, and it's where I gave up when trying to port Miranda Instant Messenger with Winelib even though it worked in MinGW. There are many other open source Windows apps out there that I'd like to try porting (say, eMule), but they're currently all written in Visual Studio and getting Visual Studio support into Winelib has been on our perpetual todo list for some years now. SCons might change that. If it really does work with Visual Studio files, we could rip out the Winelib makefile stuff and replace it with SCons. What do you think? Are the SCons developers interested in helping us do this? Do any of you use Wine yourselves? Thanks, Scott Ritchie Wine guy

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel