- Wine-Devel - list.winehq.org

netapi32 tests fail then crash
by Sylvain Petreolle Nov. 11, 2002

Nov. 11, 2002

../../../tools/runtest -q -P wine -M netapi32.dll -T ../../.. -p netapi32_test.exe.so access.c && touch access.ok err:win32:PE_fixup_imports No implementation for advapi32.dll.151(LsaClose) imported from C:\WINDOWS\SYSTEM\netapi32. dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for advapi32.dll.160(LsaFreeMemory) imported from C:\WINDOWS\SYSTEM\neta pi32.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for advapi32.dll.167(LsaNtStatusToWinError) imported from C:\WINDOWS\SYS TEM\netapi32.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for advapi32.dll.169(LsaOpenPolicy) imported from C:\WINDOWS\SYSTEM\neta pi32.dll, setting to 0xdeadbeef err:win32:PE_fixup_imports No implementation for advapi32.dll.173(LsaQueryInformationPolicy) imported from C:\WINDOWS \SYSTEM\netapi32.dll, setting to 0xdeadbeef access.c:48: Test failed: User Name Retrieved err:netapi32:NetUserGetInfo Invalid level 10000 is specified fixme:netapi32:NetUserGetInfo Can't find information for user L"Nonexistent User" fixme:netapi32:NetUserGetInfo Action Implemented for local computer only. Requested for server L"\\\\Ba path" fixme:netapi32:NetQueryDisplayInformation Level 1 partially implemented access.c:118: Test failed: Information Retrieved wine: Unhandled exception, starting debugger... WineDbg starting on pid 8071e30 No debug information in ELF '/home/wine/miscemu/wine' (0x00000000) Breakpoint 1 at 0x4000acb0 Loaded debug information from ELF '/home/wine/dlls/libntdll.dll.so' (0x40013000) No debug information in ELF '/home/wine/library/libwine.so' (0x40111000) No debug information in ELF '/home/wine/unicode/libwine_unicode.so' (0x40128000) No debug information in ELF '/lib/i686/libm.so.6' (0x4021d000) No debug information in ELF '/lib/libdl.so.2' (0x4023f000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) No debug information in ELF '/lib/libnss_files.so.2' (0x40243000) No debug information in ELF '/home/wine/dlls/netapi32/tests/netapi32_test.exe.so' (0x40594000) No debug information in ELF '/home/wine/dlls/netapi32.dll.so' (0x407d3000) No debug information in ELF '/home/wine/dlls/kernel32.dll.so' (0x407f8000) No debug information in 32bit DLL 'W:\dlls\netapi32\tests\netapi32_test.exe' (0x405a0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40050000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x40830000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0xbfed0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NETAPI32.DLL' (0x407e0000) Unhandled exception: page fault on read access to 0x006f0074 in 32-bit code (0x40840eb4). In 32-bit mode. 0x40840eb4 (KERNEL32.DLL.lstrcmpW+0x30 in kernel32.dll.so): movw 0x0(%esi),%ax Wine-dbg>bt Backtrace: =>0 0x40840eb4 (KERNEL32.DLL.lstrcmpW+0x30 in kernel32.dll.so) (ebp=407c2e18) 1 0x405a7511 (netapi32_test.exe.EntryPoint+0x511 in netapi32_test.exe.so) (ebp=407c2e58) 2 0x405a7653 (netapi32_test.exe.EntryPoint+0x653 in netapi32_test.exe.so) (ebp=407c2e64) 3 0x405a8142 (netapi32_test.exe.EntryPoint+0x1142 in netapi32_test.exe.so) (ebp=407c2e78) 4 0x405a7038 (netapi32_test.exe.EntryPoint+0x38 in netapi32_test.exe.so) (ebp=407c2e8c) 5 0x400b45ec (start_process+0x238 [process.c] in libntdll.dll.so) (ebp=407c2f30) 6 0x400b8565 (call_on_thread_stack+0x79 [sysdeps.c] in libntdll.dll.so) (ebp=407c2ff4) 7 0x400b86a0 (SYSDEPS_CallOnStack+0x14 in libntdll.dll.so) (ebp=00000000) Wine-dbg>info stack Stack dump: 0x407c2e08 (netapi32_test.exe.EntryPoint+0x21be08): ffffffba 405a9374 40251bd0 405a85a4 0x407c2e18 (netapi32_test.exe.EntryPoint+0x21be18): 407c2e58 405a7511 006f0074 405a8520 0x407c2e28 (netapi32_test.exe.EntryPoint+0x21be28): 407c2e48 407c2e44 405a8659 00000000 0x407c2e38 (netapi32_test.exe.EntryPoint+0x21be38): 00000000 00610072 00000005 00000002 0x407c2e48 (netapi32_test.exe.EntryPoint+0x21be48): 40251bb8 405a9374 405a9260 bffff9ec 0x407c2e58 (netapi32_test.exe.EntryPoint+0x21be58): 407c2e64 405a7653 405a9374 407c2e78 0x407c2e68 (netapi32_test.exe.EntryPoint+0x21be68): ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: PATCH: cups dynamical dependency
by Dimitrie O. Paun Nov. 11, 2002

Nov. 11, 2002

On November 10, 2002 02:40 pm, Marcus Meissner wrote: > Do not link against -lcups directly, but dynamically load it > if present. (just like freetype etc.) [...] > +#ifdef HAVE_CUPS > + /* dynamically load CUPS if not yet loaded */ > + if (!cupshandle) { > + cupshandle = wine_dlopen(CUPS_SONAME, RTLD_NOW, NULL, 0); > + if (!cupshandle) cupshandle = (void*)-1; > + } > +#endif Well, if we do this dynamically, why have this HAVE_CUPS check which is a compile time check? IMO we should just include a copy of the CUPS headers that we need, and drop the compile time check altogether. In fact, this check is misleading, as it suggests that we've verified some sort of compatibility with CUPS which we haven't. We _assume_ that a certain API is available at runtime, so why pretend we use something that's on the machine we compile on? -- Dimi.

5 5

Re: Wine 0.8: VB compatibility !!
by Ann and Jason Edmeades Nov. 11, 2002

Nov. 11, 2002

I have a VB prog (see www.badcomp.co.uk) which I spent a long time getting working under Wine and fixed all the oleaut32 Var* routines it used. However if you look at that dll, there are still a huge number of stubs. Additionally the date/time handling is (was, anyway) pretty useless. I would strongly recommend if anyone starts writing VB testcases they try and exercise the Variant cases as well as the standard types (...and no, I dont have time!) VB Window Icons dont work in the wine tree - Marcus sent me a fix for OleLoadPictureEx which solves the problem but he never submitted it to the wine tree (I have a copy, but not of the license it was under). Also, Icons containing transparency dont work for me either, but thats not a vb thing, I guess. I never got printing working (wine and cups doesnt seem to handle hplj's very well - I've seen a lot of problem reports about that) but aside from that, the functionality worked fine as far as I could test. If I ever get motivated I'll try to test the printing as there is a huge amount of code I wrote to do a print preview, and that will probably highlight more var fn's missing. Regards, Jason

2 1

Re: Huge speedup to wine ReadFile on small packets
by Hannu Kotipalo Nov. 11, 2002

Nov. 11, 2002

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tony Lambregts kirjoitti Maanantai 11. Marraskuuta 2002 07:58: > > > >On Maanantai 11. Marraskuuta 2002 00:49, you wrote : > >>Well I tried it out with a couple of programs. Things seemed ok with > >>small files but when I tried to run SimCity 3000 (just one of my test > >>programs) It freezes up when loading a city (not a crash). I will try > >>to see why when I get a chance. > > > >I think that the size shouldn't be a problem; wzebra reads out a 17 Mb > > file... The problem might be that there is only one buffer. If the > > program reads two files in turns, my code switches the buffer for every > > read. This is actually slower than without. Maybe it is not freezed, > > maybe it is just too slow? Another problem might be the buffer switching > > code. > > Well from what I can see it is opening a lot of little files along with > the big file so it is slowed down to a crawl not frozen. and with trace > on... I think you need more than one than one buffer perhaps. One per > file of course. Havent looked that close... I'll make a version with more, but smaller buffers. I found one bug also; on certain case, a closed file's buffer might has been used for the next opened file with same HANDLE. Where is CLOSEFILE code?! Shouldn't it be on file.c? I need to find it to invalidate the buffer at correct place! I think that the original problem is that wine opens and closes unix file for every ReadFile. This will propably flush all linux own buffers and linux filesystem has to read the same data over and over again (when application calls ReadFile with small buffers, of course). Opened unix files should be kept open as long as corresponding WINAPI files are open. BTW. I'm using totally non-MS system. Is there any problem with MS dll's? Hannu ps. Could you PLEASE add following line to the mailing list archive configuration file: - ------------------ spamprotect = 1 - --------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE90A0BuA3ghgc3fUsRAkh1AJ9yZG8l0x7dj81+X+uIiLgJ4xlJXwCfbpEg qW4bHrv1pJ4aFVPvoHA34+k= =1L9Q -----END PGP SIGNATURE-----

1 0

New email addy
by Dustin Navea Nov. 11, 2002

Nov. 11, 2002

Just so everyone knows, since I have Outlook (and Evolution) support with my ISP's email now, I have switched over to it for my list needs. Any emails to me should be directed here, I have updated my accounts with the winehq server. I will still accept emails over at yahoo if need be but the majority should go here... -Dustin

1 0

Re: GetCurrentObject
by steve.lustbader＠philips.com Nov. 11, 2002

Nov. 11, 2002

>On Fri, 8 Nov 2002 17:56:05 -0500, you wrote: > >> GetCurrentObject returns 0, but as far as it knows, it is >> returning successfully. This is because in the line >> >> case OBJ_BITMAP: ret = dc->hBitmap; break; >> >> dc->hBitmap is 0, although dc is a valid DC. The HDC that is passed >> to GetCurrentObject to get dc is obtained by calling >> CWindow::BegingPaint(PAINTSTRUCT *) from a class derived from ATL's >> CWindow. I'm guessing that this is where the problem is probably >> coming from - the app is written in C++ with ATL. >> >> -Steve > >Here a patch that is lying around here for quite a while that I use to >prevent an Eudora 4/5 crash with the same symptoms. I wonder if it >helps you. > >And yes, GetCurrentObject(..,OBJ_BITMAP) on a freshly created dc >returns != 0 in windows. I'm just not sure this patch is the real >solution, although I haven't seen any negative effects. > >Rein. >-- >Rein Klazes >rklazes(a)xs4all.nl This patch did solve the problem for me. Maybe you should submit it to wine-patches, or at least submit it to wine-devel offically for comments. -Steve

1 0

controls/edit.c not so clean - help please
by Carl Sopchak Nov. 11, 2002

Nov. 11, 2002

The following code is in the EDIT_MakeFit() function: if ((es->buffer_limit > 0) && (size > es->buffer_limit)) { EDIT_NOTIFY_PARENT(es, EN_MAXTEXT, "EN_MAXTEXT"); return FALSE; } if ((es->buffer_limit > 0) && (size > es->buffer_limit)) size = es->buffer_limit; Obviously, the second IF condition is never true, since it's the same as the prior IF, which does a 'return FALSE'. EDIT_MakeFit() is ONLY called by EDIT_EM_ReplaceSel(), so it sppears that the second IF is attempting to limit the amount of text that is replaced to the buffer_limit. Obviously, the first IF just notifies the parent that the limit would be exceeded, then returns without modifying the edit control. Although EDIT_MakeFit() is only called from one place, EDIT_EM_ReplaceSel() is called all over the place, enumerated below. Can anyone tell me if any of these invocations should (a) fail without replacing, (b) replace the limited amount of text, or (c) ignore the limit? EDIT_WM_Clear() - Processes WM_CLEAR message - I assume it's moot here... Processing of EM_REPLACESEL message. See note below... EDIT_EM_Undo() - Processes EM_UNDO and WM_UNDO messages EDIT_WM_Char() - Process WM_CHAR message EDIT_WM_Create() - Processes WM_CREATE message - I assume it's moot here... EDIT_WM_Paste - Process WM_PASTE message EDIT_WM_SetText - Process WM_SETTEXT message. See note below... Note: Under the message EM_LIMITTEXT, MSDN states that WM_SETTEXT will not adhear to the limit, but doesn't mention any other text modification messages. The man pages for the other messages do not mention how it's action is effected by the limit. MSDN does state "The EM_LIMITTEXT message limits only the text the user can enter." Unfortunately, I don't have a MS Windows box readily available to test some of these things out on... - - - - - - - - - Another question about this code from controls/edit.c/EDIT_WM_Char(): /* Protect read-only edit control from modification */ if(es->style & ES_READONLY) return; /* BECAUSE OF THIS... */ control = GetKeyState(VK_CONTROL) & 0x8000; switch (c) { case '\r': /* If the edit doesn't want the return and it's not a multiline edit, do nothing */ if(!(es->style & ES_MULTILINE) && !(es->style & ES_WANTRETURN)) break; case '\n': if (es->style & ES_MULTILINE) { if (es->style & ES_READONLY) { /* ... WE NEVER GET HERE! */ EDIT_MoveHome(es, FALSE); EDIT_MoveDown_ML(es, FALSE); } else { static const WCHAR cr_lfW[] = {'\r','\n',0}; EDIT_EM_ReplaceSel(es, TRUE, cr_lfW, TRUE, TRUE); } } break; The place that I marked "/* BECAUSE OF THIS... */" means that the code marked by "/* ... WE NEVER GET HERE! */" will never get executed. My question: In a read only multiline edit control, should a newline move the cursor to the beginning of the next line of text in the control? (I could make this change, but don't have any way of testing it...) - - - - - Thanks for the help, Carl

3 3

Help support
by Dimitrie O. Paun Nov. 11, 2002

Nov. 11, 2002

Another on for the 0.9 TODO: -- launching Help from apps This does not work now, IIRC. It's rather 'simple', and visible from the user POV, so needs fixing IMO. -- Dimi.

9 24

Quicken 2000 / edit.c MakeFit() bug...
by Carl Sopchak Nov. 11, 2002

Nov. 11, 2002

I'm having the following problem with Quicken 2000 Deluxe under wine (CVS as of Thursday morning [and all prior versions]): When I open an investment account, then click on the security name in an existing transaction, and that security name is fairly long (say, 20+ characters), the name gets replaced by the trandaction date! This does not happen with MS Windows. (Before I go any farther, I must say that I know virtually NOTHING about windows programming, and only a small bit more about Wine coding and debugging...) After spending two days drudging through --debugmsg +all logs, I think I have a pretty good idea what's happening. It appears that Quicken uses a single Edit Control for all of it's input fields. When the account is opened, the initial editable field is the date of a new transaction. Quicken sets the maximum input length (with EM_LIMITTEXT) to 10. (Makes sense for a date...) This sets buffer_limit in it's EDITSTATE to 10. Now, when you then go and click on the security name in that existing transaction, Quicken uses WM_SETTEXT to set it's value. Under Wine, this fails, because the size of the string is greater than es->buffer_limit (checked near the top of EDIT_MakeFit() in controls/edit.c). Now, EDIT_MakeFit() does notify Quicken with EN_MAXTEXT, but Quicken doesn't seem to respond in any sensible manner (like getting a bigger control and trying again). (I have not followed this path past this point, but I know that the security name gets wiped out...) Quicken will, AFTER issuing the SETTEXT, try to re-size the field with EM_LIMITTEXT to 30, a security name length. I quote from MSDN (EM_LIMITTEXT Message Remarks section): "The EM_LIMITTEXT message limits only the text the user can enter. It does not affect any text already in the edit control when the message is sent, nor does it affect the length of the text copied to the edit control by the WM_SETTEXT message. If an application uses the WM_SETTEXT message to place more text into an edit control than is specified in the EM_LIMITTEXT message, the user can edit the entire contents of the edit control. " So, according to MSDN, the WM_SETTEXT should successfully set the text to the full length, regardless of the value of buffer_limit. I am in the process of making this change and testing it. I guess my main concern at this point is, "Are there any other ramifications to making this change that I should be concerned about?" If anyone wants to point me in a direction here, I'll follow through... Carl

1 0

Re: Help support
by Mike Hearn Nov. 11, 2002

Nov. 11, 2002

Well, I for one (though as i'm not writing the code this is just my comments) would not be willing to choose a rendering engine based on whether it works or not on platform X. Both Mozilla and KHTML work quite well on a large number of platforms. I'd need to know a lot more about why Mozilla doesn't work well on OpenBSD before ruling out gecko - like, is it due to something missing on OpenBSD itself. In particular due to the very few numbers of people using it on the desktop, I'd say if Mozilla doesn't work on that platform it's the problem of obsd or mozilla, not Wine. On the other hand, I don't really think Gecko is right for this anyway, so it's something of a moot point. Generally though I'd say that making decisions based on what certain platforms can and cannot do is a bad idea when said platform is in the minority of usage (esp when it's all open source). Flame away. On Mon, 2002-11-11 at 11:23, Keith Matthews wrote: > On 11 Nov 2002 08:29:49 +0000 > "Mike Hearn" <m.hearn(a)signal.qinetiq.com> wrote: > > > Hi, > > > > Please make sure you try whatever rendering engine you choose with a > > wide sample of CHM pages. From what I remember of my Windows days, CHM > > help often contains lots of IEisms, from VBScript to IE specific > > DHTML, ie they're not standard HTML despite the name. > > > > Whatever renderer is chosen then should be one we can easily fork and > > massage into a relatively IE compatible one. Here is a quick roundup > > of the options based on what I know of the available engines: > > > > - Gecko: the best (in terms of features/compatability/speed) rendering > > engine around. Also benefits from being very widely deployed at least > > on Linux. Note that soon Mozilla will be splitting into a GRE (gecko > > runtime environment), then an XRE (xul runtime) layered on top, with > > Mozilla being an "application" on top of that framework. When this > > happens, making the GRE a dependancy of Wine would not be such a big > > deal IMHO, it's only a few megs at the moment. > > > > * Pros: We get a high quality rendering engine that we know is > > powerful enough to do what we need, and when the GRE thing happens > > it'll be relatively easy to embed too. Already has IWebBrowser > > interfaces(bitrotted afaik). > > * Cons: Gecko codebase is huge and complex, adding whatever IEisms > > are > > necessary may be hard. Overhead of XPCOM etc. > > > I'll add something else here. > > Mozilla is an absolute pain to run on OpenBSD. The porting team have > recently worked out that they can get it to run as long as they > statically link it. > > I have no idea if the Gecko part is affected by this, and I'm aware that > Wine does not currently run on OBSD anyway, but why make things more > difficult. > > Konq runs happily so KHTML is probably no problem and I have not heard > of any problems with GtkHTML. > >

1 0