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

Winmm resources and WINE Resource Compiler
by Steven Edwards Dec. 14, 2003

Dec. 14, 2003

Hello, It seems the Wine Resource compiler accepts \"string\" in resources while windres and MS RC do not. I have updated the resources for winmm and wrc still accepts the proper handling of this ""string"". Can someone look at the sources for WRC and fix this? Thanks Steven Changelog: Porting fix for Winmm Resources (patch by Filip Navara) __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

1 0

Allocating too much memory for prelink workaround
by Vincent Béron Dec. 14, 2003

Dec. 14, 2003

Thinking about what Fabian and Marcus hit... Would it be possible to just have a dummy executable which allocates the 256MB chunk of memory from 11/22, linked to the same libs as the main wine-{k,p}thread, but having that executable not actually used? That way, we still gain the prelink workaround by reserving the memory, but Wine should continue to work on computers with less memory, or those who do not overcommit memory. Vincent

3 6

Help w/fd_ops for SMB
by Juan Lang Dec. 14, 2003

Dec. 14, 2003

Hi folks, I'm trying to modify Wine's SMB code to use Netbios(), rather than implementing NetBIOS-over-TCPIP itself. I'm having trouble figuring out how to handle the fd_ops in the wineserver. I was hoping for input. Currently, the SMB code creates a socket directly, and this socket is polled by the server for readability. Netbios() hides a connection behind an 8-bit adapter index and an 8-bit session index, so there's no way (through the Netbios() interface) to get the socket handle being used for a connection. Any opinions on whether (and if yes, how) the polling should be done? One possibility might be to figure out the TDI stuff, as using TDI for NetBIOS allows you to avoid the Netbios() interface. However, I haven't found any public documentation for the TDI interface to NetBIOS, except perhaps in the NT DDK (whose license I think is problematic). Any suggestions appreciated. Thanks, --Juan __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

2 3

Alsa 1.0 and Wine
by Brett I. Holcomb Dec. 14, 2003

Dec. 14, 2003

I checked the archives and noticed the thread on Alsa 1.0. What was the resolution on that? I guess my concern is that for those of us that have 1.0 what happens if it's left for 0.9. I know with Winex it broke and I had to patch the winex alsa files. I used the quick and dirty method of modifying the header file but that is really a kluge and not long term. I have Alsa 1.0 installed so it works but it's not transportable to a system with 0.9. The better method is the patch that supports both interfaces so it doesn't matter what we have. I know I made the move to Alsa 1.0 because it does fix the oss emulation problem which has been bothering a lot of people. Thanks.

1 0

Printing with no printer
by Mike Hearn Dec. 14, 2003

Dec. 14, 2003

Hi, It seems from reading the documentation that it's possible to print to a .ps file in Wine, even if you don't actually have a printer. However, I'm not sure how to do that - I've got far enough to get the "Couldn't find PPD file '/unix/path/to/PPD/file', expect a crash now!" message, but am not sure where to go from here. I don't have any PPD files, as I have no printer. Has anybody done this before? thanks -mike

2 1

win16 app crashes in SCROLL_GetScrollRange()
by Saulius Krasuckas Dec. 14, 2003

Dec. 14, 2003

hi, once i got this crash. i have ve filled a bug report: http://bugs.winehq.com/show_bug.cgi?id=1503 now, inspired with a notice made by Andreas Mohr..: > Ah, WAIT!! Watcom has: > ./h/nt/winuser.h:#define SBM_GETRANGE 0x00E3 /*not in win3.1 */ .i decided to dig into some details. and i've stopped at one unclear state. wine has a patch in cvs: http://www.winehq.org/hypermail/wine-patches/2003/03/0052.html which says: > As discussed with Alexandre, this patch makes the GetScroll* API > functions send a message to the Window in the case of SB_CTL scroll > bars. - if (!(infoPtr = SCROLL_GetScrollInfo( hwnd, nBar ))) - { - if (lpMin) lpMin = 0; - if (lpMax) lpMax = 0; - return FALSE; - } - if (lpMin) *lpMin = infoPtr->minVal; - if (lpMax) *lpMax = infoPtr->maxVal; - return TRUE; + /* Refer SB_CTL requests to the window */ + if (nBar == SB_CTL) + return SendMessageA(hwnd, SBM_GETRANGE, (WPARAM)lpMin, (LPARAM)lpMax); + else + return SCROLL_GetScrollRange(hwnd, nBar, lpMin, lpMax); may now i ask someone for a help or explanation? the question is: if the win16 doesn't handle SBM_GETRANGE message, should wine send it in a case of win16 app? if no, then i'd like to start writing an additional check ;-). and one more question. msdn states: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/pl… If the nBar parameter is SB_CTL and the window specified by the hWnd parameter is not a system scroll bar control, the system sends the SBM_GETRANGE message to the window to obtain scroll bar information. This allows GetScrollRange to operate on a custom control that mimics a scroll bar. aren't we missing one more check here? maybe we need to check class-name of control targeted by hwnd? additional greps led me to: [s2(a)katleriai wine-cvs]$ grep -A10 Scrollbar.messages wine/include/wine/winuser16.h /* Scrollbar messages */ #define SBM_SETPOS16 (WM_USER+0) #define SBM_GETPOS16 (WM_USER+1) #define SBM_SETRANGE16 (WM_USER+2) #define SBM_GETRANGE16 (WM_USER+3) #define SBM_ENABLE_ARROWS16 (WM_USER+4) #define SBM_SETRANGEREDRAW16 WM_NULL /* Not in Win16 */ #define SBM_SETSCROLLINFO16 WM_NULL /* Not in Win16 */ #define SBM_GETSCROLLINFO16 WM_NULL /* Not in Win16 */ /* CBT hook structures */ any ideas about where these constants came from? googling with "-wine" keyword gave me NULL :-/.

5 7

Re: locale: Fix for too small buffers
by Vitaliy Margolen Dec. 14, 2003

Dec. 14, 2003

Yep that is the problem I was seeing with one program I'm running. And this patch took care of it. Thanks! Vitaliy Margolen Tuesday, December 2, 2003, 13:01:18, Vitaliy Margolen wrote: > Hi, found a problem with the latest locale changes. When it calls the > GetLocaleInfoW() function, the attached error occurs. > This occurred because of the new code using the LOCALE_RETURN_NUMBER flag. The > problem is if the buffer supplied to get_registry_locale_info is quite small > (say sizeof(INT)). The value returned by NtQueryValueKey() however, is for a > string, and is much longer. As NtQueryValueKey updates the value of size, > this caused other parts of the code to corrupt memory.

3 4

msg.c:333: Test failed: ShowWindow:overlapped: in msg 0x0047 expecting wParam 0x47 got 0x0
by Uwe Bonnes Dec. 13, 2003

Dec. 13, 2003

Hallo, running "make test" in "ddls/user/test", I get ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so msg.c && touch msg.ok msg.c:333: Test failed: ShowWindow:overlapped: in msg 0x0047 expecting wParam 0x47 got 0x0 make: *** [msg.ok] Error 1 This is on a Suse 9.0 system, SMP with two P3, kernel "Linux siemens 2.4.21-144-smp4G" Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: config: add resources path
by Alexandre Julliard Dec. 13, 2003

Dec. 13, 2003

Kevin Koltzau <kevin(a)plop.org> writes: > Many registry keys under XP refer to a %ResourceDir% env that points > to the path where windows themes are located. > > In case any apps refer to this, or if someone loads a registry > export from XP this should be available in wine also > > Interestingly, windows doesn't actually have this env set..my guess > is ExpandEnvironmentStrings has a special case to handle this > particular name I seriously doubt that; most likely it's something that is either handled internally in uxtheme, or uxtheme defines the variable before expanding the string. I think this needs more investigation, but it doesn't seem to be something that should be handled in kernel. -- Alexandre Julliard julliard(a)winehq.com

3 4

[Bug 939] We need a resolution for abandoned bugs
by Uwe Bonnes Dec. 13, 2003

Dec. 13, 2003

Hallo, what about having a mechanisme that mails the bug autor after a given time, lets say 1/2 year, asking to reconfirm the bug. With no reaction from the bug author after some time ( several weeks), the bug is marked as abandonned. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Delayed debug tracing
by Mike Hearn Dec. 13, 2003

Dec. 13, 2003

Hi, I'd like to implement delayed debug tracing, by which I mean you can do a +relay,+seh,+tid,+win,+otherstuff and yet not create a log file so huge it's impossible to work with. I seem to recall seeing this feature in WineX, where you can press Alt-F12 to switch it on. Does anybody who knows the debugging/keyboard code have any particular preferences as to how this should be implemented? thanks -mike

5 8

Corrupted Wine source package on sf
by Vincent Béron Dec. 13, 2003

Dec. 13, 2003

Hi Alexandre, The 20031212 source .tar.gz on sourceforge is shorter (~400k) than the one on ibiblio, and when untarred yields an error. You probably want to reupload it. Vincent

2 1

Internally maintained end-to-end API documentation
by Joshua Walker Dec. 13, 2003

Dec. 13, 2003

Hello all, I have been a lurker, going on now a good part of three years. I have some ideas I wish to cast to the table. I am a writer, not a programmer by craft. This hindrance aside, I have kicked around my fair share of C code. I have also been known to throw gooey splatterings of VMS report data into Postgres, and somehow rationalize it into something coherent on the other side for pay. After reading Wine Weekly News Issue #200, (Congrats by the way), I stumbled across the Wine Status Pages. I particularly like how everything is grouped by major components. With a quick glance at a color-coded graph, one can see how well something has been implemented. There is one thing that really bugging the heck out of me. Most of the API documentation is possessed by MSDN. In my humble opinion, this is a very dangerous and volatile place to have it. I was once told that using the internet as a data resource is like watching The Library of Alexandria burn over and over again. Having attempted to be a code developer for Microsoft products in the past, I know how quick MSDN can be when it comes to pulling the data out from under your feet. I also know what it's like to go hunting for some bizarre functionality, only to have MSDN look at you back with nothing but a blank stare on it's face. Sometimes it's the "little things" like the deep inner workings of interprocess communication. Better yet, why on earth is my stack is being messed with after a function call. I think it's about time to take the various Windows APIs and place them onto a fishbowl for safe keeping. Having lurked here for as long as I have, I have found two constants about announcing projects on wine-devel that I'd like to share. 1) In order to have Alexandre change direction, you better have a very good reason. 2) Many ideas have been announced here with no real clear goal or steps of execution. They soon die of atrophy shortly after. As for myself, I'm thinking to taking up the mantle for documenting the Windows API, or at least setting up public facilties for myself and others to use. The problem I have is how about will it be documented? First goal is to figure out where on earth to *put* the documentation.. I'm thinking of some kind of universal data holder where API information can aggregated, parsed, and rendered to one's choosing. As I shook my magic hate-ball I asked, "What do you think about storing the API data in some kind of XMLish-thingy format?" All signs pointed to yes. This is quite tragic as my knowledge of XML is really weak. As far as I know, it's that HTML superset, isn't it? Stepping back a bit, I started thinking of tossing an SQL database on one of my machines and writing some kind of dynamic HTML front end for it. The SQL idea is nice because I can write the front end to spit out what I have in any data format I can dream of, including XML. It also allows people to come to my website, pop in an API function that wan't there, and move on with their lives. That seems plausible. The second hurtle is what to put as the actual fields. I'm really only used to seeing function rendered an a "Unix man style" format. Name, synopsis, description, return value, errors, bugs. See "man fork" for example. We will also need kind of a DLL overview, (man stdio?). What about something a little more UML compatible. Anyone have any ideas? Admittedly this is where my coherence of the project ends. There might be someone out there a little more apt at content than I am. Let me close with a story; When I was 12 my mother bought a brand new washing machine. My mother gave me the old one and a set of wrenches, and then proceeded to tell me to go nuts. In the span of five hours there was washing machine all over our front lawn. I learned more about about washing machines at the age of 12 by tearing that thing apart more than most adults know now. It's kinda what I want to do with Windows. -Joshua

2 1

More deadlocks + backtrace
by Shachar Shemesh Dec. 13, 2003

Dec. 13, 2003

I ran "spyxx" from MSVC on my deadlocking program, and everything was ok. I then quite the program itself (Microsoft Digital Image Pro was run with +relay, spy was run without any debug values). I left spy running for a while (~2 days), as I had other things to do, and I wanted the window handles it collected. At some point, the console that launched spy began showing the following: $ wine SPYXX err:font:ReadFontDir Can't open directory "/win/windows/fonts" fixme:mdi:MDIRefreshMenu partially function stub fixme:mdi:MDIRefreshMenu partially function stub err:toolbar:TOOLBAR_NotifyFormat wrong response to WM_NOTIFYFORMAT (0), assuming ANSI err:win:CreateWindowExA bad class name "msctls_updown" err:ntdll:RtlpWaitForCriticalSection section 0x40380d68 "?" wait timed out in thread 0011, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x40380d68 "?" wait timed out in thread 0011, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x40380d68 "?" wait timed out in thread 0011, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x40380d68 "?" wait timed out in thread 0011, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x40380d68 "?" wait timed out in thread 0011, blocked by 0000, retrying (60 sec) Here are the backtraces: Wine-dbg>walk process pid threads parent executable >00000010 2 00000000 'Y:\sources\Transfer\RemoteDebug\SPYXX.EXE' Wine-dbg>walk thread process tid prio 00000010 (D) Y:\sources\Transfer\RemoteDebug\SPYXX.EXE 00000012 0 <== 00000011 0 Wine-dbg>bt 0x11 Backtrace: =>0 0x4010e8ab (NTDLL.DLL._memccpy+0x5202b in libc.so.6) (ebp=40032c60) 1 0x401f4002 (NTDLL_wait_for_multiple_objects+0xbf(count=0x0, handles=0x0, flags=0x8, timeout=0x40032d10) [sync.c:578] in NTDLL.DLL) (ebp=40032cf8) 2 0x401f1edd (usr1_handler+0x4e(__signal=0xa, __context=0x8f) [signal_i386.c:1123] in NTDLL.DLL) (ebp=40032d1c) 3 0x4006e498 (NTDLL.DLL.toupper+0x6208 in libc.so.6) (ebp=4080f7e0) 4 0x401f4002 (NTDLL_wait_for_multiple_objects+0xbf(count=0x1, handles=0x4080f8cc, flags=0xc, timeout=0x4080f900) [sync.c:578] in NTDLL.DLL) (ebp=4080f878) 5 0x401f40ae (NTDLL.DLL.NtWaitForMultipleObjects+0x74 in NTDLL.DLL) (ebp=4080f8a0) 6 0x401f40fe (NtWaitForSingleObject+0x42(handle=0x88, alertable=0x0, timeout=0x4080f900) [sync.c:611] in NTDLL.DLL) (ebp=4080f8c4) 7 0x401cda35 (RtlpWaitForCriticalSection+0x127(crit=0x40380d68) [critsection.c:193] in NTDLL.DLL) (ebp=4080f964) 8 0x401cdc25 (RtlEnterCriticalSection+0x51(crit=0x40380d68) [critsection.c:255] in NTDLL.DLL) (ebp=4080f97c) 9 0x404f2555 (wine_pthread_mutex_lock+0x34(mutex=0x101593c8) [pthread.c:182] in KERNEL32.DLL) (ebp=4080f98c) 10 0x0011273a (__pthread_mutex_lock+0x25(mutex=0x101593c8) [kthread.c:588] in wine-kthread) (ebp=4080f99c) 11 0x40f409ea (_end+0x75bb6 in libX11.so.6) (ebp=4080f9bc) 12 0x40f0d799 (_end+0x42965 in libX11.so.6) (ebp=4080fa1c) 13 0x40e8b39e (X11DRV_InitKeyboard+0x84(key_state_table=0x40b66880) [keyboard.c:1332] in X11DRV.DLL) (ebp=4080fadc) 14 0x40e8c1c4 (X11DRV_MappingNotify+0x35(event=0x4080fb94) [keyboard.c:1635] in X11DRV.DLL) (ebp=4080fafc) 15 0x40e83647 (.L164+0xb [event.c] in X11DRV.DLL) (ebp=4080fb7c) 16 0x40e82e65 (process_events+0x71(data=0x40380d40) [event.c:143] in X11DRV.DLL) (ebp=4080fbf8) 17 0x40e82ffa (X11DRV_MsgWaitForMultipleObjectsEx+0x17b(count=0x1, handles=0x40380c6c, timeout=0xffffffff, mask=0x0, flags=0x0) [event.c:184] in X11DRV.DLL) (ebp=4080fd38) 18 0x40ad5f96 (GetMessageW+0x287(msg=0x46becc, hwnd=0x0, first=0x0, last=0x0) [message.c:2363] in USER32.DLL) (ebp=4080fdf4) 19 0x40ad6020 (GetMessageA+0x33(msg=0x46becc, hwnd=0x0, first=0x0, last=0x0) [message.c:2380] in USER32.DLL) (ebp=4080fe14) 20 0x6c3be6e9 (MFC42.DLL.5307+0x13 in MFC42.DLL) (ebp=0046becc) 21 0x0000000f (ebp=000100d6) Wine-dbg>bt 0x12 Backtrace: =>0 0x4010e8ab (NTDLL.DLL._memccpy+0x5202b in libc.so.6) (ebp=4030fc60) 1 0x401f4002 (NTDLL_wait_for_multiple_objects+0xbf(count=0x0, handles=0x0, flags=0x8, timeout=0x4030fd10) [sync.c:578] in NTDLL.DLL) (ebp=4030fcf8) 2 0x401f1edd (usr1_handler+0x4e(__signal=0xa, __context=0x8f) [signal_i386.c:1123] in NTDLL.DLL) (ebp=4030fd1c) 3 0x4006e498 (NTDLL.DLL.toupper+0x6208 in libc.so.6) (ebp=419eb450) 4 0x401f4002 (NTDLL_wait_for_multiple_objects+0xbf(count=0x1, handles=0x419eb53c, flags=0xc, timeout=0x419eb530) [sync.c:578] in NTDLL.DLL) (ebp=419eb4e8) 5 0x401f40ae (NTDLL.DLL.NtWaitForMultipleObjects+0x74 in NTDLL.DLL) (ebp=419eb510) 6 0x404fcb20 (WaitForMultipleObjectsEx+0x1d5(count=0x1, handles=0x419eb670, wait_all=0x0, timeout=0x32, alertable=0x0) [sync.c:167] in KERNEL32.DLL) (ebp=419eb648) 7 0x404fc8b8 (WaitForSingleObject+0x3c(handle=0x64, timeout=0x32) [sync.c:95] in KERNEL32.DLL) (ebp=419eb668) 8 0x004232fa (SPYXX.EXE..text+0x222fa in SPYXX.EXE) (ebp=40aab4df) 9 0x0168ec81 (SPYXX.EXE..rsrc+0x1221c81 in wine-kthread) (ebp=53e58955) *** Invalid address 0x53e58955 (_end+0x121f453d) I hope this helps someone. -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

2 3

Added support for inter-process GetWindowLong on the window extra bytes
by Phil Krylov Dec. 13, 2003

Dec. 13, 2003

Hello, This change prevents IBM Translation Manager from working correctly. It has a dialog named "Export Folder" which used to contain three buttons and a tabbed notebook with various options. After this update, the pages of the tabbed notebook are no longer displayed (and created). Hope I can provide some more details like a debug log if someone will tell me which channels should be traced. AJ> ChangeSet ID: 10222 AJ> CVSROOT: /opt/cvs-commit AJ> Module name: wine AJ> Changes by: julliard(a)wine.codeweavers.com 2003/11/26 16:15:41 AJ> Modified files: AJ> windows : win.c AJ> server : window.c trace.c protocol.def AJ> include/wine : server_protocol.h AJ> Log message: AJ> Added support for inter-process GetWindowLong on the window extra AJ> bytes. AJ> Patch: http://cvs.winehq.com/patch.py?id=10222 AJ> Old revision New revision Changes Path AJ> 1.226 1.227 +132 -111 wine/windows/win.c AJ> 1.25 1.26 +36 -4 wine/server/window.c AJ> 1.185 1.186 +7 -3 wine/server/trace.c AJ> 1.87 1.88 +6 -0 wine/server/protocol.def AJ> 1.88 1.89 +7 -1 AJ> wine/include/wine/server_protocol.h -- Best regards, Phil mailto:phil(a)newstar.rinet.ru

2 3

Core DLL's Status Section
by Tom Dec. 13, 2003

Dec. 13, 2003

Hi, Here is my first draft anyone have any comments?, constructive criticism? You will see I have wineps, x11drv, winedos listed on this page now so ill remove those sections from the Core Status page. If everything looks good ill paste the three sections together and send Brian a copy for WWN inclusion. :) And while he is doing that ill add in the remaining doc links. and then it should be ready for wine-patches. I've also got a nice new list of todo's to add to that page as well. Happy Holidays, Tom

1 0

Re: gdi: AlphaBlend constants
by Alexandre Julliard Dec. 12, 2003

Dec. 12, 2003

Kirill Smelkov <kirr(a)landau.phys.spbu.ru> writes: > +/* AlphaBlend flags */ > +#define AC_SRC_NO_PREMULT_ALPHA 0x01 > +#define AC_SRC_NO_ALPHA 0x02 > +#define AC_DST_NO_PREMULT_ALPHA 0x10 > +#define AC_DST_NO_ALPHA 0x20 Where do these come from? I don't see them in the SDK headers or on MSDN, there's only an AC_SRC_ALPHA. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: ntdll / kernel32: #38
by Dmitry Timoshkov Dec. 12, 2003

Dec. 12, 2003

"Eric Pouech" <pouech-eric(a)wanadoo.fr> wrote: > +HANDLE WINAPI OpenConsoleW(LPCWSTR name, DWORD access, LPSECURITY_ATTRIBUTES sa, > + DWORD creation) > +{ > + static const WCHAR coninW[] = {'C','O','N','I','N','$',0}; > + static const WCHAR conoutW[] = {'C','O','N','O','U','T','$',0}; > + BOOL output; > + HANDLE ret; > + > + if (strcmpW(coninW, name) == 0) > + output = FALSE; > + else if (strcmpW(conoutW, name) == 0) > + output = TRUE; While you are moving the code around then you are probably reviewing it as well? So, the question is: shouldn't the above comparisons be case insensitive? -- Dmitry.

2 1

Re: menu: Fix for menu tracking problem version 2
by Alexandre Julliard Dec. 12, 2003

Dec. 12, 2003

Andrew de Quincey <adq_dvb(a)lidskialf.net> writes: > I wrote a program in windows which had owner drawn menu items. Whenever I > received the WM_DRAWITEM message: > > 1) I called GetCapture(), and compared it with the hwnd of main window > containing the menu. It pops up a message box if they are different. > 2) I then called SetCapture() with the HWND of the menu item itself. > > This approximately simulates what IDA is doing. > > The message box never popped up. This shows that even though the capture was > changed in one WM_DRAWITEM, windows had reset the capture to the window > containing the menu by the time of the next one. I also checked the messages > _were_ being sent using Spy++ (in case of a programming error). That's a good start, but it's not enough to know what Windows is really doing. You should also check the capture window right after you call SetCapture; and you should use GetGUIThreadInfo and print out all the details, especially the GUI_INMENUMODE flag. My suspicion is that the capture is not allowed to change at all in menu mode. -- Alexandre Julliard julliard(a)winehq.com

2 5

Problems with transparent windows
by Juan Antonio Boscá Lloret Dec. 12, 2003

Dec. 12, 2003

Hello, I've found a probable bug in Wine when running win32 applications. Wine does not repaint windows areas that are hidden by another window over them (I think this is a behaviour by design). This behaviour is not correct when the upper window is transparent (WS_EX_TRANSPARENT style). Is it a bug? Thank you. --------------------------------------------------------------- Juan Antonio Boscá Lloret Departamento Programación CAE, S.A. jabosca(a)edicurs.com ---------------------------------------------------------------

2 1

Re: wine/dlls/kernel pthread.c
by Rein Klazes Dec. 12, 2003

Dec. 12, 2003

On Fri, 12 Dec 2003 00:19:25 -0600, you wrote: > Log message: > Return an error in wine_pthread_mutex_unlock if we don't own the > critical section, this should avoid trouble caused by a locking bug > inside Xlib. Good, the locking problem that I reported seems to be fixed by this. Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

Re: unicode & wine internals
by Mike Hearn Dec. 12, 2003

Dec. 12, 2003

No patch? On Thu, 2003-12-11 at 20:14, Eric Pouech wrote: > wine_get_unix_file_name is now a unicode function > A+

1 0

Re: shlexec: Fixes for buffer overrun problems
by Alexandre Julliard Dec. 12, 2003

Dec. 12, 2003

Andrew de Quincey <adq_dvb(a)lidskialf.net> writes: > Hi, this is a cleanup of shell32/shlexec.c to remove potential buffer > overruns. I've also tried to make parts of the code a little easier to > follow, without affecting the functionality. It's a very inefficient mechanism, you are reallocating the same string over and over to append sometimes only a single char. The right way to avoid overflows is to compute the length of the full string first and then allocate all the needed space at once. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Janitorial: Get rid of W->A calls for shlexec (2/2)
by Alexandre Julliard Dec. 12, 2003

Dec. 12, 2003

Marcelo Duarte <wine-devel(a)bol.com.br> writes: > Hi, > > Changelog: > Marcelo Duarte <wine-devel(a)bol.com.br> > -Janitorial: Get rid of W->A calls for shlexec > -Implementation of FindExecutableW > > Coments: > After you aplying my patch 1/2 and made corrections using sizeof, I see the > problems in the patch 2/2 and I do the corrections, and now, I think that all > is correct. No, there are still many places where the sizes are wrong. Every time you change a buffer from char[] to WCHAR[] you have to fix uses of sizeof on that buffer to count characters properly. Also there are still HeapAlloc calls that are done in bytes instead of WCHARs. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: comctl32/toolbar: Potential fix for button redraw in TBSTYLE_FLAT toolbars
by Dimitrie O. Paun Dec. 12, 2003

Dec. 12, 2003

On December 11, 2003 04:32 pm, Andrew de Quincey wrote: > I have concluded that the WM_ERASEBKGND is sent from within WM_PAINT when > the toolbar detects that the mouse has moved off a button and wants to > de-highlight it. Well, it probably does a InvalidateRect() call. You can try an ugly InvaldateRect(hwnd, 0, TRUE); but this will probably result in flicker. For added bonus, figure out the button's rect, and pass it in: /* figure out stuff in rect */ InvalidateRect(hwnd, &rect, TRUE); BTW, what are the parameters of WM_ERASEBKGND? -- Dimi.

2 4

bugs in d3d8.dll and msvcrt.dll
by Ivan Leo Murray-Smith Dec. 11, 2003

Dec. 11, 2003

There are 2 bugs that prevent mafia (Trial version) from working correctly, they are in d3d8.dll and msvcrt.dll, updated backtraces generated with wine-20031212 are at http://bugs.winehq.com/show_bug.cgi?id=1670 the demo is at http://www.mafia-game.com in the downloads section.

1 0

Deadlock?
by Shachar Shemesh Dec. 11, 2003

Dec. 11, 2003

When trying to run Microsoft Digital Image Pro, I occasionally get problems when loading it. The splash screen comes up, and then it hangs. This problem only happens occasionally. I have not, to date, managed to reproduce it with relay turned on. This is what I do get on screen: err:module:import_dll No implementation for USER32.dll.GetScrollBarInfo imported from L"C:\\Program Files\\Microsoft Picture It! 9\\piutil.dll", setting to 0xdeadbeef err:font:ReadFontDir Can't open directory "/win/windows/fonts" err:imagelist:ImageList_LoadImageW Error loading image! err:toolbar:ToolbarWindowProc unknown msg 204e wp=000000ca lp=4080deec err:toolbar:ToolbarWindowProc unknown msg 204e wp=000000ca lp=4080ea54 err:toolbar:ToolbarWindowProc unknown msg 2210 wp=00ca0001 lp=00010051 err:toolbar:ToolbarWindowProc unknown msg 204e wp=40c757d8 lp=4080eaa4 err:toolbar:ToolbarWindowProc unknown msg 2210 wp=57d80001 lp=00010053 fixme:toolbar:TOOLBAR_SetPadding stub - nothing done with values, cx=7, cy=9 fixme:imm:ImmAssociateContext (0x10056, (nil)): semi-stub fixme:imm:ImmAssociateContext (0x10058, (nil)): semi-stub fixme:imm:ImmAssociateContext (0x1005a, (nil)): semi-stub fixme:hook:NotifyWinEvent (32784,0x10056,-4,0)-stub! fixme:hook:NotifyWinEvent (32784,0x1005a,-4,0)-stub! fixme:hook:NotifyWinEvent (32782,0x10058,-4,0)-stub! err:toolbar:ToolbarWindowProc unknown msg 204e wp=000000ca lp=4080e61c fixme:imm:ImmAssociateContext (0x1009d, (nil)): semi-stub err:ntdll:RtlpWaitForCriticalSection section 0x4020fc60 "loader.c: loader_section" wait timed out in thread 0009, blocked by 000c, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x7c38b208 "?" wait timed out in thread 000c, blocked by 0009, retrying (60 sec) -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

2 4

winefile can't launch any apps!
by Dan Kegel Dec. 11, 2003

Dec. 11, 2003

Trying to launch any app, e.g. wine's notepad, by double-clicking on the .exe in 'winefile' crashes wine, like this: 0x42079c30 (NTDLL.DLL.strcpy+0x20): movzbl 0x0(%edx),%eax Wine-dbg>bt Backtrace: =>0 0x42079c30 (NTDLL.DLL.strcpy+0x20) (ebp=4072ed8c) 1 0x40778fd4 (SHELL32.DLL.FindExecutableW+0x7ec in SHELL32.DLL) (ebp=4072f840) 2 0x40779103 (SHELL32.DLL.ShellExecuteExA+0x1f in SHELL32.DLL) (ebp=4072f854) 3 0x40620515 (winefile.exe.EntryPoint+0x4515 in winefile.exe) (ebp=4072f9c4) 4 0x40620692 (winefile.exe.EntryPoint+0x4692 in winefile.exe) (ebp=4072f9f0) 5 0x40620a8c (winefile.exe.EntryPoint+0x4a8c in winefile.exe) (ebp=4072faa4) 6 0x408d0703 (USER32.DLL.EndDeferWindowPos+0x31b in USER32.DLL) (ebp=4072fac8) 7 0x408d0761 (USER32.DLL.EndDeferWindowPos+0x379 in USER32.DLL) (ebp=4072faf4) 8 0x408d4ff2 (USER32.DLL.EndDeferWindowPos+0x4c0a in USER32.DLL) (ebp=4072fb1c) 9 0x408d5645 (USER32.DLL.CallWindowProcW+0xf9 in USER32.DLL) (ebp=4072fb50) 10 0x408e50ab (USER32.DLL.IsCharAlphaW+0x2d57 in USER32.DLL) (ebp=4072fbac) 11 0x408e5e2d (USER32.DLL.SendMessageTimeoutW+0x135 in USER32.DLL) (ebp=4072fc10) 12 0x408e604d (USER32.DLL.SendMessageW+0x31 in USER32.DLL) (ebp=4072fc3c) 13 0x40895f32 (USER32.DLL.EditWndProc+0xaff6 in USER32.DLL) (ebp=4072fcd4) 14 0x40897359 (USER32.DLL.EditWndProc+0xc41d in USER32.DLL) (ebp=4072fcf8) 15 0x408d0703 (USER32.DLL.EndDeferWindowPos+0x31b in USER32.DLL) (ebp=4072fd1c) 16 0x408d0761 (USER32.DLL.EndDeferWindowPos+0x379 in USER32.DLL) (ebp=4072fd48) 17 0x408d5539 (USER32.DLL.CallWindowProcA+0xf9 in USER32.DLL) (ebp=4072fd7c) 18 0x40620d99 (winefile.exe.EntryPoint+0x4d99 in winefile.exe) (ebp=4072fda4) 19 0x408d0703 (USER32.DLL.EndDeferWindowPos+0x31b in USER32.DLL) (ebp=4072fdc8) 20 0x408d0761 (USER32.DLL.EndDeferWindowPos+0x379 in USER32.DLL) (ebp=4072fdf4) 21 0x408d5539 (USER32.DLL.CallWindowProcA+0xf9 in USER32.DLL) (ebp=4072fe28) 22 0x408b94a2 (USER32.DLL.DispatchMessageA+0x96 in USER32.DLL) (ebp=4072fe6c) 23 0x406214b9 (winefile.exe.EntryPoint+0x54b9 in winefile.exe) (ebp=4072fea4) 24 0x406214f1 (winefile.exe.EntryPoint+0x54f1 in winefile.exe) (ebp=4072febc) 25 0x4061c0a5 (winefile.exe.EntryPoint+0xa5 in winefile.exe) (ebp=4072ff2c) 26 0x4036b132 (KERNEL32.DLL.SetThreadExecutionState+0x16d6 in KERNEL32.DLL) (ebp=4072fff4) 27 0x4002df1d (_end+0x402c0f1) (ebp=00000000) This is on an SMP RH9 system running wine 20031118 compiled from source. - Dan

5 7

Low level dlls
by carlini＠dcc.ufmg.br Dec. 11, 2003

Dec. 11, 2003

Hi, what is a low level dlls in M$ windows nt? (low level dll == ddl whit access win device driver and/or hardware recourses.) They can natively be loaded? tanks Ricardo ================================ = Ricardo Carlini Sperandio = = 4! perido = = Ciencia da Computacao - UFMG = = Slack User / FreeBSD user = ================================

1 0

Re: I made a wish, wrote a letter to Santa...
by Subhobroto Sinha Dec. 11, 2003

Dec. 11, 2003

Actually Shachar, I was thinking along these lines: (1) Programs in WINE are making direct calls to internal functions (which are not really Win32, but made by us using which we can use te Win32 functions as wrappers...) and that's just possible because C functions are globally callable (the only thing you really need to keep the compiler happy is the function prototype) And that's a bad thing, because while developing tools we should really forget that we are coding fo WINE, and just write using Win32 SDK APIs... Encapsulating internal WINE functions as private, and exposing them using the correct APIs would be better engineering... Just to force lazy people like us to write protable code (you see, calling internal WINE functions are a lot easier than calling the corresponding wrappers.. (2) A few things like DirectX and COM are so very closely tied with C++ objects that implementing them in C seems an overkill to me. But after knowing they are done, I have nothing against that .... (3) C++ is VERY reusable. WINE has a lot of potential for reusablity , but by doing C where it was not needed, we are unnecessarily having to spend time finding out pieces here and there in the huge code structure. WINE is recieving more interest than ever, and we can only encourage people to join us by giving something they too can reuse, and people who really work for WINE are those types who start writing their own code if they find that tracing down a function and it's references will take more time. For example, whatever I have gone through (which is VERY little BTW..), I still feel that implementing many tools like winemenubuilder or winefile would have been better in C++ Infact, I intent to do some experimentation after Xmas (I am having my semester exams now, so ..) Hope what I said reaches you all ;) Season's greetings Subhobroto <snip> On Thu, 11 Dec 2003 Shachar Shemesh wrote : >I'm sorry, it has been YEARS since I wrote anything OLE related (my very first Windows program was an OLE server, hand coded, that did a shell extension. That was my only interaction with OLE). As such, I will not presume to decide whether that statement is correct or not. </snip snip, snip..>

2 1

Re: Adding support for a USB device
by Rolf Kalbermatter Dec. 11, 2003

Dec. 11, 2003

Message: 2 Date: Tue, 9 Dec 2003 14:56:16 -0800 Subject: Adding support for a USB device From: Dan Timis <timis(a)museresearch.com> To: wine-devel(a)winehq.org Hi, >I need help with supporting a particular USB device under wine. I have >to start by saying that although I am an experienced C/C++ programmer >with some Linux experience, I have almost no Windows or wine experience. > >The Windows code for which I need to provide support uses CreateFile() >to get a handle to the device. The name of the device is something >like "\\.\MyDevice0" "\\.\MyDevice1" and so on. Then, the code uses >DeviceIoControl() to read and write from/to the device. The >requirement is not to change the windows code. > >I looked through the wine code and I found this in device.c: > >static const struct VxDInfo VxDList[] > >I could add another entry into the table and write a deviceio handler >(BOOL (*deviceio)(DWORD, LPVOID, DWORD, LPVOID, DWORD, LPDWORD, >LPOVERLAPPED);). I wrote some test code in Linux using libusb reading >and writing to the device so I know what to do inside the deviceio >handler. > >Is this the right approach? If so, what do I need to do to get >CreateFile to return the right handle? I think it really depends on the type of device and the possibility to rewrite the device driver or not. \\.\MyDevice0 is just a device driver name which at some point is registered in the registry with the appropriate VXD, SYS, or WDM driver file. If you know the exact DeviceIOControls called into that driver with its parameters and all, you could rewrite the VXD, SYS or WDM driver to call directly the appropriate Unix device driver calls and maybe compile it as a Winelib driver. With a bit hacking in the CreateFile function it should be possible to call such a driver over DeviceIOControl or you could add the according code to the above mentioned VXDList. >Or should I write an external driver that gets loaded by wine? If so, >how would I do that? What are the chances that the Windows driver for >this device would just work with wine? If you don't know these details and want to use the original device driver you are probably out of luck. The current CreateFile implementation is not really up to the task of loading an external native device driver and invoke it over the DeviceIOControl (which could probably be remedied with a little hacking at this point) and what is much more problematic there is little or no support for a lot of the Windows kernel services most device driver usually expect to be able to call. When they are not able to link to one or more of those functions at load time, loading of the device driver will simply fail in Wine, as it does with normal DLL files under all Win32 implementations, too. Rolf Kalbermatter

3 3

Crash early in running msiexec.exe
by Dan Kegel Dec. 11, 2003

Dec. 11, 2003

This is on RH9 SMP with wine-20031118. Trying to run the MS SFU 3.0 (hey, I got it for $5 from that special offer they ran on slashdot a couple weeks ago...) setup.exe from the commandline yields the crash: Unhandled exception: page fault on read access to 0x0049002e in 32-bit code (0x400b73fd). In 32-bit mode. 0x400b73fd (NTDLL.DLL.RtlInitAnsiString+0x19 in NTDLL.DLL): repne scasb %es:(%edi) Wine-dbg>bt Backtrace: =>0 0x400b73fd (NTDLL.DLL.RtlInitAnsiString+0x19 in NTDLL.DLL) (ebp=4071e8f8) 1 0x400b7628 (NTDLL.DLL.RtlCreateUnicodeStringFromAsciiz+0x20 in NTDLL.DLL) (ebp=4071e918) 2 0x407bf5ad (USER32.DLL.MessageBoxIndirectA+0x119 in USER32.DLL) (ebp=4071e984) 3 0x407bf422 (USER32.DLL.MessageBoxExA+0x5e in USER32.DLL) (ebp=4071e9c4) 4 0x407bf38f (USER32.DLL.MessageBoxA+0x23 in USER32.DLL) (ebp=4071e9e4) 5 0x004010f7 (msiinst.exe.EntryPoint+0xf7 in msiinst.exe) (ebp=00000001) Seems a shame to bail out so early. Any suggestions for which --debugmsg channel to turn on? Best I could find was +process,+ntdll,+string which output the following right before the crash: ... trace:string:wvsnprintfA "Y:\\instmsi.exe /D:E:\\IXP001.TMP\\" trace:process:CreateProcessW app (null) cmdline L"E:\\IXP001.TMP\\msiinst.exe /i instmsi.msi REBOOT=REALLYSUPRESS /q" trace:process:find_exe_file looking for L"E:\\IXP001.TMP\\msiinst.exe" trace:process:find_exe_file Trying native exe L"E:\\IXP001.TMP\\msiinst.exe" trace:ntdll:NtReadFile (0x34,(nil),(nil),(nil),0x4051dca0,0x4051dd44,0x00000040,(nil),(nil)),partial stub! trace:ntdll:NtReadFile (0x34,(nil),(nil),(nil),0x4051dca0,0x4051dcdc,0x00000004,(nil),(nil)),partial stub! trace:ntdll:NtReadFile (0x34,(nil),(nil),(nil),0x4051dca0,0x4051dd24,0x00000014,(nil),(nil)),partial stub! trace:process:CreateProcessW starting L"E:\\IXP001.TMP\\msiinst.exe" as Win32 binary trace:process:__wine_kernel_init starting process name=L"E:\\IXP001.TMP\\msiinst.exe" file=0x4 argv[0]="E:\\IXP001.TMP\\msiinst.exe" trace:ntdll:NtReadFile (0x4,(nil),(nil),(nil),0xbfffd438,0xbfffd4dc,0x00000040,(nil),(nil)),partial stub! trace:ntdll:NtReadFile (0x4,(nil),(nil),(nil),0xbfffd438,0xbfffd474,0x00000004,(nil),(nil)),partial stub! trace:ntdll:NtReadFile (0x4,(nil),(nil),(nil),0xbfffd438,0xbfffd4bc,0x00000014,(nil),(nil)),partial stub! trace:process:__wine_kernel_init starting Win32 binary L"E:\\IXP001.TMP\\msiinst.exe" - Dan

2 4

Re: PATCH for Bugs 1844 and 1845
by Andreas Rosenberg Dec. 11, 2003

Dec. 11, 2003

I sent two patches about a week ago. The first one: "Bug 1844: Point Size in DLG_TEMPLATE may be negative" made it into the CVS (I browsed with: http://cvs.winehq.com/cvsweb) The second "Bug 1845: Return values of CharUpperA and CharLowerA" did not. Any reasons to reject this patch? I also wrote an conformance test for this problem. Did the case mentioned on the WINE web site happen? "Rejected patches might receive a note in the wine-devel mailing list, and accidentally ignored patches will disappear into a silent, featureless void. Please resubmit if this happens to your patch." -- Andy

2 1

Re: Patch for bug 1848 - TrackPopupMenu returns wrong result, when menu is canceled
by Dimitrie O. Paun Dec. 11, 2003

Dec. 11, 2003

On December 11, 2003 01:20 pm, Andreas Rosenberg wrote: > + if (!(menu = MENU_GetMenu( hmenu ))) > + { > + SetLastError(ERROR_INVALID_MENU_HANDLE); /* - added by A.Rosenberg > 2003.12.11 */ + return FALSE; > + } No need to add the 'added by ...' comment, it uglifies the code needlessly. That info is available in the log. Also, please try to follow the style of the file, nowhere do we use this bracketing style. -- Dimi.

1 0

multi-level subdirs under dlls/
by Dimitrie O. Paun Dec. 11, 2003

Dec. 11, 2003

Hi folks, I know people are concerned right now with more important matters, but given that (1) we're cleaning up the tree, and (2) we're getting close to 0.9, I figured it maybe time to bring this up. Namely, under dlls/ we have by and large a flat structure, with the exception of a few 'special' cases (there's always have to be special cases :/). I find this rather upsetting, for the following reasons: -- the organization is confusing since it implies some sort of dependency that's not there (they are all .dlls) -- it makes grepping so much more difficult. Instead of the simple: grep BLAH dlls/*/*.[ch] we need to resort to find, etc. -- it makes scripts in general needlessly complicated -- it hides those parts in the depth of tree -- it is inconsistent with the rest of our DLLs Now, I know that this is mainly historical, but why not fix it? Yeah, we're going to loose a bit of CVS history, but not quite, because the move can mark that so in the log. So we're only making 'cvs log' on a few files a bit more complicated, but we're simplifying every day operation by so much. I think it's a clear win. Here is the list of the offending DLLs: ddraw/d3ddevice ddraw/dclipper ddraw/ddraw ddraw/direct3d ddraw/dpalette ddraw/dsurface dinput/joystick dinput/keyboard dinput/mouse gdi/enhmfdrv gdi/mfdrv msacm/imaadp32 msacm/msg711 msacm/msadp32 msacm/winemp3 msvideo/msrle32 user/dde wineps/data winmm/joystick winmm/mcianim winmm/mciavi winmm/mcicda winmm/mciseq winmm/mciwave winmm/midimap winmm/wavemap winmm/wineoss winmm/winearts winmm/winealsa winmm/winenas winmm/wineaudioio winmm/winejack Pretty please... -- Dimi.

3 3

Partial success: RoughDraft 2.11
by Dan Kegel Dec. 11, 2003

Dec. 11, 2003

On a whim, I tried out RoughDraft 2.11 under wine-20031118 this morning. It installed and ran with some anomolies (e.g. the installer's EULA doesn't display at all!, .doc import works really poorly, a few pixels misplaced here and there, can't invoke web browser to display help), but it might be good enough for some users. It's a free download at http://www.rsalsbury.co.uk/rd.htm and I recommend it as a test app. His FAQ says no Linux or Mac port is planned, so there must be interest out there, and he'd probably be tickled pink if Wine improved to the point where it ran his app well enough for aunt Tilly to use. Sources not available but the author seems like a good guy, and would probably be willing to work with us if we really needed it (especially if we fixed a few things first, like that EULA display problem). - Dan

3 2

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha Dec. 11, 2003

Dec. 11, 2003

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he would let his elves use C++ in WINE. (Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', and you can make your wishes at 'wine-devel[at]winehq.com'..) You see, Santa was always so good - he answered people's prayers and got together his obedient elves to run Win32 on Non-Windows platforms! However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain C, and thus developments in those areas were soon in limbo. But that could be solved using yet another language called C++ - if only Santa would let it be. Oh please Santa ! Let us adultrate WINE with C++, please. It's not that we will rewrite everything in C++ once we get the green signal - things like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but what about MFC, COM, OLE ? Not that I expect to compile native MFC source using WineLib, but at least we can write the runtimes so that native MFC apps can atleast run under WINE ? DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM and already our implementations have structure object pointers running wild, whereas encapsulation would have done away with it ! As a simple explanation, we might take our 'This' hack wheras C++ would let have us use it as 'this' without even us worrying about it ! Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX source as I do not have a graphics base at all ..) where initializing a few member variables from a constructor would have done away with some redundancy. Most of the time we are passing around multilevel pointers when a simple reference would have done: For example a call like Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )'] can be made to a simple Stream_LoadString(sString); using C++ if we had the prototype rewritten to 'static HRESULT Stream_LoadString(LPWSTR& pstr )' and making it a member function of IStream (and thus the 'IStream* stm' and 'BOOL unicode' would be member variables..) We have code like that all over the place whenever COM etc comes into play and "That's Not A Good Thing(TM)" ! Please give us the green card - alternately, a new test branch may also be created just to see if C++ would work.All C++ based modfications would goto that tree. If that test branch works and delivers, it maybe merged into the main WINE tree, otherwise if it fails to deliver just remove it after a stipulated period ! If WINE stuck to C only because some platforms do not support C++, then will Win32 apps run on such OS at all ? Things like SPARC do not need MS Apps at all (though SPARC has C++..) For a expert discussion on C++ please see http://www.research.att.com/~bs/blast.html Microsoft themselves use C++ : <quote> Microsoft: Literally everything at Microsoft is built using various flavors of Visual C++ - mostly 6.0 and 7.0 but we do have a few holdouts still using 5.0 :-( and some products like Windows XP use more recent builds of the compiler. The list would include major products like: Windows XP Windows NT (NT4 and 2000) Windows 9x (95, 98,

9 12

dlls/oleaut32/tests/vartype.c problems
by Gerald Pfeifer Dec. 11, 2003

Dec. 11, 2003

The new file dlls/oleaut32/tests/vartype.c, add by the following commit revision 1.1 date: 2003/12/11 05:25:44; author: julliard; state: Exp; Jon Griffiths <jon_p_griffiths(a)yahoo.com> Test almost all of the low level variant functions adds a couple of warnings: vartype.c:4118: warning: integer constant is too large for "long" type vartype.c:4118: warning: integer constant is too large for "long" type vartype.c:4118: warning: integer constant is too large for "long" type vartype.c:4119: warning: integer constant is too large for "long" type vartype.c:4119: warning: integer constant is too large for "long" type vartype.c:4119: warning: integer constant is too large for "long" type The problem is, that in the use of EXPECTDEC(0,0,0,0x100000000), the constant is 0x100000000 is too large for both long and unsigned long. This could be addressed by writing it as 0x100000000ULL (unsigned long long), but in that case the uses in the EXPECTDEC macro seem wrong, as they cast the value to long and unsigned long, respectively. Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 0

Re: oleaut32 low level tests
by Dmitry Timoshkov Dec. 11, 2003

Dec. 11, 2003

"Jon Griffiths" <jon_p_griffiths(a)yahoo.com> wrote: > Jon Griffiths <jon_p_griffiths(a)yahoo.com> > > +dlls/oleaut32/tests/vartype.c dlls/oleaut32/tests/Makefile.in > Test almost all of the low level variant functions The only failure I have here: vartype.c:3340: Test failed: hres=0x0, type=8 (should be VT_BSTR), *bstr='1' It's again win2k SP4 with Russian locale. -- Dmitry.

1 0

six months+ being #1 at rpmseek
by Tom Dec. 11, 2003

Dec. 11, 2003

Hi, I sent this mail : http://www.winehq.org/hypermail/wine-devel/2003/06/0581.html to wine-devel almost six months ago about wine being the #1 download at rpmseek. I've kept a check on our status and we have been there #1 download and we have never dropped below the #1 spot in the last six months.. I'm not sure how many downloads were getting from them per day, week, month but were on top and that is saying something! Tom

2 1

Suggestion - don't require sane and artsc
by Bill Medland Dec. 10, 2003

Dec. 10, 2003

(Having just been caught by this again !!) It would be nice if in the distributions we dynamically detected libartsc and libsane rather than requiring them. When someone is installing on a small computer they will tend to exclude irrelevant packages like scanner and sound software when they don't have a scanner or speakers. (This paricularly relates to the RedHat 8.0 rpms) -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

6 9

winfile fails in windowcreateex
by Rein Klazes Dec. 10, 2003

Dec. 10, 2003

Hi, winfile (from a win98 installation) that I use to track problems with 16 bit file dialog fails today: | 0030:Call USER.452: CREATEWINDOWEX(00000000,129701a8 "WFS_Frame",12970efa "File Manager",02cf0000,0029,0046,03c0,02c0,0000,0000,1296,00000000) ret=1277:164f ds=1297 | 0030:Call kernel32.GlobalFindAtomA(403de6a0 "WFS_Frame") ret=407e1496 | 0030:Ret kernel32.GlobalFindAtomA() retval=0000c039 ret=407e1496 | trace:win:WIN_CreateWindowEx "File Manager" "WFS_Frame" ex=00000000 style=02cf0000 41,70 960x704 parent=(nil) menu=(nil) inst=0x1296 params=(nil) | trace:win:dump_window_styles style: WS_CLIPCHILDREN WS_CAPTION WS_SYSMENU WS_THICKFRAME WS_GROUP WS_TABSTOP WS_MINIMIZEBOX WS_MAXIMIZEBOX | trace:win:dump_window_styles exstyle: | trace:win:WIN_CreateWindowEx winproc type is 1 (WIN_PROC_16) | 0030:Call kernel32.GetExePtr(00001296) ret=407af5db | 0030:Ret kernel32.GetExePtr() retval=000011af ret=407af5db | 0030:Call ntdll.RtlAllocateHeap(40340000,00000000,00000084) ret=407de8ce | 0030:Ret ntdll.RtlAllocateHeap() retval=403aed90 ret=407de8ce | 0030:Call ntdll.RtlNtStatusToDosError(c0000008) ret=407de9f0 | 0030:Ret ntdll.RtlNtStatusToDosError() retval=00000006 ret=407de9f0 | 0030:Call ntdll.RtlFreeHeap(40340000,00000000,403aed90) ret=407de9e1 | 0030:Ret ntdll.RtlFreeHeap() retval=00000001 ret=407de9e1 | trace:win:WIN_CreateWindowEx out of memory | 0030:Ret USER.452: CREATEWINDOWEX() retval=0000 ret=1277:164f ds=1297 I did not look at it myself, but maybe this is enough for a clue? Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 2

Using Wine to isolate a bug in OLE2 files from Gnumeric
by Jody Goldberg Dec. 10, 2003

Dec. 10, 2003

Hello, I maintain Gnumeric and have run into a problems when writing xls files larger than 13-14 meg. MS excel can read them, but promptly corrupts them. I had hoped this was a windows bug, but just in case I installed an older copy of cross over office with office 2k. That combination produced exactly the same sort of corruption. That is likely good news to wine developers, your emulation is excellent. It also means that the problem is clearly on my end. A sample file is http://www.gnome.org/~jody/bigfile.xls.bz2 (bunzip2 and keep a copy because it gets corrupted) Loading it into MS Excel works smoothly, but subsequent reloads fail and the file is corrupt. It seems like the extended meta block allocation tables are being lost for some reason. Are there any OLE2 file format experts about that might have some insight ? Many Thanks Jody PS Please CC me on responses, I am not subscribed to the list.

2 2

Status of winealsa patch
by Sylvain Petreolle Dec. 10, 2003

Dec. 10, 2003

Hi, My winalsa patch for alsa 1.0 support wasnt commited and there wasnt any feedback fo it. Another winealsa patch was commited after that, should I resubmit mine ? References : http://www.winehq.org/hypermail/wine-patches/2003/11/0342.html http://www.winehq.org/hypermail/wine-patches/2003/12/0047.html ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ____________________________________________________________________________________ Do You Yahoo!? -- Avec Yahoo! soyez au coeur de la récolte de dons pour le Téléthon. http://fr.promotions.yahoo.com/caritatif/

5 9

Re: Re: I made a wish, wrote a letter to Santa...
by Subhobroto Sinha Dec. 10, 2003

Dec. 10, 2003

To be honest, if you follow my previous posts, I DID write some C++. Albeit, that was not reallt necessary ... ;) Anyways, I will submit a pure C and a C++ version of future patches, sch that both work under the current WINE. After that, it will be upto Sir Julliard... Season's Greetings Subhobroto Sinha >On Wed, 10 Dec 2003 Sir Marcus Meissner wrote thus: >Read what Alexandre wrote. To paraphrase: > >"Feel free to write it in C++ and submit it when you are done." > >Ciao, Marcus >

1 0

Issues in typelib.c with installshield 7
by Andrew de Quincey Dec. 10, 2003

Dec. 10, 2003

Hi, today I've been trying to get an Installshield 7 installer going. I think I've seen reports from other people about having problems as well. The problems I've been having stem from the implementation of ITypeLib/ITypeInfo/etc in oleaut32. The first problem is as follows: Installshield has a TLB which contains a type hiererachy as follows: IDispatch : ISomething : : ISomething2 An instance of ISomething2 is created. Installshield attempts to look up a method which is only defined in ISomething. The lookup fails. This is because ISomething and ISomething2 inherit from IDispatch, and are marked as TKIND_DISPATCH in the typelib. However in the code, an upwards traversal of the type hierarchy is only done for the TKIND_INTERFACE. I've experimented with modifying the code so that it also does an upward traversal for TKIND_DISPATCH as well (as they are still interfaces which can inherit). It now finds the methods/values properly. (It still doesn't work as there are then reference count problems, but I'm looking into that.) However, can anyone confirm if my experimental modification is the correct behaviour? e.g. in ITypeInfo_fnGetIDsOfNames, I have changed it to if(This->TypeAttr.cImplTypes && (This->TypeAttr.typekind==TKIND_INTERFACE || This->TypeAttr.typekind==TKIND_DISPATCH)) {

3 7

Re: Sorry for spamming the list..
by Fabian Cenedese Dec. 10, 2003

Dec. 10, 2003

>I am really sorry for making multiple posts - I got the Rediffmail mailer's verification after 20 minutes (normally Yahoo!'s mailservers notify almost instantaneously..), but before I could realize it, my 4 messages had already been mailed out of the queue... > >This was the first time I was using an Indian mail server, and well as it turns out, it was slower than a USA server ?! I dont know about times but it also swallowed some text. Every mail ended at a different point and the rest was missing. bye Fabi

1 0

Using a windows dll from a winelib or possibly native linux app.
by Arthur Bergman Dec. 10, 2003

Dec. 10, 2003

Hi, I have been trying to develop an application using a vendor provided dll from an external vendor to work under linux. If we develop the app on a windows box and move it over to the wine environment it works, but it would be preferable to have a more native approach. So I tried using winelib and have progressed to a point where I have an application that compiles using the vendor supplied header files under gcc, and a vendor.dll.spec file that describes the DLL. However when I compile everything, the generated vendor.dll.so file does contain the correct symbols but they are undefined. Having played around using winemaker and winedump while trying to read up everything on winelib I am now stuck and not sure how to proceed forward. Thanks Arthur

5 4

Re: comdlg32 MSVC+PSDK patch
by Dimitrie O. Paun Dec. 10, 2003

Dec. 10, 2003

On December 9, 2003 08:47 pm, Steven Edwards wrote: > This one gets us about 60 to 70% of the way there on MSVC+PSDK. Cool. > Once I get > my hands around cleaning up the rest of the printer dialog I will give > a better status update on the PSDK problems I am having. Actually I'd be very interested in this. Maybe we get to do that status page after all :))) > I wanted to also cleanup some of my mess from the Win16/32 Split so I > made this dll look more like the winmm source layout. With this patch > you can rm -fr fontdlg.h and colordlg.h in wine/dlls/commdlg. This is all good, but: +typedef struct CCPRIVATE +{ + LPCHOOSECOLORW lpcc; /* points to public known data structure */ + int nextuserdef; /* next free place in user defined color array */ 1 (one) space indent?!? Please man, stick to 4-space indent, especially when the file was using 4 space indent. Such small indentation makes the code difficult to follow. I have to admit, my eyesight is not what it used to be... -- Dimi.

1 0

Re: Using a windows dll from a winelib or possibly native linux app.
by Jon Griffiths Dec. 10, 2003

Dec. 10, 2003

Hi Arthur, > the generated vendor.dll.so file does contain the correct > symbols but they are undefined. By any chance is the vendor dll implemented in C++? If not, this should work. If so, you have a bit of a problem, and one that no-one has seriously tried to overcome (or at least if they have, they haven't documented it). If the dll exports mangled names (_??xxx in the .spec file) then linking cannot occur when you build with gcc because gcc uses a different name mangling scheme. You would need to include stubs to call the real functions and export these with the gcc-mangled names, either by reimplementing the functions inside the dll, or calling through to the real dll with function pointers and GetProcAddress(). Are the vender dll/headers redistributable? Cheers, Jon __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

1 0