- Wine-Devel - list.winehq.org

OLE speed, builtin vs. native
by Dan Kegel Feb. 8, 2003

Feb. 8, 2003

I'm testing an Installshield 6 setup program tonight against wine-20030115 remotely over a 1Mbit/sec link. Running native $ wine SETUP.EXE takes 1 minute 40 seconds to put up the main dialog. With the DLL overrides $ wine --dll compobj,storage,ole,ole2,ole32,oleaut32,rpcrt4=n SETUP.EXE it takes 1 minute 10 seconds. So our OLE seems to be noticably slower. I imagine we'll fix that up before 1.0. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Various Visual FoxPro bug reports filed
by Paul McNett Feb. 7, 2003

Feb. 7, 2003

Hello, I just filed 5 bug reports (1263-1267) regarding various issues with Microsoft Visual FoxPro. These represent some of the most obvious issues, but I'm sure I'll find more as I move my Visual FoxPro development over to Linux from Windows. I have a demo Visual FoxPro application that demonstrates these issues and a few more that I haven't reported in BugZilla yet. You can get this app from my site at: http://www.paulmcnett.com/vfp/testwine/ I'll be updating this app as new issues are discovered and old ones resolved. I'll now take this opportunity to thank everyone here for making Wine what it is today: you are giving me the ability to move off of Windows completely and yet still use my favorite development environment. Kudos to everyone involved! -- Paul McNett - p(a)ulmcnett.com Hollister, California, USA

1 0

145 Gnu Makefiles for all Petzold Programs
by John Kopplin Feb. 7, 2003

Feb. 7, 2003

I have just completed 145 Gnu makefiles that allow the free MinGW (Gnu) Compiler to compile and execute all of the example programs which Charles Petzold describes in his "Programming Windows Fifth Edition" book, which is the standard reference book on Microsoft's WIN32 API. I freely distribute these 145 makefiles in a .ZIP file, along with an installation program that will copy them into Petzold's directory structure, from my web page at: http://www.computersciencelab.com/Petzold.htm Only 5 of the 145 programs require user intervention to compile with the Gnu compiler, which is not bad for porting that many programs to a new compiler, especially given Microsoft's lax adherence to standards. I would be very pleased if these makefiles would help with the development of the Wine emulator. John Kopplin _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail

2 1

To select or LBS_NOSEL...
by Ferenc Wagner Feb. 7, 2003

Feb. 7, 2003

Hello, can anybody think of a way that a listbox with LBS_NOSEL style can still highlight a row, return meaningful values for LB_GETCURSEL and in general behave exatly like a selectable one? This is the behaviour I see under Win 95 and XP (using Spy++), and what I can achieve under Wine by unsetting the LBS_NOSEL attribute in LISTBOX_Create. What's going on? MSDN tells what you'd expect... I would be grateful for any insight. I hope to create some test program soon, but since I've never coded Windows GUIs it will probably take some time and brain cells. Feri.

1 0

Listview problems
by Dan Kegel Feb. 7, 2003

Feb. 7, 2003

I've already sent this to Dimi, but... the demo http://msdn.microsoft.com/downloads/samples/internet/commctrl/vlistvw/defau… doesn't work very well with Wine at the moment. It demonstrates the LVS_OWNERDATA variant of a listview. I built it with msvc6. The default view looks ok, but if you pick a different view, the fun starts... "large icons" seem to all be drawn on top of each other. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 3

edit control bug
by Felipe W Damasio Feb. 7, 2003

Feb. 7, 2003

Hi, I'm porting a software using winelib and found a (at least I think so) serious bug with the edit control: When you put a lot of text in an edit control and then begins to backspace them, the app simply seg faults. I'm using wine-20030115 but also tried wine-20021031, and both have this bug. Both the source and the executable for test are available here: ftp://elipse.com.br/pub/EditControl/about1-src.tar.gz ftp://elipse.com.br/pub/EditControl/about1-exe.tar.gz Yeah, I stole the example from Petzold's book....so please enter help->about to see the dialog :) Can anyone help with this? Is this a known wine bug? I did the usual google search but couldn't fine any reference of this. But if is: Is somebody working on it? Or will anyone work on this? And can I help? Thanks for any help you can give me (please CC me). Felipe

3 5

Re: RtlUpperChar (was: some ntdll functions) [Virus checked]
by thomas.mertes＠t-mobile.at Feb. 6, 2003

Feb. 6, 2003

Dan Kegel <dank(a)kegel.com> wrote: > That looks like a horrible kludge. Before we settle on > something like this, we should probably consult the > people on the unicode mailing list to see what they > suggest. This is not what I suggest. Please read my complete mail. I wrote: I did a test on w2k trying to convert all chars between 0 and 255. The result was: Just 'a' .. 'z' are converted to 'A' .. 'Z', all other characters remain unchanged. I switched the machine between 'EN' (English) and 'DE' (German) and no difference. My test Function is: static void test_RtlUpperChar(void) { int i; CHAR ch; CHAR upper_ch; CHAR expected_upper_ch; for (i = 0; i <= 255; i++) { ch = (CHAR) i; upper_ch = pRtlUpperChar(ch); if (ch >= 'a' && ch <= 'z') { expected_upper_ch = ch - 'a' + 'A'; } else { expected_upper_ch = ch; } /* if */ ok(upper_ch == expected_upper_ch, "RtlUpperChar('%c') has result '%c', expected '%c'", ch, upper_ch, expected_upper_ch); } /* for */ } ... and this test passed really under native w2k. Greetings Thomas

2 1

WineConf 2003
by Dan Kegel Feb. 6, 2003

Feb. 6, 2003

How about we hold it as a satellite conference to LinuxTag, Karlsruhe, Germany, 10-13 July 2003? LinuxTag is a very big, very cool event. See http://www.linuxtag.org/2003/en/conferences/cfp.html - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

4 5

Re: Fix module entry deallocation in MODULE_DecRefCount
by Eric Pouech Feb. 6, 2003

Feb. 6, 2003

Warren_Baird(a)cimmetry.com wrote: > > > ChangeLog: > > Fix module entry deallocation in MODULE_DecRefCount. > > Description: > > Also decrement the reference count on any other libraries with > exactly the same short name since two module entries are being > allocated when we load the library. Maybe the real fix here would > be to ensure that a module entry is allocated no more than once > but we couldn't figure out how to do that. the fix doesn't seem the right one... could you post a -debugmsg +file,+module of what really happens here A+ -- Eric Pouech

1 0

Re: RtlUpperChar (was: some ntdll functions) [Virus checked]
by thomas.mertes＠t-mobile.at Feb. 6, 2003

Feb. 6, 2003

"Dmitry Timoshkov" <dmitry(a)baikal.ru> wrote: > <thomas.mertes(a)t-mobile.at> wrote: > > > RtlUpperChar does not take the locale into account. It always convertes > > just > > 'a' .. 'z' and nothing else. > > > > Is this the right direction or did I miss something? > > No, that's not right. We really need to convert to unicode first, then > upper case unicode character and convert the result back to ansi. See > the ReactOS source for reference (at the first glance it closely enough > matches NTDLL asm code). I have not seen the asm code. I just do tests on w2k (see my other mail). ReactOS is ok but not my measurement. These tests suggest that the right implementation would be: CHAR WINAPI RtlUpperChar( CHAR ch ) { if (ch >= 'a' && ch <= 'z') { return ch - 'a' + 'A'; } else { return ch; } } I was not able to find any other behaviour under w2k. RtlUpperString also just converts 'a' .. 'z' to 'A' .. 'Z'. In my opinion RtlUpperChar and RtlUpperString are low level functions which do not know anything about locales / codepages. But the ntdll (and msvcrt) functions toupper and _toupper should know about locales / codepages (may be they should use the solution below). BTW: My other implementation did it the ReactOS way and is not a 'horrible kludge': CHAR WINAPI RtlUpperChar( CHAR ch ) { WCHAR wch; wch = toupperW(((WCHAR) ch) & 0xff); if (wch >> 8) { return ch; } else { return (CHAR) wch; } } According to my information: When you do not have multibyte chars (as it is here), you just set the upper byte to 0. Just look close: ((WCHAR) ch) & 0xff is necessary because CHAR is signed and ((WCHAR) ch) would sign extend (which is wrong). I did a test with the 'horrible kludge' on wine and it worked fine (The ISO Latin 1 charaters got converted in the right way). Greetings Thomas

2 1