- wine-devel - winehq.org

Re: Fix kernel heap test
by Dimitrie O. Paun 16 Dec '03

16 Dec '03

On December 15, 2003 10:35 am, Hans Leidekker wrote: > The test succeeds on Wine. This is wrong of course, tests should > always succeed on Windows and either succeed on Wine or fail on > Wine and be marked todo_wine. Great, thanks for catching this. Our current implementation seems to be freeing memory on size=0, how can we check what Windows does? If it doesn't, we can just simpligy the code to this: Index: dlls/kernel/heap.c =================================================================== RCS file: /var/cvs/wine/dlls/kernel/heap.c,v retrieving revision 1.4 diff -u -r1.4 heap.c --- dlls/kernel/heap.c 27 Nov 2003 00:59:36 -0000 1.4 +++ dlls/kernel/heap.c 15 Dec 2003 16:19:04 -0000 @@ -615,37 +614,15 @@ SetLastError(ERROR_INVALID_HANDLE); } else #endif - if(size!=0) - { - hnew=hmem; - if(pintern->Pointer) - { - if((palloc = HeapReAlloc(GetProcessHeap(), heap_flags, - (char *) pintern->Pointer-HGLOBAL_STORAGE, - size+HGLOBAL_STORAGE)) == NULL) - hnew = 0; /* Block still valid */ - else - pintern->Pointer = (char *)palloc+HGLOBAL_STORAGE; - } - else - { - if((palloc=HeapAlloc(GetProcessHeap(), heap_flags, size+HGLOBAL_STORAGE)) - == NULL) - hnew = 0; - else - { - *(HGLOBAL *)palloc = hmem; - pintern->Pointer = (char *)palloc + HGLOBAL_STORAGE; - } - } - } + if(size == 0) size = 16; + hnew=hmem; + if(pintern->Pointer) palloc = HeapAlloc(GetProcessHeap(), heap_flags, size+HGLOBAL_STORAGE); + else palloc = HeapReAlloc(GetProcessHeap(), heap_flags, (char *) pintern->Pointer-HGLOBAL_STORAGE, size+HGLOBAL_STORAGE); + if (!palloc) hnew = 0; else { - if(pintern->Pointer) - { - HeapFree(GetProcessHeap(), 0, (char *) pintern->Pointer-HGLOBAL_STORAGE); - pintern->Pointer=NULL; - } + pintern->Pointer = (char *)palloc + HGLOBAL_STORAGE; + if (!pintern->Pointer) *(HGLOBAL *)palloc = hmem; } } } -- Dimi.

2 1

Re: Implement support for many MCIWndClass MCI_ and MCIWNDM_ messages
by Dimitrie O. Paun 16 Dec '03

16 Dec '03

On December 15, 2003 03:12 am, Dmitry Timoshkov wrote: > What remains to be done is a proper support for MCI_WINDOW > command in mciavi.drv. Cool stuff Dmitry! Now that this stuff is in the tree, would it be fair to mark this on the status page as 75% complete? What's still left to do? Eric was saying that we needed (before your patch): - missing extended styles, notification, MCIWNDM_* I guess you did the MCIWNDM_* stuff, but the notification is still a TODO. Is the TODO list still too big to be listed in its entirety? -- Dimi.

2 1

Re: Internally maintained end-to-end API documentation
by Brian Vincent (C) 16 Dec '03

16 Dec '03

> After reading Wine Weekly News Issue #200, (Congrats > by the way), I stumbled across the Wine Status Pages. Thanks. > In my humble opinion, this is a very dangerous and > volatile place to have it. It is volatile and there have definitely been instances of people wondering where documentation has disappeared to. > 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? SGML is the one document format To Rule Them All. XML is a subset of that. HTML is a subset of XML (and therefore SGML). Realistically, Wine could probably use XML for all its documents. But we use SGML since that was around first. We convert the SGML into various nice document formats depending on how it's used. If you know HTML then you won't have much of a problem marking up SGML. > 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. I wouldn't. Wine has lots of tools in use for building and searching documentation, not the least of which is "grep". > 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. I actually really like this idea. The standard C library is nicely documented in man pages, why shouldn't Win32 be the same way? I don't think we need another document format or repository (Side note, is it just me, or is the GNU texinfo format the stupidest form of documentation ever invented..) The important thing is, keep the documentation in a format that is easily modifiable by developers. Since most have a copy of CVS laying around that probably means keeping docs in a text format somewhere in the documentation/ directory. The scope of this project is huge. In some ways you're trying to recreate MSDN, and as Greg pointed out that documentation lives on real media in the hands of thousands of people. Yes, it might be nice to replicate that but copyright issues are something you'll need to be aware of. If you rewrite all of it by hand you definitely won't infringe on copyrights, but is there an easier way put it together? Something tells me there's already some resources out there that could be used as a foundation. Also, be sure to read the "Terms of Use" link at the bottom of msdn.microsoft.com. It may as well just say "You can only read our web pages." A quick search on Google alludes to people writing man pages for Win32. This was on a NetBSD mailing list: http://mail-index.netbsd.org/netbsd-bugs/2001/05/17/0008.html >Number: 12974 >Category: pkg >Synopsis: w32doc-borland - man pages for the win32 api >Confidential: no >Severity: non-critical >Priority: low >Responsible: pkg-manager >State: open >Class: change-request >Submitter-Id: net >Arrival-Date: Thu May 17 13:16:00 PDT 2001 >Closed-Date: >Last-Modified: >Originator: Ben Collver >Release: 1.5 >Organization: >Environment: >Description: >A set of Unix-like man pages for the Windows 32 API. This package creates >a new manual section (wb) containing man pages derived from a Windows >help file distributed by Borland for Delphi2. Once installed, you could for >example read the WinMain man page by typing "man wb WinMain". >This documentation is not as up-to-date as that in devel/w32doc. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

2 1

Re: TDI + NetBIOS = Network Neighborhood
by Luke Kenneth Casson Leighton 16 Dec '03

16 Dec '03

hi, wrote to the wine-devel mailing list about this one describing a few words about what's needed to be done to "support" your efforts. documentation. rfc1001.txt and rfc1002.txt - these describe NBT (netbios over tcp) and how to get: - datagrams (port 138) equivalent to UDP - sessions (port 139) equivalent to TCP - names (port 137) LISTEN UP! THIS IS EQUIVALENT TO DYNAMIC-DNS + DHCP! the last one of these needs careful explanation. in light of the recent attempts by the wireless IETF crowd to create a dynamic routing protocol is is _totally_ ironic that netbios got there first _by over twenty years_ - and that there is a FREE implementation for the taking, in nmbd. it's also pretty ironic because they've had to play catch-up with concepts like node status queries in additional extension draft rfcs, and they STILL haven't added the "name conflict" concept which is there to tell anyone that will listen that a name which is attempting to be claimed is being taken by someone else who won't give it back. port 137 _is_ actually dns, so if you happen to know of any wine-licensing compatible DNS client code then you can use that as the basis for your efforts. it's dns but it's extended: the names of the types of packets mean slightly different things; there is additional packet types to represent NAME_REGISTER and NAME_STATUS; there is also a different CNAME type to cope with netbios names; the "dns zone" is there it's called a "scope"; the "dns name" is "compressed" it's a brain-dead misnomer given that the name is actually expanded in some sort of stupid base-4 (no, not base-64, yes, that's right, base-4) encoding scheme that turns a 16-byte space-padded thing into an overbloated 64-byte monster. cifsbrow.txt. eek, it's been a while. have a look at www.cb1.com/~lkcl/ntdom. no, try this: http://www.monyo.com/technical/samba/rfc/ actually, first try this: http://ubiqx.org/cifs/References.html which will give you a better idea of what the other one contains: the ftp://ftp.microsoft.com/developr/drg/CIFS directory appears to be inaccessible, now, which is just typical. basically you should read cifsbrow.txt in conjunction with rfc1001.txt and rfc1002.txt. SKIM THEM! YOU ONLY NEED A MINIMAL SUBSET OF THOSE DOCUMENTS FOR A CLIENT IMPLEMENTATION!!!! the only reason that you need to read those docs - skimmed - is because you need to know what you are going to be communicating with (not implementing, server-side, just connecting to, client-side). all you _really_ need is to be able to do a NetBIOS name query and also to be able to do a couple of SMB queries to obtain lists of servers. THAT IS ALL THAT A CLIENT-SIDE NETWORK NEIGHBOURHOOD BROWSER IS. REALLY! if you're implementing this from scratch, however, expect to allocate about ... mmm ... anywhere between four and eight weeks. i _thoroughly_ recommend that you investigate finding some dns client code to adapt and save yourself some time with decoding port 137. also, while you're at it, you might want to next focus on the contents of the ntnp.doc file which was last available with the ms-dev that contained visual studio 4.3. ntnp.doc stands for nt network provider and it had a companion "client-side" document to describe the other bit that went with it. basically there is a "redirector" protocol on both client _and_ server-side that covers browsing. these two protocols "merge" the network neighbourhoods into one big happy family, such that netware's network neighbourhood can be installed and cooperate happily with the smb network neighbourhood can be installed and cooperate happily with the kerberos-domain-based network neighbourhood and it was all one big happy family yippee. so, whilst you may believe that it is best to implement the network neighbourhood browsing functions as "direct" as possible, if you ever install the "client for netware" under wine and then wonder why it doesn't appear in the network neighbourhood, remember what i said in the paragraph above!! l.

1 0

Vacation
by Alexandre Julliard 15 Dec '03

15 Dec '03

Folks, There won't be any commits for a while, since I'm leaving now for a vacation in Switzerland, where I won't have net access. Assuming I survive the deprivation, I'll be back in two weeks. I hope you all have nice holidays, and I look forward to finding a few hundred patches in my mailbox when I get back... -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Fix ntdll test
by Alexandre Julliard 15 Dec '03

15 Dec '03

Hans Leidekker <hans(a)it.vu.nl> writes: > Uncomment some tests in rtlstr.c and wrap them in todo_wine{} instead. You can't do that, many of these tests succeed, which is not allowed inside todo_wine. And please try a 'make test' when you change a test, as already explained there's no point in submitting a patch that causes make test to fail. -- Alexandre Julliard julliard(a)winehq.com

2 1

netapi32 and NetBIOS
by Luke Kenneth Casson Leighton 15 Dec '03

15 Dec '03

[sent also to samba-technical mailing list] hi, i've just been alerted to the netbios work in wine (hooray!) as part of an effort to get the network neighbourhood going (yippee!). there is a problem, which i can help overcome. the problem is this: imagine that there is no TCP/IP stack in linux. imagine that TCP/IP runs in two separate user-space services, both of which are GPL'd: the TCP service is a fork-on-demand one that binds to all interfaces, and the UDP service is even worse, it's a single-process running a state machine. let's pretend that neither of the processes understand anything but Web services, and now you want to add SMTP, or worse, HTTPS. you have to consider hard-coding and linking into a paired monolith of programs, and you have a licensing and logistical nightmare that is totally unacceptable for practical purposes. this is the situation that is faced by wine, because samba, which consists of two programs, smbd and nmbd, "controls" the NetBIOS transport, from both a server _and_ (due to some bugs in Windows) also a client perspective. a flawed attempt to make it possible to cut-in to the NetBIOS equivalent of Dynamic-DNS-plus-DHCP (the NBNS system on port 137) was added in 2000 into nmbd, however from the Wine perspective this is totally useless because the code to access the bypass mechanism is GPL'd (tdb - trivial database). happily there is a convenient way round the mess, because it is possible to create the equivalent of a "Network Address Translation" service, and working code along these lines, which maintained a state machine of NetBIOS connections, was created over three years ago. nmbd needs to talk via this NAT service, so does nmblookup and, once the code is all there, so does Wine's Network Neighbourhood browsing code. at present, all you have to do to get the Wine "Network Neighbourhood" code to work is to disable samba, which is going to be totally impractical for most people. it is not _yet_ necessary for such a service to be created, but by the time the NetBIOS code in wine is released, it will _become_ necessary. if anyone wants to sponsor me [pay money] to revive the experiments i made in late 1999 / early 2000 in order to implement a NetBIOS "NAT" service, please contact me. l. -- -- expecting email to be received and understood is a bit like picking up the telephone and immediately dialing without checking for a dial-tone; speaking immediately without listening for either an answer or ring-tone; hanging up immediately and then expecting someone to call you (and to be able to call you). -- every day, people send out email expecting it to be received without being tampered with, read by other people, delayed or simply - without prejudice but lots of incompetence - destroyed. -- please therefore treat email more like you would a CB radio to communicate across the world (via relaying stations): ask and expect people to confirm receipt; send nothing that you don't mind everyone in the world knowing about...

1 0

uxtheme clips to much
by hatky 15 Dec '03

15 Dec '03

I know these are stubs but since they were added more of the splash screen and the top of the main application of Trillian has been cut off freeware at: http://download.com.com/3000-2150-10047473.html?part=trillian&subj=dlpagtag… home page at: http://www.ceruleanstudios.com/downloads/ Hatky. __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

2 2

Extended window flag
by Fabian Cenedese 15 Dec '03

15 Dec '03

Hi I have an application where I get the styles from a window with GetWindowLong(m_hWnd, GWL_EXSTYLE); In Windows I get 0x00000110 but in wine I get 0x40000110. From the wine headers (mine seem to old) I get this means 'managed by the system'. Is this something wine specific? Do I need to pay attention to this? If it's a valid Windows flag why isn't it set in Windows? If it's just wine specific can I just mask it out? Thanks bye Fabi

3 6

Re: Running Wine under MS SFU under Wine ... ?
by ea＠iol.it 15 Dec '03

15 Dec '03

> My real point is - SFU is yet another set of windows > programs we can use to test wine, may as well grab a > copy while they're 'free'. SFU3 contains also the POSIX personality for NT/2k. Does Wine run native NT apps yet?

1 0

Wine Segmentation fault
by Fabian Cenedese 15 Dec '03

15 Dec '03

Hi I have a problem with starting wine itself. After trying the CodeWeavers wine I wanted to get clean again and removed everything I could find only slightly wine related (/usr/bin, /usr/local... etc). I even removed my cvs of wine of a few days ago. Then I made a fresh checkout and did the complete install with wineinstall. But still after this whole procedure I cannot start wine. Any ideas? Knoppix (Kernel 2.4.22) fabi@lx_fabi:/usr/local/bin$ gdb wine GNU gdb 5.3-debian Copyright 2002 Free Software Foundation, Inc. .. snip .. This GDB was configured as "i386-linux"... (gdb) run Starting program: /usr/local/bin/wine Program received signal SIG32, Real-time event 32. 0x40046fc4 in pthread_getconcurrency () from /lib/libpthread.so.0 (gdb) bt #0 0x40046fc4 in pthread_getconcurrency () from /lib/libpthread.so.0 #1 0x40046e08 in pthread_getconcurrency () from /lib/libpthread.so.0 #2 0x400463f2 in pthread_create () from /lib/libpthread.so.0 #3 0x00110de6 in get_threading () at glibc.c:61 #4 0x00110e2e in main (argc=1, argv=0xbffffc74) at glibc.c:73 Thanks bye Fabi

3 4

Re: PATCH: old freetype patch / FT_Get_First_Char
by Pouech Eric DMI AEI CAEN 15 Dec '03

15 Dec '03

> + if(!!pFT_Get_First_Char || (pFT_Get_First_Char( ft_face, &dummy ) < 0x100)) me thinks two bangs are one too much A+

2 1

Re: Running Wine under MS SFU under Wine ... ?
by Dan Kegel 15 Dec '03

15 Dec '03

Greg wrote: > On Sunday 14 December 2003 09:02 pm, Dan Kegel wrote: > >>I recently posted with problems running Microsoft's >>Services for Unix under Wine. I only tried it out >>of morbid curiosity, actually, and because MS was >>offering it for free. The free offer expired, but >>it's back again for a little while; slashdot.org >>seems to be running banner ads for it. I'd encourage >>any of you who even *might* be tempted to try this >>out to go order the CD-ROM. It would be way bitchin' >>cool if we could nest Wine and MS SFU (I seem to recall >>we can't nest Wine in Cygwin for some technical reason, >>but who knows, maybe SFU won't have the same problem). > > Don't get your hopes up; they are nothing to write home about. OK, I have to confess, I was drunk when I wrote that :-) My real point is - SFU is yet another set of windows programs we can use to test wine, may as well grab a copy while they're 'free'. - Dan

1 0

Re: Resend: Another fix for kernel file test
by Alexandre Julliard 14 Dec '03

14 Dec '03

Hans Leidekker <hans(a)it.vu.nl> writes: > Tested on Win2k and Win98. MoveFile returns ERROR_ALREADY_EXISTS > when the destination exists. > > -Hans > > Changelog > MoveFile returns ERROR_ALREADY_EXISTS, not ERROR_FILE_EXISTS You need to fix the code too, or add a todo_wine; I can't commit tests that fail. -- Alexandre Julliard julliard(a)winehq.com

3 5

Winmm resources and WINE Resource Compiler
by Steven Edwards 14 Dec '03

14 Dec '03

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 14 Dec '03

14 Dec '03

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 14 Dec '03

14 Dec '03

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 14 Dec '03

14 Dec '03

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 14 Dec '03

14 Dec '03

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 14 Dec '03

14 Dec '03

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@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 14 Dec '03

14 Dec '03

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 13 Dec '03

13 Dec '03

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 13 Dec '03

13 Dec '03

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 13 Dec '03

13 Dec '03

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 13 Dec '03

13 Dec '03

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 13 Dec '03

13 Dec '03

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 13 Dec '03

13 Dec '03

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 13 Dec '03

13 Dec '03

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 13 Dec '03

13 Dec '03

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@newstar.rinet.ru

2 3

Core DLL's Status Section
by Tom 13 Dec '03

13 Dec '03

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 12 Dec '03

12 Dec '03

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 12 Dec '03

12 Dec '03

"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 12 Dec '03

12 Dec '03

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 12 Dec '03

12 Dec '03

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 12 Dec '03

12 Dec '03

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 12 Dec '03

12 Dec '03

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 12 Dec '03

12 Dec '03

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 12 Dec '03

12 Dec '03

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 12 Dec '03

12 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

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 11 Dec '03

11 Dec '03

"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 11 Dec '03

11 Dec '03

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 10 Dec '03

10 Dec '03

(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@mercuryspeed.com http://webhome.idirect.com/~kbmed

6 9

winfile fails in windowcreateex
by Rein Klazes 10 Dec '03

10 Dec '03

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 10 Dec '03

10 Dec '03

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 10 Dec '03

10 Dec '03

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 10 Dec '03

10 Dec '03

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 10 Dec '03

10 Dec '03

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 10 Dec '03

10 Dec '03

>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 10 Dec '03

10 Dec '03

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 10 Dec '03

10 Dec '03

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 10 Dec '03

10 Dec '03

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

rpcrt4 and rpcss with WINE and ReactOS
by Steven Edwards 10 Dec '03

10 Dec '03

Hello, Ok I know this going to start YALD (Yet Another Long Discussion) that wont go anywhere right away but...... ReactOS is getting ready to do a major import of the WINE dlls as you guys know due to my repeated cross-postings to Wine-devel and ros-kernel. When we compile rpcrt and ole32 from WINE with some hacks we can make it work under ReactOS but I would like to develop a implementation that works properly without dirty hacking. I dont know much about WINEs rpcss other than whats in the comments of the code and for that matter I dont know much about Windows rpcss. Can we share these componates? How are we going to break compatiblity by doing this? Thanks Steven __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

3 5

Adding support for a USB device
by Dan Timis 09 Dec '03

09 Dec '03

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? 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? Thanks, Dan Timis Muse Research, Inc.

2 1

Re: Winewrap change
by Alexandre Julliard 09 Dec '03

09 Dec '03

Shachar Shemesh <wine-patches(a)shemesh.biz> writes: > Slight change to winewrap > Changelog > Shachar Shemesh <winecode(a)shemesh.biz> > tools/winewrapper > > * Add tools into path for wine Hmmm, which program do you need from tools at run time? -- Alexandre Julliard julliard(a)winehq.com

2 2

Sorry for spamming the list..
by Subhobroto Sinha 09 Dec '03

09 Dec '03

Hello 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 ?! Regards Subhobroto Sinha

1 0

Re: wine/dlls/oleaut32/tests vartest.c
by Jon Griffiths 09 Dec '03

09 Dec '03

Hi Dmitry, > vartest.c:4151: Test failed: VarAbs: expected 0x0,5,1.1, got 0x80020005,0,0 > vartest.c:4217: Test failed: VarNot: expected 0x0, got 0x80020008 vt 20|0x0 > vartest.c:4217: Test failed: VarNot: expected 0x0, got 0x80020008 vt 21|0x0 > vartest: 526958 tests executed, 0 marked as todo, 3 failures. Does this patch fix it? Jon __________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/

2 1

DirectX Status Section
by Tom 09 Dec '03

09 Dec '03

Hi, Here is my first draft anyone have any comments?, constructive criticism? Tom

1 0

Help for OLEAUT32 DLL problem
by Robert Iver 09 Dec '03

09 Dec '03

Having a spot of trouble getting this function implemented in Wine so I can install a program for my job. It is basically a VB app that interfaces with a MySQL server database. I have heard that I cannot use a native DLL to do the job since it is OLE, so I have been trying to write a stub for it. Unfortunately, this is my first try at developing for Wine and I have writer's block. The function I am trying to implement is GetRecordInfoFromGuids. Could anyone out there write a basic stub for this program, so I can implement it and at least have an example to work with???? BTW, I have installed DCOM98, Crystal Reports and SQL Network Client Utility with no problems..

3 2

Forte Agent 2.0 (closed beta)
by Boris 'pi' Piwinger 09 Dec '03

09 Dec '03

Hi! I am new to the list and have Linux at home since last Thursday. I am still having some problems getting Forte Agent to work under Wine, but I am involved into (closed) beta testing for Forte Agent for many years and we just got the first shot at 2.0 which will change a lot anyway. Some problems are gone, but some serious problems are new. It is the aim of Forte to have Agent run under Wine. So they asked me to invite Wine developers to join the beta testing people so both sides can see what needs to be done. People on the Agent beta list are in very close contact (I really enjoy it) to the progammer Mark Sidell, he really get's the things done we suggest:-)) If you are a Wine developer and would like to join, please let me know, I'll forward it to the guys at Forte. pi

6 8

Re: wine/dlls/oleaut32/tests vartest.c
by Dmitry Timoshkov 09 Dec '03

09 Dec '03

"Alexandre Julliard" <julliard(a)winehq.org> wrote: > Log message: > Jon Griffiths <jon_p_griffiths(a)yahoo.com> > Fix the tests to pass when locale settings are user-overriden. > Fix those tests which pass now. > Test copying, formatting, VarAbs, VarNot. New tests for VarAbs and VarNot fail for me on win2k SP4 (Russian locale): vartest.c:1760:======== Testing VarUI1FromXXX ======== vartest.c:1848:======== Testing VarUI2FromXXX ======== vartest.c:1935:======== Testing VarUI4FromXXX ======== vartest.c:2021:======== Testing VarI1FromXXX ======== vartest.c:2087:======== Testing VarI2FromXXX ======== vartest.c:2132:======== Testing VarI4FromXXX ======== vartest.c:2176:======== Testing VarR4FromXXX ======== vartest.c:2223:======== Testing VarR8FromXXX ======== vartest.c:2243:======== Testing VarDateFromXXX ======== vartest.c:2298:======== Testing VarBoolFromXXX ======== vartest.c:2354:======== Testing VarBSTRFromXXX ======== vartest.c:2573:======== Testing Hi-Level Variant API ======== vartest.c:2658:======== Testing different VARTYPES ======== vartest.c:3831:Skipping VarFormatNumber tests as decimal seperator is ',' vartest.c:3987:Skipping VarFormat tests for non english language vartest.c:4151: Test failed: VarAbs: expected 0x0,5,1.1, got 0x80020005,0,0 vartest.c:4217: Test failed: VarNot: expected 0x0, got 0x80020008 vt 20|0x0 vartest.c:4217: Test failed: VarNot: expected 0x0, got 0x80020008 vt 21|0x0 vartest: 526958 tests executed, 0 marked as todo, 3 failures. -- Dmitry.

1 0

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 09 Dec '03

09 Dec '03

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

2 1

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 09 Dec '03

09 Dec '03

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 makin

1 0

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 09 Dec '03

09 Dec '03

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 M

1 0

I made a wish, wrote a letter to Santa...
by Subhobroto Sinha 09 Dec '03

09 Dec '03

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 makin

1 0

Re: regedit: consistent formatting
by Lionel Ulmer 09 Dec '03

09 Dec '03

On Mon, Dec 08, 2003 at 12:03:00AM -0500, Dimitrie O. Paun wrote: > Only whitespace changes. Unfortunately, the formatting was > all messed up by having tabs of 4 and 8 chars (I said it > before, and I'll say it again: the only sane way of dealing > with tabs is to always use the standard size of 8 chars. > Anything else is too complicated to ever work reliably). Just to flame a bit (the lists were a bit quiet lately) : the only sane way to dealing with TABs is when TABs are used properly (ie by an editor that uses them only to go to the current C indenting level and uses spaces for everything that comes after). With such an editor, tab size does not matter at all. No idea if Emacs / Vi can be used to work like that :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

6 10

Question about libwine_unicode functions and others in WINE
by Steven Edwards 08 Dec '03

08 Dec '03

Hello, We are looking at porting more code from WINE to ReactOS and I am having trouble understanding the need for libwine_unicode as a shared library. Some of the functions that it exports such as CompareString are implemented in ntdll as RtlCompareString and then also used in shlwapi as per a recent patch. Wouldnt it better to import the function from ntdll and hide libwine_unicode or make the parts that we need to share a static library? In ReactOS we have created NT compatible NLS files. Could WINE do this also and dump libwine_nicode? Also I was looking at the HeapAlloc stuff in WINE and code we have ported from ReactOS such as the FormatMessage function in kernel32. Doesnt kernel32 HeapAlloc and friends map on top of ntdll RtlHelpAlloc? Can we submit patches to WINE so that everything just calls RtlHeapAlloc so we dont have to change the sources? Thanks Steven __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

7 19

ATI driver crashes the system with wine
by Gerhard W. Gruber 08 Dec '03

08 Dec '03

I tried to install the ATI 3D acceleration for my card Radeon 9800XT. So far I didn'tsucced and I currently have to use Mesa for that. Now I managed to get at least the fglrx driver working with agpgart but when I use this then my system immediatly crashes when I try to run Agent from wine. I doubt that Agent is the cuplrit, so I guess this is something in wine. The screen goes simply blank and I can't see anything. I have to power off. When I disable the agpgart module I can run wine as well. My system: Kernel 2.4.22 (kernel.org) Suse 8.2 pro (with the drivers from the latest release). Wine is the CVS download from today (I just downloaded it about an hour ago and installed it). Everything else works fine. When I run glxgears it works, even though I have only 400 FPS because of the missing 3D acceleration. Any ideas whats wrong there or how I can debug this? Maybe this will give me a clue as whats wrong with my 3D acceleration as well. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu

4 5

Re: wine/windows painting.c
by Marcelo Duarte 08 Dec '03

08 Dec '03

This patch caused a regression in Winamp 2.91, and the top window is not repainted. I use with the folowing modifications in the ~/.wine/config: ; Winamp 2.91 runs good, but the title is eated. In desktop is better. [AppDefaults\\winamp.exe\\x11drv] "Desktop" = "560x700" Em Sex 05 Dez 2003 01:42, Alexandre Julliard escreveu: > ChangeSet ID: 10338 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/12/04 22:42:43 > > Modified files: > windows : painting.c > > Log message: > In RDW_ValidateParent, get rid of the parent update region if it is > empty after the validation, to avoid a useless WM_PAINT. > > Patch: http://cvs.winehq.com/patch.py?id=10338 > > Old revision New revision Changes Path > 1.88 1.89 +9 -1 wine/windows/painting.c Index: wine/windows/painting.c diff -u wine/windows/painting.c:1.88 wine/windows/painting.c:1.89 --- wine/windows/painting.c:1.88 Sun Dec 7 05:54:18 2003 +++ wine/windows/painting.c Sun Dec 7 05:54:18 2003 @@ -379,7 +379,15 @@ ptOffset.x = rect.left - rectParent.left; ptOffset.y = rect.top - rectParent.top; OffsetRgn( hrg, ptOffset.x, ptOffset.y ); - CombineRgn( wndParent->hrgnUpdate, wndParent->hrgnUpdate, hrg, RGN_DIFF ); + if (CombineRgn( wndParent->hrgnUpdate, wndParent->hrgnUpdate, hrg, RGN_DIFF ) == NULLREGION) + { + /* the update region has become empty */ + DeleteObject( wndParent->hrgnUpdate ); + wndParent->hrgnUpdate = 0; + wndParent->flags &= ~WIN_NEEDS_ERASEBKGND; + if( !(wndParent->flags & WIN_INTERNAL_PAINT) ) + add_paint_count( wndParent->hwndSelf, -1 ); + } OffsetRgn( hrg, -ptOffset.x, -ptOffset.y ); } } -- Marcelo Duarte

2 2

Status : Multimedia section
by Tom 07 Dec '03

07 Dec '03

Hi, Here is the new layout of the Multimedia section of the "Status Dll's" page. May I ask what you guys here think of it?, constructive criticism? Tom

5 10

Re: small file reorganisation
by Alexandre Julliard 06 Dec '03

06 Dec '03

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > I hope Alexandre will not got mad about the introduced circular dep > (kernel32 => (delay) winedos => kernel32). Since, we're now building > the DLLs through the .spec files, I assumed, since it no longer > impacts the make system, it would be ok. I don't think that's a good idea, especially since winedos is not a standard dll. And IMO it's preferable to have kernel export _lclose16 which is a standard API, than replacing it by a new DisposeFileHandle function that doesn't correspond to anything on Windows. -- Alexandre Julliard julliard(a)winehq.com

2 4

Thoughts about fixing bug 1848
by Andreas Rosenberg 06 Dec '03

06 Dec '03

I was thinking about fixing the bug 1848. Here are parts of the involved functions. See my comments/questions with multiple *** inside: ------------------------------- BOOL WINAPI TrackPopupMenu( HMENU hMenu, UINT wFlags, INT x, INT y, INT nReserved, HWND hWnd, const RECT *lpRect ) { BOOL ret = FALSE; MENU_InitTracking(hWnd, hMenu, TRUE, wFlags); /****** returns always TRUE */ /* Send WM_INITMENUPOPUP message only if TPM_NONOTIFY flag is not specified */ if (!(wFlags & TPM_NONOTIFY)) SendMessageW( hWnd, WM_INITMENUPOPUP, (WPARAM)hMenu, 0); if (MENU_ShowPopup( hWnd, hMenu, 0, x, y, 0, 0 )) /****** this may return FALSE if MENU_GetMenu fails */ /****** how can we decide if the call failed, or a click outside the menu happened ???? */ /****** I would suggest to let MENU_TrackMenu return -1 if clicked outside the menu and zero if */ /****** something fails - this requires no other change */ ret = MENU_TrackMenu( hMenu, wFlags | TPM_POPUPMENU, 0, 0, hWnd, lpRect ); MENU_ExitTracking(hWnd); /***** returns always TRUE */ if( (!(wFlags & TPM_RETURNCMD)) && (ret != FALSE) ) /****** FALSE = 0*/ ret = TRUE; return ret; } static INT MENU_TrackMenu( HMENU hmenu, UINT wFlags, INT x, INT y, HWND hwnd, const RECT *lprect ) { ..... INT executedMenuId = -1; .... /*** If I understood things right - simply return executedMenuId */ /*** suggestion: return (executedMenuId) */ /*** could somebody please comment, if my assumption is correct? */ return ((executedMenuId != -1) ? executedMenuId : 0); }

1 0

winetest WineHQ integration
by Ferenc Wagner 06 Dec '03

06 Dec '03

Hi, so we should start working out this one, too. First let me sketch the present picture. I've got a directory structure like this: | + 20030829 + 95 | + 95_michael | + 98 | + 98_joel | + 98_kevin | + etc. | ` 2003s | + 20030916 (similar) ` 20031127 (similar) That is, one directory for each test collection and one subdirectory for each submission of it. For a new submission I create a directory, copy the results.txt into it, create a reporter.txt next to it, add it to archs in the Makefile, and make. For a new test collection I create missing.dll.txt's (presently dsound), Makefile and tests.zip in a new directory. Changes needed at least: 1. Windows version detected automatically. 2. Tester name and contact (?) included in the results. 3. Automatically generated tags, probably simple incremental numbers. 4. Which submission should be the principal one? The first? 5. Makefile at one level higher, archs variable autodetected. But before doing anything, we definitely need the opinion of the website maintainer. We need a very simple CGI to handle the file uploads. Presently it is <http://afavant.elte.hu/~wferi/wine/winetest.pl>. All of the present machinery is available in that directory: Makefile, dissect, gather and the other ingredients. I don't know much about web design or anything about WineHQ's inner workings. What sort of output should we produce? I think the above is enough for a start... Feri.

4 6

Re: System tray integration
by Mike Hearn 05 Dec '03

05 Dec '03

Hi Alexandre, This has missed the last two commits. Is this codes presence in shell32 really a blocking issue? If so then I'd note that quite a lot of people have problems caused by the lack of this patch (can't quit apps etc). thanks -mike On Sun, 2003-11-30 at 16:16, Mike Hearn wrote: > Hi, > > This patch updates my system tray patch to work with the new atom > interning code, fixes a few bugs and replaces the per-icon mutex with a > global one. The critical section handling should therefore be much less > broken now. > > Yes, I know it should be in wineshell.exe but for now this will do, and > the code can always be moved later. > > thanks -mike > > ChangeLog: > Implement support for XEMBED based system trays > > Index: dlls/shell32/systray.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/systray.c,v > retrieving revision 1.24 > diff -u -r1.24 systray.c > --- dlls/shell32/systray.c 24 Oct 2003 04:23:37 -0000 1.24 > +++ dlls/shell32/systray.c 30 Nov 2003 16:08:37 -0000 > @@ -1,11 +1,11 @@ > /* > - * Systray > + * System tray handling code (client side) > * > - * Copyright 1999 Kai Morich <kai.morich(a)bigfoot.de> > + * Copyright 1999 Kai Morich <kai.morich(a)bigfoot.de> > + * Copyright 2003 Mike Hearn <mike(a)theoretic.com> > * > - * Manage the systray window. That it actually appears in the docking > - * area of KDE or GNOME is delegated to windows/x11drv/wnd.c, > - * X11DRV_WND_DockWindow. > + * This code creates a window with the WS_EX_TRAYWINDOW style. The actual > + * environment integration code is handled inside the X11 driver. > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -42,7 +42,17 @@ > #include "commctrl.h" > #include "wine/debug.h" > > -WINE_DEFAULT_DEBUG_CHANNEL(shell); > +WINE_DEFAULT_DEBUG_CHANNEL(systray); > + > +static CRITICAL_SECTION systray_lock; > +static CRITICAL_SECTION_DEBUG critsect_debug = > +{ > + 0, 0, &systray_lock, > + { &critsect_debug.ProcessLocksList, &critsect_debug.ProcessLocksList }, > + 0, 0, { 0, (DWORD)(__FILE__ ": system tray") } > +}; > +static CRITICAL_SECTION systray_lock = { &critsect_debug, -1, 0, 0, 0, 0 }; > + > > typedef struct SystrayItem { > HWND hWnd; > @@ -51,12 +61,11 @@ > struct SystrayItem *nextTrayItem; > } SystrayItem; > > -static SystrayItem *systray=NULL; > -static int firstSystray=TRUE; /* defer creation of window class until first systray item is created */ > +static SystrayItem *systray = NULL; > +static int firstSystray = TRUE; /* defer creation of window class until first systray item is created */ > > static BOOL SYSTRAY_Delete(PNOTIFYICONDATAA pnid); > > - > #define ICON_SIZE GetSystemMetrics(SM_CXSMICON) > /* space around icon (forces icon to center of KDE systray area) */ > #define ICON_BORDER 4 > @@ -74,21 +83,26 @@ > { > HDC hdc; > PAINTSTRUCT ps; > - > + TRACE("hwnd=%p, msg=0x%x\n", hWnd, message); > switch (message) { > case WM_PAINT: > { > RECT rc; > SystrayItem *ptrayItem = systray; > - > + int top; > + EnterCriticalSection(&systray_lock); > + > while (ptrayItem) { > - if (ptrayItem->hWnd==hWnd) { > + if (ptrayItem->hWnd == hWnd) { > if (ptrayItem->notifyIcon.hIcon) { > hdc = BeginPaint(hWnd, &ps); > GetClientRect(hWnd, &rc); > - if (!DrawIconEx(hdc, rc.left+ICON_BORDER, rc.top+ICON_BORDER, ptrayItem->notifyIcon.hIcon, > + /* calculate top so we can deal with arbitrary sized trays */ > + top = ((rc.bottom-rc.top)/2) - ((ICON_SIZE)/2); > + if (!DrawIconEx(hdc, (ICON_BORDER/2), top, ptrayItem->notifyIcon.hIcon, > ICON_SIZE, ICON_SIZE, 0, 0, DI_DEFAULTSIZE|DI_NORMAL)) { > ERR("Paint(SystrayWindow %p) failed -> removing SystrayItem %p\n", hWnd, ptrayItem); > + LeaveCriticalSection(&systray_lock); > SYSTRAY_Delete(&ptrayItem->notifyIcon); > } > } > @@ -97,10 +111,10 @@ > ptrayItem = ptrayItem->nextTrayItem; > } > EndPaint(hWnd, &ps); > + LeaveCriticalSection(&systray_lock); > } > break; > > - case WM_MOUSEMOVE: > case WM_LBUTTONDOWN: > case WM_LBUTTONUP: > case WM_RBUTTONDOWN: > @@ -110,7 +124,8 @@ > { > MSG msg; > SystrayItem *ptrayItem = systray; > - > + /* relay the event to the tooltip */ > + EnterCriticalSection(&systray_lock); > while ( ptrayItem ) { > if (ptrayItem->hWnd == hWnd) { > msg.hwnd=hWnd; > @@ -125,15 +140,17 @@ > } > ptrayItem = ptrayItem->nextTrayItem; > } > + LeaveCriticalSection(&systray_lock); > } > - /* fall through */ > + /* fall through, so the message is sent to the callback as well */ > > case WM_LBUTTONDBLCLK: > case WM_RBUTTONDBLCLK: > case WM_MBUTTONDBLCLK: > { > SystrayItem *ptrayItem = systray; > - > + /* iterate over the currently active tray items */ > + EnterCriticalSection(&systray_lock); > while (ptrayItem) { > if (ptrayItem->hWnd == hWnd) { > if (ptrayItem->notifyIcon.hWnd && ptrayItem->notifyIcon.uCallbackMessage) { > @@ -147,9 +164,18 @@ > } > ptrayItem = ptrayItem->nextTrayItem; > } > + LeaveCriticalSection(&systray_lock); > } > break; > > + case WM_NOTIFYFORMAT: > + { > + TRACE("Received WM_NOTIFYFORMAT, showing the tray window\n"); > + ShowWindow(hWnd, SW_SHOW); > + return (DefWindowProcA(hWnd, message, wParam, lParam)); > + } > + > + > default: > return (DefWindowProcA(hWnd, message, wParam, lParam)); > } > @@ -169,7 +195,7 @@ > wc.hInstance = 0; > wc.hIcon = 0; > wc.hCursor = LoadCursorA(0, (LPSTR)IDC_ARROW); > - wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1); > + wc.hbrBackground = (HBRUSH) COLOR_WINDOW; > wc.lpszMenuName = NULL; > wc.lpszClassName = "WineSystray"; > > @@ -181,30 +207,21 @@ > } > > > -BOOL SYSTRAY_ItemInit(SystrayItem *ptrayItem) > -{ > +DWORD WINAPI SYSTRAY_ThreadProc(LPVOID p1) { > + SystrayItem *ptrayItem = (SystrayItem *)p1; > + MSG msg; > RECT rect; > - > - /* Register the class if this is our first tray item. */ > - if ( firstSystray ) { > - firstSystray = FALSE; > - if ( !SYSTRAY_RegisterClass() ) { > - ERR( "RegisterClass(WineSystray) failed\n" ); > - return FALSE; > - } > - } > - > + > /* Initialize the window size. */ > rect.left = 0; > rect.top = 0; > rect.right = ICON_SIZE+2*ICON_BORDER; > rect.bottom = ICON_SIZE+2*ICON_BORDER; > > - ZeroMemory( ptrayItem, sizeof(SystrayItem) ); > /* Create tray window for icon. */ > ptrayItem->hWnd = CreateWindowExA( WS_EX_TRAYWINDOW, > - "WineSystray", "Wine-Systray", > - WS_VISIBLE, > + "WineSystray", "Windows System Tray", > + 0, > CW_USEDEFAULT, CW_USEDEFAULT, > rect.right-rect.left, rect.bottom-rect.top, > 0, 0, 0, 0 ); > @@ -222,31 +239,73 @@ > ERR( "CreateWindow(TOOLTIP) failed\n" ); > return FALSE; > } > + > + /* Enter the message loop */ > + while (GetMessageA (&msg, 0, 0, 0) > 0) { > + TranslateMessage (&msg); > + DispatchMessageA (&msg); > + } > + > + TRACE("Shutting down system tray thread\n"); > + if(ptrayItem->notifyIcon.hIcon) > + DestroyIcon(ptrayItem->notifyIcon.hIcon); > + if(ptrayItem->hWndToolTip) > + DestroyWindow(ptrayItem->hWndToolTip); > + > + return 0; > +} > + > +BOOL SYSTRAY_ItemInit(SystrayItem *ptrayItem) > +{ > + DWORD threadID; > + > + /* Register the class if this is our first tray item. */ > + EnterCriticalSection(&systray_lock); > + if ( firstSystray ) { > + firstSystray = FALSE; > + if ( !SYSTRAY_RegisterClass() ) { > + ERR( "RegisterClass(WineSystray) failed\n" ); > + LeaveCriticalSection(&systray_lock); > + return FALSE; > + } > + } > + LeaveCriticalSection(&systray_lock); > + > + ZeroMemory( ptrayItem, sizeof(SystrayItem) ); > + > + /* We need to run the system tray window in a separate thread, as otherwise if the originating thread > + stops processing messages, the tray window will hang. If another part of the application then does > + for instance a FindWindow call, this can deadlock the application. */ > + if (!CreateThread(NULL, 0, SYSTRAY_ThreadProc, (LPVOID) ptrayItem, 0, &threadID)) { > + ERR("Could not create system tray item thread\n"); > + return FALSE; > + } > return TRUE; > } > > > static void SYSTRAY_ItemTerm(SystrayItem *ptrayItem) > { > - if(ptrayItem->notifyIcon.hIcon) > - DestroyIcon(ptrayItem->notifyIcon.hIcon); > - if(ptrayItem->hWndToolTip) > - DestroyWindow(ptrayItem->hWndToolTip); > - if(ptrayItem->hWnd) > - DestroyWindow(ptrayItem->hWnd); > + /* MSDN says we shouldn't do this, but I can't see another way to make GetMessage() return zero */ > + PostMessageA(ptrayItem->hWnd, WM_QUIT, 0, 0); > return; > } > > > void SYSTRAY_ItemSetMessage(SystrayItem *ptrayItem, UINT uCallbackMessage) > { > + EnterCriticalSection(&systray_lock); > ptrayItem->notifyIcon.uCallbackMessage = uCallbackMessage; > + LeaveCriticalSection(&systray_lock); > } > > > void SYSTRAY_ItemSetIcon(SystrayItem *ptrayItem, HICON hIcon) > { > + EnterCriticalSection(&systray_lock); > ptrayItem->notifyIcon.hIcon = CopyIcon(hIcon); > + LeaveCriticalSection(&systray_lock); > + > InvalidateRect(ptrayItem->hWnd, NULL, TRUE); > } > > @@ -255,9 +314,11 @@ > { > TTTOOLINFOA ti; > > - strncpy(ptrayItem->notifyIcon.szTip, szTip, sizeof(ptrayItem->notifyIcon.szTip)); > + EnterCriticalSection(&systray_lock); > + strncpy(ptrayItem->notifyIcon.szTip, szTip, sizeof(ptrayItem->notifyIcon.szTip)); > ptrayItem->notifyIcon.szTip[sizeof(ptrayItem->notifyIcon.szTip)-1]=0; > - > + LeaveCriticalSection(&systray_lock); > + > ti.cbSize = sizeof(TTTOOLINFOA); > ti.uFlags = 0; > ti.hwnd = ptrayItem->hWnd; > @@ -280,10 +341,15 @@ > { > SystrayItem **ptrayItem = &systray; > > + TRACE("%p\n", pnid); > + > + EnterCriticalSection(&systray_lock); > /* Find last element. */ > while( *ptrayItem ) { > - if ( SYSTRAY_ItemIsEqual(pnid, &(*ptrayItem)->notifyIcon) ) > + if ( SYSTRAY_ItemIsEqual(pnid, &(*ptrayItem)->notifyIcon) ) { > + LeaveCriticalSection(&systray_lock); > return FALSE; > + } > ptrayItem = &((*ptrayItem)->nextTrayItem); > } > /* Allocate SystrayItem for element and add to end of list. */ > @@ -297,6 +363,7 @@ > SYSTRAY_ItemSetMessage(*ptrayItem, (pnid->uFlags&NIF_MESSAGE)?pnid->uCallbackMessage:0); > SYSTRAY_ItemSetTip (*ptrayItem, (pnid->uFlags&NIF_TIP) ?pnid->szTip :"", FALSE); > > + LeaveCriticalSection(&systray_lock); > TRACE("%p: %p %s\n", (*ptrayItem), (*ptrayItem)->notifyIcon.hWnd, > (*ptrayItem)->notifyIcon.szTip); > return TRUE; > @@ -307,8 +374,12 @@ > { > SystrayItem *ptrayItem = systray; > > + TRACE("%p\n", pnid); > + > + EnterCriticalSection(&systray_lock); > while ( ptrayItem ) { > if ( SYSTRAY_ItemIsEqual(pnid, &ptrayItem->notifyIcon) ) { > + LeaveCriticalSection(&systray_lock); > if (pnid->uFlags & NIF_ICON) > SYSTRAY_ItemSetIcon(ptrayItem, pnid->hIcon); > if (pnid->uFlags & NIF_MESSAGE) > @@ -321,6 +392,7 @@ > } > ptrayItem = ptrayItem->nextTrayItem; > } > + LeaveCriticalSection(&systray_lock); > return FALSE; /* not found */ > } > > @@ -329,6 +401,9 @@ > { > SystrayItem **ptrayItem = &systray; > > + TRACE("%p\n", pnid); > + > + EnterCriticalSection(&systray_lock); > while (*ptrayItem) { > if (SYSTRAY_ItemIsEqual(pnid, &(*ptrayItem)->notifyIcon)) { > SystrayItem *next = (*ptrayItem)->nextTrayItem; > @@ -338,10 +413,12 @@ > free(*ptrayItem); > *ptrayItem = next; > > + LeaveCriticalSection(&systray_lock); > return TRUE; > } > ptrayItem = &((*ptrayItem)->nextTrayItem); > } > + LeaveCriticalSection(&systray_lock); > > return FALSE; /* not found */ > } > Index: dlls/x11drv/event.c > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/event.c,v > retrieving revision 1.29 > diff -u -r1.29 event.c > --- dlls/x11drv/event.c 21 Nov 2003 21:48:36 -0000 1.29 > +++ dlls/x11drv/event.c 30 Nov 2003 16:08:37 -0000 > @@ -3,6 +3,7 @@ > * > * Copyright 1993 Alexandre Julliard > * 1999 Noel Borthwick > + * 2003 Mike Hearn > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -51,10 +52,15 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(event); > WINE_DECLARE_DEBUG_CHANNEL(clipboard); > +WINE_DECLARE_DEBUG_CHANNEL(systray); > > /* X context to associate a hwnd to an X window */ > extern XContext winContext; > > +extern Atom systray_selection; > +extern Window systray_window; > + > + > #define DndNotDnd -1 /* OffiX drag&drop */ > #define DndUnknown 0 > #define DndRawData 1 > @@ -1213,7 +1219,47 @@ > static void EVENT_ClientMessage( HWND hWnd, XClientMessageEvent *event ) > { > if (event->message_type != None && event->format == 32) { > - if (event->message_type == x11drv_atom(WM_PROTOCOLS)) > + if (event->message_type == x11drv_atom(MANAGER)) { > + if (event->data.l[1] == systray_selection) { > + TRACE_(systray)("New NETWM systray manager detected, id=%ld\n", event->data.l[2]); > + /* NOTE: It turns out that the ability to detect when a new tray applet joins the > + * desktop is not as helpful as you might think. In order to do something useful with it, > + * we would need to be able to "store" icons unmapped as children of the root window while > + * no tray applet is available. > + * > + * The basic problem is that tray icons are always destroyed when the applet is removed. > + * This is apparently an issue with X itself, which the upcoming XFIXES extension should hopefully > + * address. The EggTrayIcon code which will be soon moving into GTK+ doesn't attempt to handle this > + * situation, so for now neither do we. > + * > + * This is theoretically fixable in Wine with enough work, we just have to modify the code in > + * shell32/systray.c to save the image and recreate the window on demand. Exactly how the > + * communication between the x11drv and shell32 takes place is left as an excercise for the > + * reader. > + * -mike (3rd August 2003) > + */ > + } > + } else if (event->message_type == x11drv_atom(_XEMBED)) { > + char* opcode; > + switch (event->data.l[1]) { > + case 0: opcode = "XEMBED_EMBEDDED_NOTIFY"; break; > + case 1: opcode = "XEMBED_WINDOW_ACTIVATE"; break; > + case 2: opcode = "XEMBED_WINDOW_DEACTIVATE"; break; > + case 3: opcode = "XEMBED_REQUEST_FOCUS"; break; > + case 4: opcode = "XEMBED_FOCUS_IN"; break; > + case 5: opcode = "XEMBED_FOCUS_OUT"; break; > + case 6: opcode = "XEMBED_FOCUS_NEXT"; break; > + case 7: opcode = "XEMEBD_FOCUS_PREV"; break; > + case 10: opcode = "XEMBED_MODALITY_ON"; break; > + case 11: opcode = "XEMBED_MODALITY_OFF"; break; > + case 12: opcode = "XEMBED_REGISTER_ACCELERATOR"; break; > + case 13: opcode = "XEMBED_UNREGISTER_ACCELERATOR"; break; > + case 14: opcode = "XEMBED_ACTIVATE_ACCELERATOR"; break; > + default: opcode = "[Unknown opcode]"; break; > + } > + TRACE_(systray)("XEmbed message, opcode is %s : %ld\n", opcode, event->data.l[1]); > + /* we currently don't handle these messages */ > + } else if (event->message_type == x11drv_atom(WM_PROTOCOLS)) > handle_wm_protocols_message( hWnd, event ); > else if (event->message_type == x11drv_atom(DndProtocol)) > { > Index: dlls/x11drv/window.c > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/window.c,v > retrieving revision 1.65 > diff -u -r1.65 window.c > --- dlls/x11drv/window.c 21 Nov 2003 21:48:36 -0000 1.65 > +++ dlls/x11drv/window.c 30 Nov 2003 16:08:37 -0000 > @@ -4,6 +4,7 @@ > * Copyright 1993, 1994, 1995, 1996, 2001 Alexandre Julliard > * Copyright 1993 David Metcalfe > * Copyright 1995, 1996 Alex Korobka > + * Copyright 2003 Mike Hearn > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -24,6 +25,7 @@ > > #include <stdarg.h> > #include <stdlib.h> > +#include <stdio.h> > #ifdef HAVE_UNISTD_H > # include <unistd.h> > #endif > @@ -46,6 +48,7 @@ > #include "mwm.h" > > WINE_DEFAULT_DEBUG_CHANNEL(x11drv); > +WINE_DECLARE_DEBUG_CHANNEL(systray); > > extern Pixmap X11DRV_BITMAP_Pixmap( HBITMAP ); > > @@ -73,6 +76,7 @@ > "WM_PROTOCOLS", > "WM_DELETE_WINDOW", > "WM_TAKE_FOCUS", > + "MANAGER", > "KWM_DOCKWINDOW", > "DndProtocol", > "DndSelection", > @@ -81,6 +85,9 @@ > "_NET_WM_PID", > "_NET_WM_PING", > "_NET_WM_NAME", > + "_XEMBED_INFO", > + "_XEMBED", > + "_NET_SYSTEM_TRAY_OPCODE", > "XdndAware", > "XdndEnter", > "XdndPosition", > @@ -103,6 +110,14 @@ > "text/richtext" > }; > > +/* for XDG systray icons */ > +Atom systray_selection; > +Window systray_window; > +#define SYSTEM_TRAY_REQUEST_DOCK 0 > +#define SYSTEM_TRAY_BEGIN_MESSAGE 1 > +#define SYSTEM_TRAY_CANCEL_MESSAGE 2 > + > + > static LPCSTR whole_window_atom; > static LPCSTR client_window_atom; > static LPCSTR icon_window_atom; > @@ -354,11 +369,60 @@ > size_hints->min_height = size_hints->max_height; > size_hints->flags |= PMinSize | PMaxSize; > } > + if (win->dwExStyle & WS_EX_TRAYWINDOW) { > + /* force the window to be the correct width */ > + size_hints->min_width = GetSystemMetrics(SM_CXSMICON) + 5; /* give some padding to make icons not bunched up */ > + } > + > XSetWMNormalHints( display, data->whole_window, size_hints ); > XFree( size_hints ); > } > } > > +/*********************************************************************** > + * X11DRV_systray_dock_window > + * > + * Docks the given X window with the NETWM system tray. > + */ > +BOOL CALLBACK X11DRV_systray_dock_window( HWND hwnd, Display *display ) { > + WND* win = WIN_GetPtr((HWND)hwnd); > + struct x11drv_win_data *data = win->pDriverData; > + XEvent ev; > + unsigned long info[2]; > + LONG exstyle; > + > + /* is the window a tray window? */ > + if (IsWindowUnicode(hwnd)) > + exstyle = GetWindowLongW(hwnd, GWL_EXSTYLE); > + else > + exstyle = GetWindowLongA(hwnd, GWL_EXSTYLE); > + if ( !(exstyle & WS_EX_TRAYWINDOW) ) return TRUE; > + > + TRACE_(systray)("Docking tray icon 0x%x\n", (int)hwnd); > + > + > + /* set XEMBED protocol data on the window */ > + info[0] = 0; /* protocol version */ > + info[1] = 0; /* mapped = true */ > + XChangeProperty(display, data->whole_window, x11drv_atom(_XEMBED_INFO), x11drv_atom(_XEMBED_INFO), 32, PropModeReplace, (unsigned char*)info, 2); > + > + /* send the docking request message */ > + memset(&ev, 0, sizeof(ev)); > + ev.xclient.type = ClientMessage; > + ev.xclient.window = systray_window; > + ev.xclient.message_type = x11drv_atom(_NET_SYSTEM_TRAY_OPCODE); > + ev.xclient.format = 32; > + ev.xclient.data.l[0] = CurrentTime; > + ev.xclient.data.l[1] = SYSTEM_TRAY_REQUEST_DOCK; > + ev.xclient.data.l[2] = data->whole_window; > + XSendEvent(display, systray_window, False, NoEventMask, &ev); > + XSync(display, False); > + > + WIN_ReleasePtr(win); > + return TRUE; > +} > + > + > > /*********************************************************************** > * X11DRV_set_wm_hints > @@ -408,7 +472,7 @@ > set_size_hints( display, win ); > > /* systray properties (KDE only for now) */ > - if (win->dwExStyle & WS_EX_TRAYWINDOW) > + if ((win->dwExStyle & WS_EX_TRAYWINDOW) && (systray_window == None)) > { > int val = 1; > XChangeProperty( display, data->whole_window, x11drv_atom(KWM_DOCKWINDOW), > @@ -709,10 +773,19 @@ > static void create_desktop( Display *display, WND *wndPtr ) > { > X11DRV_WND_DATA *data = wndPtr->pDriverData; > - > + char *systray_buffer; > + > wine_tsx11_lock(); > winContext = XUniqueContext(); > XInternAtoms( display, (char **)atom_names, NB_XATOMS - FIRST_XATOM, False, X11DRV_Atoms ); > + > + /* we can't intern this with the rest as it depends on the screen we are connecting to */ > + systray_buffer = HeapAlloc(GetProcessHeap(), 0, sizeof(char)*20); > + sprintf(systray_buffer, "_NET_SYSTEM_TRAY_S%d", DefaultScreen(display)); > + systray_selection = XInternAtom(display, systray_buffer, False); > + HeapFree(GetProcessHeap(), 0, systray_buffer); > + > + > wine_tsx11_unlock(); > > whole_window_atom = MAKEINTATOMA( GlobalAddAtomA( "__wine_x11_whole_window" )); > @@ -1109,6 +1182,14 @@ > * we do a proper ShowWindow later on */ > if (wndPtr->dwStyle & WS_VISIBLE) cs->style |= WS_VISIBLE; > > + /* if it's a tray window, dock it */ > + if (wndPtr->dwExStyle & WS_EX_TRAYWINDOW) { > + /* get the tray window if present */ > + systray_window = XGetSelectionOwner(display, systray_selection); > + if (systray_window != None) > + X11DRV_systray_dock_window(hwnd, display); > + } > + > WIN_ReleaseWndPtr( wndPtr ); > return TRUE; > > Index: dlls/x11drv/x11drv.h > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/x11drv.h,v > retrieving revision 1.11 > diff -u -r1.11 x11drv.h > --- dlls/x11drv/x11drv.h 25 Nov 2003 03:27:38 -0000 1.11 > +++ dlls/x11drv/x11drv.h 30 Nov 2003 16:08:37 -0000 > @@ -387,6 +387,7 @@ > XATOM_WM_PROTOCOLS, > XATOM_WM_DELETE_WINDOW, > XATOM_WM_TAKE_FOCUS, > + XATOM_MANAGER, > XATOM_KWM_DOCKWINDOW, > XATOM_DndProtocol, > XATOM_DndSelection, > @@ -395,6 +396,9 @@ > XATOM__NET_WM_PID, > XATOM__NET_WM_PING, > XATOM__NET_WM_NAME, > + XATOM__XEMBED_INFO, > + XATOM__XEMBED, > + XATOM__NET_SYSTEM_TRAY_OPCODE, > XATOM_XdndAware, > XATOM_XdndEnter, > XATOM_XdndPosition, > > >

2 3

Re: Implement support for NETWM utility window type
by Mike Hearn 05 Dec '03

05 Dec '03

Hi Alexandre, This too missed the last couple of commits. Did I get the style stuff wrong? On Mon, 2003-12-01 at 00:40, Mike Hearn wrote: > ChangeLog: > Map (WS_EX_TOOLWINDOW & WS_CAPTION) to _NET_WM_WINDOW_TYPE_UTILITY. > This makes Delphi a bit easier to use, as floating palettes aren't > unmanaged anymore. > > Index: dlls/x11drv/x11drv.h > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/x11drv.h,v > retrieving revision 1.11 > diff -u -b -r1.11 x11drv.h > --- dlls/x11drv/x11drv.h 25 Nov 2003 03:27:38 -0000 1.11 > +++ dlls/x11drv/x11drv.h 1 Dec 2003 00:38:03 -0000 > @@ -395,6 +395,8 @@ > XATOM__NET_WM_PID, > XATOM__NET_WM_PING, > XATOM__NET_WM_NAME, > + XATOM__NET_WM_WINDOW_TYPE, > + XATOM__NET_WM_WINDOW_TYPE_UTILITY, > XATOM_XdndAware, > XATOM_XdndEnter, > XATOM_XdndPosition, > Index: dlls/x11drv/window.c > =================================================================== > RCS file: /home/wine/wine/dlls/x11drv/window.c,v > retrieving revision 1.65 > diff -u -b -r1.65 window.c > --- dlls/x11drv/window.c 21 Nov 2003 21:48:36 -0000 1.65 > +++ dlls/x11drv/window.c 1 Dec 2003 00:38:03 -0000 > @@ -81,6 +81,8 @@ > "_NET_WM_PID", > "_NET_WM_PING", > "_NET_WM_NAME", > + "_NET_WM_WINDOW_TYPE", > + "_NET_WM_WINDOW_TYPE_UTILITY", > "XdndAware", > "XdndEnter", > "XdndPosition", > @@ -119,7 +121,8 @@ > if (win->dwExStyle & WS_EX_TRAYWINDOW) return TRUE; > /* child windows are not managed */ > if (win->dwStyle & WS_CHILD) return FALSE; > - /* tool windows are not managed */ > + /* tool windows are not managed unless they have a caption */ > + if ((win->dwExStyle & WS_EX_TOOLWINDOW) && ((win->dwStyle & WS_CAPTION) == WS_CAPTION)) return TRUE; > if (win->dwExStyle & WS_EX_TOOLWINDOW) return FALSE; > /* windows with caption or thick frame are managed */ > if ((win->dwStyle & WS_CAPTION) == WS_CAPTION) return TRUE; > @@ -424,6 +427,12 @@ > XChangeProperty(display, data->whole_window, x11drv_atom(_NET_WM_PID), > XA_CARDINAL, 32, PropModeReplace, (char *)&i, 1); > > + /* map WS_EX_TOOLWINDOW to _NET_WM_WINDOW_TYPE_UTILITY */ > + if ((win->dwExStyle & WS_EX_TOOLWINDOW) && (win->dwStyle & WS_CAPTION)) { > + Atom a = x11drv_atom(_NET_WM_WINDOW_TYPE_UTILITY); > + XChangeProperty(display, data->whole_window, x11drv_atom(_NET_WM_WINDOW_TYPE), XA_ATOM, 32, PropModeReplace, (char*)&a, 1); > + } > + > mwm_hints.flags = MWM_HINTS_FUNCTIONS | MWM_HINTS_DECORATIONS; > mwm_hints.functions = 0; > if ((win->dwStyle & WS_CAPTION) == WS_CAPTION) mwm_hints.functions |= MWM_FUNC_MOVE; > @@ -785,6 +794,8 @@ > 0 ); > } > > + > + > /* non-maximized child must be at bottom of Z order */ > if ((win->dwStyle & (WS_CHILD|WS_MAXIMIZE)) == WS_CHILD) > { > > >

2 3

Who maintains the imagehlp dll?
by Andrew de Quincey 05 Dec '03

05 Dec '03

Now that I have IDA nearly sorted, I was wondering.. who maintains the imagehlp dll? It seems kinda empty, and I'm sure it was at one point more complete (I looked into wine some time ago). I ask this because about a year or so ago I got about 3/4 of the way through reverse engineering the Windows PDB formats (up to those supported by VS.NET). If I had an actual implementation goal in mind and feedback from people using it, I might actually be bothered to finish it off.... Incidentally, I have years of reverse engineering experience.. if anyone wants me to look at anything, feel free to drop me a line (for an example, see the recently released reverse engineered opensource nforce ethernet driver, forcedeth).

5 4

Re: wine/dlls/x11drv x11drv_main.c
by Rein Klazes 05 Dec '03

05 Dec '03

On Thu, 4 Dec 2003 15:59:51 -0600, you wrote: > Log message: > Initialize Xlib threading support to see what it breaks... Thanks for the warning! Just about everything here halts after a few minutes: | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) | err:ntdll:RtlpWaitForCriticalSection section 0x40380db0 "?" wait timed out in thread 000e, blocked by 0000, retrying (60 sec) The easiest way to reproduce it here is switching to another workspace and back again. After reversing the patch everything is as stable as before. Debian unstable, glibc 2.3.2 on standard kernel 2.4.22 - no nptl - and xfree86 4.2.1. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 4

SSTab, Tabctl32.ocx again
by Fabian Cenedese 05 Dec '03

05 Dec '03

Hi I have a VB6 program which fails on wine due to the Tab control SSTab from TabCtl32.ocx as other users have reported too. Should this already work? Is this part of the work of improving wine for VB programs? Maybe it's not the tab control itself but one of its parts. I made a trace and this is the part shortly before the error message comes: fixme:ole:SPCF_CreateInstance (0x412d2408,(nil),{7bf80980-bf32-101a-8bbb-00aa00300cab},0x40669ea4), creating stdpic with PICTYPE_NONE. trace:ole:OleCreatePictureIndirect (0x40911d28,0x212f53d8,1,0x40669ea4) trace:ole:OLEPictureImpl_Construct (0x40911d28) type = 0 0009:Call ntdll.RtlAllocateHeap(405e0000,00000008,00000050) ret=412941cd 0009:Ret ntdll.RtlAllocateHeap() retval=40669f00 ret=412941cd 0009:Call ntdll.RtlAllocateHeap(405e0000,00000000,00000028) ret=41281227 0009:Ret ntdll.RtlAllocateHeap() retval=40669f58 ret=41281227 0009:Call ntdll.RtlAllocateHeap(405e0000,00000008,00000028) ret=41281282 0009:Ret ntdll.RtlAllocateHeap() retval=40669f88 ret=41281282 trace:ole:ConnectionPointImpl_QueryInterface (0x40669f58)->({b196b286-bab4-101a-b69c-00aa00341d07}, 0x40669f3c) trace:ole:ConnectionPointImpl_AddRef (0x40669f58)->(ref=1) trace:ole:ConnectionPointImpl_Release (0x40669f58)->(ref=2) trace:ole:OLEPictureImpl_Construct returning 0x40669f00 trace:ole:OLEPictureImpl_QueryInterface (0x40669f00)->({7bf80980-bf32-101a-8bbb-00aa00300cab}, 0x40669ea4) trace:ole:OLEPictureImpl_AddRef (0x40669f00)->(ref=1) trace:ole:OLEPictureImpl_Release (0x40669f00)->(ref=2) trace:ole:OLEPictureImpl_QueryInterface (0x40669f00)->({00000109-0000-0000-c000-000000000046}, 0x40911dd8) trace:ole:OLEPictureImpl_AddRef (0x40669f00)->(ref=1) trace:ole:OLEPictureImpl_Load (0x40669f00,0x4182036c) 0009:Call ntdll.RtlAllocateHeap(405e0000,00000008,00000000) ret=412968dc 0009:Ret ntdll.RtlAllocateHeap() retval=40669fb8 ret=412968dc 0009:Call user32.CreateIconFromResourceEx(40669fb8,00000000,00000001,00030000,00000000,00000000,00000000) ret=41295ed6 0009:Call gdi32.DIB_BitmapInfoSize(40669fb8,00000000) ret=40b0ae1b 0009:Ret gdi32.DIB_BitmapInfoSize() retval=01780108 ret=40b0ae1b 0009:Ret user32.CreateIconFromResourceEx() retval=00000000 ret=41295ed6 fixme:ole:OLEPictureImpl_Load CreateIcon failed. trace:ole:OLEPictureImpl_Release (0x40669f00)->(ref=2) Looks like it's something with pictures that actually fails. Does this tell anyone anything? Do I need to re-register something else? Maybe some type library? Can I get more info with other debug channels? Or am I out of luck? Thanks bye Fabi

1 0

Status of InstallShield-Setup Engine
by Andreas Rosenberg 05 Dec '03

05 Dec '03

Hi! I'm new to this list. The company I'm working for, is developing software for Windows and as a personal Linux fan I was testing our software with Wine from time to time. The last tries (several month ago) were still pretting bad, but with the Wine from Suse 9.0 (snapshot from August 2003) there were only "trivial" errors (mostly conformance) which we were able to circumwent in our software. I tracked all problems and reported them als bugs: (1844, 1845, 1847, 1848) together with a patch for two of them. b.t.w I'm using a different eMail account with this mailing list as with the Wine Bugzilla. We have a customer, who already asked for a version of our software being able to run on Linux. What's seems to be a big problem, is the InstallShield Setup Engine we are using (like many others). A played around with it and it crashed in different ways. I looked into the bug list and found the rather old "meta bug" #170. Unfortunately the link inside is broken. Perhaps we can contribute in making the InstallShield Setup Engine work. Has anybody tracked what's causing the problem? I read about "global window handles", but this didn't gave me the right clue. Is it related with the API call FindWindow? Is the IS Setup Engine using multiple processes and trying to communicate via window messages or DDE? If anybody could point me in the right direction, this would be great. Otherwise it would be a waste of resources to debug/search stuff others already did. Regards Andy

5 5

Re: PATCH for Bugs 1844 and 1845
by Alexandre Julliard 05 Dec '03

05 Dec '03

Andreas Rosenberg <sonix2003(a)ctf-z.de> writes: > 1844: Point Size in DLG_TEMPLATE may be negative (with DS_SETFONT) > > Within Windows the pointSize parameter (for the FONT in the DLG_TEMPLATE > struct) may be a signed 16-bit integer. With WINE this integers get's > converted to an unsigned int resulting in huge font for the dialog. The size > of the dialog is being computed based on this font and results in invalid > parameters for CreateWindow, that may cause a termination of WINE. We detected > this problem testing our software with WINE. The fix for pointSize is OK, but why did you also change the sign of the font height in the CreateFont call? This doesn't look right. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: menu: nasty bug in menu tracking
by Alexandre Julliard 05 Dec '03

05 Dec '03

Andrew de Quincey <adq_dvb(a)lidskialf.net> writes: > The problem is that MSG.lParam is NOT necessarily in screen coordinates (even > though the comment I have removed says they are). As I can't trust the MSG.pt > either, this means using GetCursorPos() to determine the mouse position in > screen coordinates. This is wrong, you have to use lParam, as the comment says. And the coordinates are always in screen coords when we are tracking the menu. Something else must be going on here. -- Alexandre Julliard julliard(a)winehq.com

2 4

RE: menu: nasty bug in menu tracking
by Mike Jackson 05 Dec '03

05 Dec '03

Actually I think the code would work better like this:- if ((msg.message >= WM_MOUSEFIRST) && (msg.message <= WM_MOUSELAST)) { mt.pt.x = (short)LOWORD(msg.lParam); mt.pt.y = (short)HIWORD(msg.lParam); ClientToScreen(msg.hwnd,&mt.pt); -----Original Message----- From: wine-patches-admin(a)winehq.com [mailto:wine-patches-admin@winehq.com] On Behalf Of Andrew de Quincey Sent: Friday, 5 December 2003 8:45 AM To: wine-patches Subject: menu: nasty bug in menu tracking In IDA, the menus don't work correctly... as you move down a menu, the wrong item is highlighted if you move to a submenu.. after that, the wrong menu is opened and other bad things occur. The problem is that MSG.lParam is NOT necessarily in screen coordinates (even though the comment I have removed says they are). As I can't trust the MSG.pt either, this means using GetCursorPos() to determine the mouse position in screen coordinates. BTW: MSDN says this about the MSG.lParam value for WM_MOUSEMOVED events: lParam The low-order word specifies the x-coordinate of the cursor. The coordinate is relative to the upper-left corner of the client area. The high-order word specifies the y-coordinate of the cursor. The coordinate is relative to the upper-left corner of the client area.

2 1

Re: wine/ programs/Makefile.in ./configure.ac ./co ...
by Ferenc Wagner 05 Dec '03

05 Dec '03

Alexandre Julliard <julliard(a)winehq.org> writes: > Added files: > programs/winetest: winetest.h util.c send.c maketest main.c > Makefile.in .cvsignore First of all, thank you very much for adapting and putting this into the tree! Losing some of the automation is not a problem as we seldom have new modules to test. But we've got an error in the cross-configured tree: tba:/usr/local/src/wine/pe/dlls/msvcrt/tests/ $ make i586-mingw32msvc-gcc cpp.o file.o heap.o scanf.o testlist.o -o msvcrt_test.exe -L../../../dlls -lmsvcrt -L../../../libs/wine -lwine -L../../../libs/port -lwine_port -lm ../../../dlls/libmsvcrt.a(ds00464.o)(.text+0x0): multiple definition of `atexit' /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mingw32msvc/lib/crt2.o:/home/ron/devel/debian/mingw32-runtime/mingw32-runtime-3.2/build_dir/src/mingw-runtime-3.2/crt1.c:266: first defined here ../../../dlls/libmsvcrt.a(ds00332.o)(.text+0x0): multiple definition of `_onexit' /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mingw32msvc/lib/crt2.o:/home/ron/devel/debian/mingw32-runtime/mingw32-runtime-3.2/build_dir/src/mingw-runtime-3.2/crt1.c:274: first defined here make: *** [msvcrt_test.exe] Error 1 On the other hand, $ i586-mingw32msvc-gcc cpp.o file.o heap.o scanf.o testlist.o -o msvcrt_test.exe works all right, and makes winetest.exe build flawlessly. Best wishes, Feri.

4 4

direct X 9 and troubles ..
by Lars Segerlund 04 Dec '03

04 Dec '03

Hi, I don't know how far along the directX9 support in wine is, and I am having trouble getting a game to run to which there is a downloadable demo (http://www.gamershell.com/news_BMotoGP2BDemo.shtml) which I thought might be usefull. The question is, should this run ? Is there something I have configured wrongly ? ( I have tried it on two different machines with different settings and hardware + soft OpenGL and hardware OpenGL ). Still it beats me .. any help appreciated if only 'no this should not work' .. / regards, Lars Segerlund.

2 1

warning fixes in comctl32.dll
by Jonathan Wilson 04 Dec '03

04 Dec '03

I just posted a patch to the reactos list that gets whatever comctl32.dll reactos has building with -Wall -Werror. But I dont have a WINE tree or any way to "port" these fixes over to WINEHQ. Can someone do it for me?

2 1

Re: sysparams: slight optimisation for IDA 3
by Dmitry Timoshkov 04 Dec '03

04 Dec '03

"Andrew de Quincey" <adq_dvb(a)lidskialf.net> wrote: > Version 3 > + spi_idx = SPI_GETICONTITLELOGFONT; > + > + if (!spi_loaded[spi_idx]) > + { > + memcpy(lpLogFont, &iconTitleLogFont, sizeof(LOGFONTA)); > + break; > + } Sorry to bother you again, but probably the comparison statement needs to be reverted... -- Dmitry.

7 10

Sound capture issues...
by Thomas Brix Larsen 04 Dec '03

04 Dec '03

Hi list, in the voice com program Skype (www.skype.org), I'm able to hear other people but I can't talk to them myself. Does anyone have a clue why? I believe this program uses DirectX to capture voice input. Not implented? Greetings, --Thomas _________________ My worst enemy gave me a copy of Windows...

2 3

Font matching algorithms
by Mike Hearn 04 Dec '03

04 Dec '03

Hi, Recently Wine CVS has started always matching "System" to "Bitstream Vera Mono", and nothing I alter in the config file can seem to change it. This is kind of annoying as it's not a very good match, I'd rather it used Vera Sans, is there a way to override Wines choice? thanks -mike

1 0

Re: new old winetests
by Brian Vincent (C) 04 Dec '03

04 Dec '03

>> -- we're linking against ws2_32 >> Is this DLL available on all versions of Windows we >> want to run on? > >As far I know ><http://msdn.microsoft.com/library/en-us/winsock/winsock/windows_sockets_st art_page_2.asp> >yes. But I am not sure whether it is installed in the base >system or only an option if you want to have networking >(like on Win3.1). Probably not too many people would run >the tests on a standalone machine anyway, but who knows... I actually just ran into this the other night. I installed TaxCut 2003 (which, by the way, mostly works with a few native DLL's) when it didn't like Wine's ws2_32. According to the references built into TaxCut this wasn't part of the original Win95 that shipped. It came out shortly after as an add-on and was likely first included in OSR2. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

6 8

Re: Missing msvcmaker .cvsignores 1
by Jakob Eriksson 04 Dec '03

04 Dec '03

:-D Shachar Shemesh wrote: > Ferenc Wagner wrote: > >> There will be no further parts, sorry. >> >> Feri. >> >> >> > Nobody expects the Spanish Inquisition! Our chief weapon is suprise. > Suprise and fear. Fear and suprise. Are TWO weapons are fear, suprise, > and ruthless eficiency. >

1 0

JournalPlayBack hook
by Juan Antonio Boscá Lloret 03 Dec '03

03 Dec '03

Hello, I'm trying to use the JournalPlayBack hook in a Win32 application and it doesn't work. However it looks to work in 16 bits. Any idea? Thank you --------------------------------------------------------------- Juan Antonio Boscá Lloret Departamento Programación CAE, S.A. jabosca(a)edicurs.com ---------------------------------------------------------------

3 2

Question about simple profiling implementation
by Andrew de Quincey 03 Dec '03

03 Dec '03

Hi, the last thing I have to do with the profiling stuff is the trickiest: To decide what is the best way to determine the times. To get times that are useful, I'm using the RDTSC opcode (which returns the number of CPU clock cycles since the machine was powered on).. basically I've added a couple of defines to wine/debug.h: #define GET_COUNTER(__COUNTER) __asm__ __volatile__ ( "rdtsc" : "=a" (__COUNTER.LowPart), "=d" (__COUNTER.HighPart) ) and theres another, GET_ELAPSED which takes a start time, and calculates the difference. (BTW: I don't think these names are very good; I'm going to change them) The elapsed value is output when the relay trace for the function return is printed. I've also created a new script to analyse these to give you the average times, total times etc, and I've fixed tools/examine-relay to cope with the addition to the trace output. The problem is.. not all i386-derived CPUs support this feature. As far as I can see there are three ways of determining this. Which would people prefer? 1) Check in /proc/cpuinfo for the "tsc" flag. 2) I could write a short amount of assembly to interrogate the chip itself for this feature (a couple of instructions) 3) Use the existing QueryPerformanceCounter(). Personally, I'm favouring (2)... but what do other people think?

6 12

Re: debugger problems
by Chris Morgan 03 Dec '03

03 Dec '03

Nope, still doesn't appear to work. Rein, you see the same? Chris On Sunday 30 November 2003 11:08 am, Eric Pouech wrote: > Chris Morgan wrote: > > Still isn't working with build from todays cvs. Is this patch in there? > > it seems that AJ applied it after your mail had been sent > A+

5 10

Re: bc21en209 at Odin
by Dietrich Teickner 03 Dec '03

03 Dec '03

Hi Craig, The best way is for the future the first, removing '\\?\' in Odin and Wine. This way will need some times in odin, we are not prepaired for this, And I have no update access for wine. I will try to inform wine about the problem. I thing You have implemented this methods and You modify this without full forthing w98-api. This can us help for this build. We can test BC2.1 and can work with them as w2k(without , and we can also test the new api modifications. The switch should only force the w98 behavior in the path handling. For 'all', Odin and Wine can set the configuration-file. And Wine and Odin should work in the next time at the \\?\ problem. Please save also the last BC2.0 Build. Dietrich Scooter Support wrote: > Hi Dietrich, > > That would definitely cause problems in BC. We detect the Windows > version on startup and when running under WinNT4/2K/XP we use the \\?\ > notation for all file access, including sessions and rules. Under > Win9x we use the standard ANSI functions. > > In our current usage it wouldn't be a problem if ODIN simply removed > the \\?\ prefix and converted the paths back to ANSI. If it would be > easier I can add a command line switch to force BC to use the Win9x > behavior. > > Best Regards, > Craig > > > >>Hi Craig, > > >>I know where the problenm is in the comunication between BC21 and Odin. >>BC21 used only the long path notation for the filenames if the version >>set in Odin (Wine ?) as w2k or xp. If I set Win98 (nt4.0?), I have no >>problems with accessing folders. >>Currently is the \\?\h:\... notation only partialy supported in >>Odin (for eCS or OS/2) and in >>wine (for Linux). > > >>Start in native w98 ok, >>also in my xp >>Also in w98 in virtual PC. > > >>Can it be that many problems comes from the \\?\ prefix ? >>Also no access to the session database ? > > >>Best regards, >>Dietrich > > >>Log as w2k > > >>t01 ( 0): (FS=150B) KERNEL32: GetVersionExA 19ee88 >>t01 ( 0): (FS=150B) Kernel32:Odin profile:('WinVersion','Version',''): >>returning 'Win2000' >>t01 ( 0): (FS=150B) version 5.0 >>t01 ( 0): (FS=150B) build nr 893 >>t01 ( 0): (FS=150B) Platform Id 2 >>t01 ( 0): (FS=150B) szCSDVersion Service Pack 2 >>... >>t02 ( 0): attachThread to dll NTDLL.DLL >>t02 ( 0): attachThread to dll NTDLL.DLL DONE >>t02 ( 0): attachThread to dll GDI32.DLL >>t02 ( 0): attachThread to dll GDI32.DLL DONE >>t02 ( 0): KERNEL32: ResetEvent 33 >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: ResetEvent 2f >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: GetDriveTypeA 2003f1b8 >>t02 ( 1): KERNEL32: GetDriveType h:\ = 3 >>t02 ( 0): KERNEL32: GetDriveTypeA returned 3 >>t02 ( 0): KERNEL32: GetFileAttributesW 3016994 >>t02 ( 1): KERNEL32: SetLastError to 123 >>t02 ( 1): KERNEL32: GetFileAttributes of \\?\h:\ returned -1 >>t02 ( 0): KERNEL32: GetFileAttributesW returned ffffffff >>t02 ( 0): KERNEL32: GetLastError returned 123 >>t02 ( 0): KERNEL32: SetLastError to 123 >>t02 ( 0): KERNEL32: RaiseException eedfade 1 7 327fd80 >>t02 ( 1): KERNEL32: RaiseException(0eedfadeh) >>t02 ( 1): KERNEL32: RtlDispatchException entered >>t02 ( 1): Win32 exception chain: > > >>Log as w98 > > >>t01 ( 0): (FS=150B) KERNEL32: SetEnvironmentVariable HOMEPATH to \ >>t01 ( 0): (FS=150B) KERNEL32: GetVersionExA 19ee88 >>t01 ( 0): (FS=150B) Kernel32:Odin profile:('WinVersion','Version',''): >>returning 'Win98' >>t01 ( 0): (FS=150B) version 4.a >>t01 ( 0): (FS=150B) build nr 40a07ce >>t01 ( 0): (FS=150B) Platform Id 1 >>t01 ( 0): (FS=150B) szCSDVersion Win98 > > >>.. > > >>t02 ( 0): attachThread to dll GDI32.DLL >>t02 ( 0): attachThread to dll GDI32.DLL DONE >>t02 ( 0): KERNEL32: ResetEvent 33 >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: ResetEvent 2f >>t02 ( 0): KERNEL32: ResetEvent returned 1 >>t02 ( 0): KERNEL32: GetDriveTypeA 2003ea14 >>t02 ( 1): KERNEL32: GetDriveType h:\ = 3 >>t02 ( 0): KERNEL32: GetDriveTypeA returned 3 >>t02 ( 0): KERNEL32: GetFileAttributesA 2003e9f4 >>t02 ( 1): KERNEL32: GetFileAttributes of h:\ returned 16 >>t02 ( 0): KERNEL32: GetFileAttributesA returned 10 >>t02 ( 0): KERNEL32: SetErrorMode 1 >>t02 ( 1): KERNEL32: SetErrorMode(00000001h) >>t02 ( 0): KERNEL32: SetErrorMode returned 0 >>t02 ( 0): KERNEL32: GetVolumeInformationA 2003ea24 329fc8b 104 2003ea3c >>2003ea40 2003ea44 329fb86 104 >>t02 ( 1): GetVolumeInformationA h:\ >>t02 ( 1): KERNEL32: SetErrorMode(00000001h) > > >

1 0

I found what I believe is a bug in include/wine/prsht.h in ReactOS
by Jonathan Wilson 03 Dec '03

03 Dec '03

cc-ing WINE list in case its also present in the WINEHQ CVS this line: typedef const PROPSHEETPAGEA *LPCPROPSHEETPAGEW; should (I believe) be this line: typedef const PROPSHEETPAGEW *LPCPROPSHEETPAGEW; If this is a bug, can someone fix it? If its not, can someone explain why this construct is present (it looks very wierd to mix an A structure and a W structure in this typedef)

4 5

Re: winetest: the Wine test shell
by Ferenc Wagner 03 Dec '03

03 Dec '03

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > -- removed the CROSS compilation support. It should work > with a different build tree, but I haven't tested that Works just fine, thanks! Interestingly, yesterday evening I got all kinds of problems, like the build process trying to run WINDRES=false in the elf tree and other silly things. :) > -- removed striping the tests from the build. This wasn't > right for multiple reasons: > * it was using a hardcoded 'strip' command instead > of the configure one What about the following in maketest(s? cf. 8.3) STRIP="$3" DLLEXT="$4" [...] filename="$BINDIR/${test}_test.exe$DLLEXT" [...] $STRIP -s $filename and in Makefile.in (cf. tests.list vs 8.3 again): winetest.rc: maketest tests.list $(SRCDIR)/maketest -r $(SRCDIR)/tests.list "$(STRIP)" "$(DLLEXT)" > $@ || ( $(RM) $@ && exit 1 ) > * it seems strange that building winetest should > magically affect all the tests Maybe. But nothing depends on those, so I can't see it cause problems. And stripping reduces the final size of the program by an order of magnitude! It counts on a not-so-wide download link. > * why should we strip every time Stripping stripped programs doesn't take much time or effort. > Maybe we should replace this with an explicit > make strip-tests > or some such. Suggestins are welcome. Another possibility is to $STRIP -s -o ${testname}_test.exe$DLLEXT $filename It's sterile, but I'm not sure if it's better. > But I think it looks decent enough that it can go in, so we > can start sending small incremental patches to it. Shall not we put copyright notices into the files? > + if (remove (logname)) > + fatal (strmake (NULL, "Can't remove logfile: %d.", errno)); Maybe a warning would be enough here, too... :) Not that it makes any difference, of course. Best wishes, Feri.

1 0

Re: [clock04] Tidy up resources
by Alexandre Julliard 03 Dec '03

03 Dec '03

Richard Cohen <richard(a)daijobu.co.uk> writes: > Alexandre Julliard wrote: > > Your mailer has corrupted the 8-bit chars, could you please resend >> differently? > > Hmm, .. mozilla sent it as text/plain,8-bit,inline > Looks fine to me, and I can save and apply the patch OK. You are right, the problem was on my side; looks like a recent update had broken my sendmail config. My apologies to your mailer <g> -- Alexandre Julliard julliard(a)winehq.com

1 0

IDA speed problem analysis
by Andrew de Quincey 03 Dec '03

03 Dec '03

Hi, I've been doing some more work on this, and I think I've found the culprit (my apologies to everyone for the crap I've been talking recently). Whenever IDA opens the Save box.. and in fact when it does a lot of operations, it seems to completely regenerate its menus. It uses an MDI interface, and so uses the WM_MDISETMENU message to set menus. The problem function is controls/menu.c/SetMenu(). Specifically, the call to SetWindowPos() passing the SWP_FRAMECHANGED flag. If I comment this call out, IDA becomes very fast... as fast as is it in windows. If I add in Y copies of that call, IDA becomes about Y times slower. Looking at the docs on MSDN for WM_MDISETMENU, it says "After sending this message, an application must call the DrawMenuBar function to update the menu bar". Which implies that the application is in charge of telling the menu bar to redraw, meaning the call to SetWindowPos() is superfluous. However, SetMenu() is used non by MDI menus as well, which DO expect the menu to be updated automatically (MSDN: "The window is redrawn to reflect the menu change"), which means it can't just be removed. Does anyone have any suggestions for the cleanest way to resolve this? Perhaps MDI should have an internal copy of SetMenu() tailored to its needs? BTW, under windows, the MDI code does not call the USER32.SetMenu() function.

1 0

Re: WineX 3.2
by Ivan Leo Murray-Smith 03 Dec '03

03 Dec '03

My free RPMs can't hurt Transgaming. For a start, on my winex page, I have a complete list of the features that only the commercial version has, and an invitation to subscribe to Transgaming if you want those extra features. As the freeware version doesn't include installshield, lots of games won't even install with the freeware version, for a start max payne. Also, even if a game does work, it won't run full screen, so if a users has lots of games that work with the free version, but wants them to run full screen, he'll probably go to the transgaming store. For all these reasons, I don't think my free RPMs are a financial threat to Transgaming in any way. Transgaming has taken a lot from Wine (Well it wouldn't have much to sell without wine), and I don't think there is anything wrong if someone takes something back. I think Transgaming should worry about those web sites that distribute the full commercial version of WineX, you just have to look for winex 3.2 download free on google , I reported this to Transgaming many months ago, and they still haven't taken any action. Ivan.

2 1

64bit Wine?
by J. Grant 02 Dec '03

02 Dec '03

Hello I'm considering getting an Opteron. With this being a 64bit CPU I wondered if there would be any issues with using WINE to make use of win32 software on this 64bit CPU. Kind regards JG p.s. I'm not subscribed to this list from this email address, so please include my email address in any replies.

4 4

wine in the press
by Tom 02 Dec '03

02 Dec '03

http://www.osnews.com/story.php?news_id=5262 ill add it to the press page in a couple days ill look around for other articles as well. Tom

2 1

Wineinstall, Regedit seg faults
by Fabian Cenedese 02 Dec '03

02 Dec '03

Hi I just tried to install wine (from cvs 2003-12-02) on a fresh install of Knoppix (Debian). Configure/Compile went fine but I got an error with regedit as already reported here: http://bugs.winehq.org/show_bug.cgi?id=1664 In my case: Compiling regedit... make: nothing to do for "all" Preparing to install default wine registry entries... Installing default wine registry entries... tools/wineinstall: line 648: 10747 memory access error $REGEDIT $DEFREG >/dev/null Registry install failed. Is there something we can do to help? Anybody working on this? Thanks bye Fabi

1 1

Re: regedit: write support for strings
by Dimitrie O. Paun 02 Dec '03

02 Dec '03

On December 1, 2003 04:51 pm, you wrote: > ChangeLog > Add support for editing strings. Please ignore this for now, I want to change a few things. I'll resubmit in a few minutes. -- Dimi.

1 0

Re: regedit: write support for strings
by Steven Edwards 02 Dec '03

02 Dec '03

Hello Dimi, --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > I figured I should so something a bit more "useful" (in light of > the 0.9 release), so here is the first attempt. It's not too much, > and not too good, but after looking at the code, it needs some > major cleanup before I can do any work on it. So the plan is: > -- get this in the tree, so I can cleanup my tree > -- cleanup the code (proper indentation, etc) > -- add more edit support to it. > > ChangeLog > Add support for editing strings. The ReactOS and WINE regedits are a little out of sync. Can you incorporate this in to your next patch? Thanks Steven Changelog: Filip Navara - Fixed some flags in calls to CreateWindowEx - Fixed Color of the splitter (should be COLOR_BTNFACE and not light gray brush) Steven Edwards - Change a few DbgPrint statements to WINE_TRACE __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

2 1

Re: pen: fix niggly problem with hatches
by Alexandre Julliard 02 Dec '03

02 Dec '03

Andrew de Quincey <adq_dvb(a)lidskialf.net> writes: > + if (brush->lbHatch && (brush->lbStyle & ~(BS_SOLID|BS_HOLLOW))) > + FIXME("Hatches not implemented\n"); BS_SOLID etc. are not flags, you can't test them that way. -- Alexandre Julliard julliard(a)winehq.com

1 0

OpenOffice1.1.0 / wine-20031118 crash on startup
by Dan Kegel 02 Dec '03

02 Dec '03

Pure, fresh install of wine-20031118 from sources on a dual processor Red Hat 9 machine. Installed winzip, used it to unpack OpenOffice1.1.0. Installed OpenOffice1.1.0. Install went fine. Found no 'soffice.exe' of any sort, so ran Winefile and double-clicked on the "Open Text Document.lnk" in c:\windows\OpenOffice1.1.0 directory. Boom! Wine puts me into the debugger: Unhandled exception: page fault on read access to 0x02010001 in 32-bit code (0x42079c30). In 32-bit mode. 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)

2 1

Problem with latest MDK package.
by Peter Nunn 02 Dec '03

02 Dec '03

Hi folks, not sure if this belongs on this list or not, and its probably a stupidly simple question, but its got me stumped. I just installed the latest MDK package for wine (wine-20031118-mdk.i586) to update the one that shipped with MDK 9.2 (wine-20030813-1mdk.i586). Now, when I try and run wine I get wine: error while loading shared libraries: libwine.so.1: cannot open shared object file: No such file or directory libwine.so.1 is in /usr/lib/wine and I've run ldconfig after the package install, but still no joy. Any ideas what's going on here? The install also un-installed several other packages (not sure which ones though, good aren't I??) that I probably need to re-install too. It also removed the menu icons for wine and left XWine not functioning too (guess that's because wine doesn't work though). Thanks heaps. Peter Nunn. -- Think IT for your computing needs. InfoTeq Pty. Ltd.

1 0

Re: Installshield7 notes
by Daniel Kegel 02 Dec '03

02 Dec '03

"Gregory M. Turner" <gmturner007(a)ameritech.net> wrote in reply to http://marc.theaimsgroup.com/?l=wine-devel&m=106746370617833&w=2 : > Could you recommend any particular installer that fails to me (preferably > something I can download for free)? I'd be happy to take a look at this, > although I can't make any promises as some code-paths (like stubless proxies) > are not likely to be fixed anytime soon. The installer for SourceStyler (a c++ beautifier available for free download from http://www.ochresoftware.com/download.html) It fails with the message "Installer terminated prematurely.", about the time Wine complains fixme:imagehlp:StackWalk (332, 0xffffffff, 0xfffffffe, 0x41b5bb44, 0x41b5c360, (nil), 0x42054e44, 0x42054e9c, (nil)): stub I would try the workarounds listed earlier in this thread, but don't have a native copy of Windows handy. - Dan

1 0

Re: shlwapi: optimise path functions
by Dimitrie O. Paun 01 Dec '03

01 Dec '03

On November 29, 2003 06:27 pm, Andrew de Quincey wrote: > I've replaced the calls to CharNextA()/CharNextW() with array increments > and a local static function. This knocks 3.5 seconds off the file open > dialogue in IDA. Well, I'm not sure this is worth doing. First off, we're not fixing any app that makes use of CharNext{A,W}(). Second, why is your static method any faster than the real CharNextA()? Third, it's not correct to replace CharNextW() with an array increment. While it is true that currently our CharNextW() simply does the same thing, it should be fixed in the long run to properly deal with Unicode Surrogate Pairs: http://uk.geocities.com/BabelStone1357/Unicode/surrogates.html In other words, I don't think the patch is acceptable. What I'd suggest: -- figure out why the real CharNextA() is slow, and try to fix that -- figure out why it takes so long to call CharNextW() -- Dimi.

3 7

WineX 3.2
by Ivan Leo Murray-Smith 01 Dec '03

01 Dec '03

As you probably already know, Marek Lipovcan and I build RPMs of WineX for Linux Red Hat, Suse, Mandrake and compatible distros, and host them (With a bz2 of the source) on www003.portalis.it/115/ I think this is a fact that could interest a lot of people, would it be OK for me to add a link to the site in the Commercial Wine Versions section under the link to Transgaming in the wine binary download page? BTW I've just published the MDK and Suse RPM of winex 3.2, but only geeks read this list, so if you're going to try winex it you'll probably compile from source anyway.

3 2

Re: Dropped wildcards patch
by Alexandre Julliard 01 Dec '03

01 Dec '03

Hans Leidekker <hans(a)it.vu.nl> writes: > What do you mean by 'access' here? Being able to read from the file? > Write to it? Anything else like copying it or moving it? Opening an existing file or directory should work. Creating a non-existing file with a name containing wildcards should fail (but only if the wildcard is in the non-existent part of the name of course). -- Alexandre Julliard julliard(a)winehq.com

1 0

Processor-Type and -Level
by Olaf Leidinger 01 Dec '03

01 Dec '03

Hello! Once I tried to install the win32 version of gimp-1.3.xx-i686 using wine and the installer refused to install because gimp was only compiled for newer processors. The author told me, that he uses the GetSystemInfo function to get the data he needs. Running a modified MS-example on wine I get this result: Hardware information: OEM ID: 0 Number of processors: 1 Page size: 4096 Processor type: 586 Processor Level: 5 Processor Revision: 0 Minimum application address: 10000 Maximum application address: 7fffffff Active processor mask: 1 And the same on Win2k I get this output: Hardware information: OEM ID: 0 Number of processors: 1 Page size: 4096 Processor type: 586 Processor Level: 6 Processor Revision: 2560 Minimum application address: 10000 Maximum application address: 7ffeffff Active processor mask: 1 Note - I am using an athlon-xp. /********** some source ***********/ #include <windows.h> #include <stdio.h> int main() { SYSTEM_INFO siSysInfo; // Copy the hardware information to the SYSTEM_INFO structure. GetSystemInfo(&siSysInfo); // Display the contents of the SYSTEM_INFO structure. printf("Hardware information: \n"); printf(" OEM ID: %u\n", siSysInfo.dwOemId); printf(" Number of processors: %u\n", siSysInfo.dwNumberOfProcessors); printf(" Page size: %u\n", siSysInfo.dwPageSize); printf(" Processor type: %u\n", siSysInfo.dwProcessorType); printf(" Processor Level: %u\n", siSysInfo.wProcessorLevel); printf(" Processor Revision: %u\n", siSysInfo.wProcessorRevision); printf(" Minimum application address: %lx\n", siSysInfo.lpMinimumApplicationAddress); printf(" Maximum application address: %lx\n", siSysInfo.lpMaximumApplicationAddress); printf(" Active processor mask: %u\n", siSysInfo.dwActiveProcessorMask); return 1; } /********** end of some source ***********/ To bring a long story to an end: I had a look at cpu.c from dll/kernel directory and I found this part: [line 251] /* FIXME: the two entries below should be computed somehow... */ cachedsi.lpMinimumApplicationAddress = (void *)0x00010000; cachedsi.lpMaximumApplicationAddress = (void *)0x7FFFFFFF; cachedsi.dwActiveProcessorMask = 1; cachedsi.dwNumberOfProcessors = 1; cachedsi.dwProcessorType = PROCESSOR_INTEL_PENTIUM; cachedsi.dwAllocationGranularity = 0x10000; cachedsi.wProcessorLevel = 5; /* 586 */ cachedsi.wProcessorRevision = 0; So the corresponding values are compiled in. Either we change wProcessorLevel to 6 or get it from the running system. I'd prefer the later ;-) When I have some free time I could -perhaps- try to fix it but I've never changed something in the wine source. Does anybody have any proposals of how to change it in an acceptable manner? I know that all the information I need can be read from /proc/cpuinfo - but perhaps there is an easier way then reading it from there as I don't know if it is still there in 2.6. Ciao, Olaf Leidinger

3 3

RE: Supported Applications List - Screenshots
by Tom 01 Dec '03

01 Dec '03

Hi, You will need two screenshots one 200x150 and one 800x600 without scaling it down if possible. I believe the characteristics should be, No clutter & make the app as prominate as possiable. You will also want to reduce the size of the 200x150 shot as much as possible (but not to the point that its ugly) as it will be on the front page. To help save on bandwith, load faster ect. I would send them to wine-patches under WineHQ: Then if Jer wants to pick them up and put them in the que they would be there.. Is this correct? Tom

2 1

cvs access && updating news items
by Brian Vincent (C) 01 Dec '03

01 Dec '03

Guess I need to be more careful what I wish for.. Jeremy was kind enough to set me up with CVS access to the web site. As such, I won't be mailing a copy to wine-patches any more unless someone thinks it's useful. The real good news is each WWN will be posted as soon as I get done writing it and it should appear more regularly (famous last words..) Back in March I made this post: http://www.winehq.com/hypermail/wine-devel/2003/03/0685.html If no one objects I'd like to post more stuff to the front page news section. In some ways it will repeat items that will be covered in more detail in each WWN issue. The idea is to keep more current with Wine-related press releases and maybe generate more traffic/interest in Wine. News items would definitely include commercial products. Also, I can get away with more than Jeremy could - it would have looked kind of shady if he posted something about Codeweavers but forgot something about TG. Instead I'll just use my own judgement to figure out if it's related to Wine. If someone disagrees they can just deal with it^H^H^H^H^H^H send me an email. -Brian Vincent

2 1

Re: X Error of failed request
by Erik Enge 01 Dec '03

01 Dec '03

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> writes: >> X Error of failed request: BadMatch (invalid parameter attributes) >> Major opcode of failed request: 12 (X_ConfigureWindow) >> Serial number of failed request: 93 >> Current serial number in output stream: 98 > > There is a message describing the problem and the resolution here: > http://www.winehq.org/hypermail/wine-devel/2003/08/0356.html > > Unfortunately, it will require downloading the patch in the mentioned > in the message, reversing it from the source and compiling it. If you > and other people are unhappy with this not being fixed, raise your > voices on wine-devel. Hopefully someone will take the time to submit a > proper fix to this. *raises his voice* Please fix this, if you can. This is the last piece in a big puzzle for me and I'd really want it seen fixed. I tried reversing the patch out of 20030813 but it still fails with similar X errors as the one above: Error of failed request: 180 Major opcode of failed request: 153 (RENDER) Minor opcode of failed request: 7 () Serial number of failed request: 7105 Current serial number in output stream: 7123 Sometimes it's a "BadDrawable" error. Erik.

2 3

Re: FontDlg sample text
by Dmitry Timoshkov 01 Dec '03

01 Dec '03

"Shachar Shemesh" <wine-patches(a)shemesh.biz> wrote: > * Add sample text characters for Symbol, Japanese, Greek, Turkish, > Arabic, Baltic, Vietnamese, Russian, East European and Thai codepages. Why to not add them into resources? That would simplify locale handling a lot, and make our translators actually notice that strings as well. -- Dmitry.

5 12

Re: System tray integration
by Sylvain Petreolle 01 Dec '03

01 Dec '03

Your patch fails being applied to cvs at the moment... nothing critical though, this is only the license part of dlls/system32/systray.c. *************** *** 1,11 **** /* - * Systray * - * Copyright 1999 Kai Morich <kai.morich_at_bigfoot.de> * - * Manage the systray window. That it actually appears in the docking - * area of KDE or GNOME is delegated to windows/x11drv/wnd.c, - * X11DRV_WND_DockWindow. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public --- 1,11 ---- /* + * System tray handling code (client side) * + * Copyright 1999 Kai Morich <kai.morich_at_bigfoot.de> + * Copyright 2003 Mike Hearn <mike_at_theoretic.com> * + * This code creates a window with the WS_EX_TRAYWINDOW style. The actual + * environment integration code is handled inside the X11 driver. ===== 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!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

Re: Mysterious icon-change
by Ivan Leo Murray-Smith 01 Dec '03

01 Dec '03

There is a very simple solution: Don't run winetests.exe from the desktop, and the desktop icons will stay intact, at least on win2k3. It would be a good idea to put a warning in the readme and on the download page.

2 1

Re: Crypt32.dll - CryptProtectData
by Vincent Béron 30 Nov '03

30 Nov '03

Le dim 30/11/2003 à 14:52, Thomas Brix Larsen a écrit : > RCS file: /home/wine/wine/dlls/crypt32/crypt32.spec,v > retrieving revision 1.13 > diff -u -r1.13 crypt32.spec > --- dlls/crypt32/crypt32.spec 12 May 2003 03:21:45 -0000 1.13 > +++ dlls/crypt32/crypt32.spec 30 Nov 2003 19:45:03 -0000 > @@ -186,3 +186,4 @@ > @ stub RegQueryInfoKeyU > @ stub RegQueryValueExU > @ stub RegSetValueExU > +@ stdcall CryptProtectData(ptr wstr ptr ptr ptr long ptr) Try to keep the functions in alphabetical order in the spec file please. > +BOOL WINAPI CryptProtectData(DATA_BLOB* pDataIn, LPCWSTR szDataDescr, DATA_BLOB* pOptionalEntropy, PVOID pvReserved, void* pPromptStruct, DWORD dwFlags, DATA_BLOB* pDataOut) You said you changed the type of pPromptStruct to void* for cause of non-documentation. Better to get documentation for it, such as from WinCrypt.h from the SDK. I suggest you add something along those lines in Wine's wincrypt.h: typedef struct _CRYPTPROTECT_PROMPTSTRUCT { DWORD cbSize; DWORD dwPromptFlags; HWND hwndApp; LPCWSTR szPrompt; } CRYPTPROTECT_PROMPTSTRUCT, *PCRYPTPROTECT_PROMPTSTRUCT; Vincent

2 1

Re: More Tab Control fixes
by Mike Hearn 30 Nov '03

30 Nov '03

Yep, this fixes a bug that was just annoying me 5 minutes ago with the tab hottracking, thanks! One more bug remaining that I can see, on multi-line tabs we don't draw the top of the first line correctly. It can be seen in the controlspy tab demo: http://bylands.dur.ac.uk/~mh/Tab.exe thanks -mike On Sun, 2003-11-30 at 19:54, Vitaliy Margolen wrote: > Yet more Tab Control fixes. Now it should look and work much closer to native. > > Vitaliy Margolen > > changelog: > - Fix drawing of HotTracked tabs & buttons > - More tab size fixes in different styles > - Don't use new padding until style changes > - Fix left alignment of labels &| icons > - Don't draw over UpDown control > - Fully erase tabs when scrolling > - More tests

1 0

[GS]etLastError oddness
by Juan Lang 30 Nov '03

30 Nov '03

Howdy again. I've been running into a problem where I call SetLastError() in kernel32 to indicate a particular failure to an app, but the app gets 0 when it calls GetLastError(). I call GetLastError() within kernel32 as a sanity check, and it returns what I set it to. Any clues what gives? My kingdom for a working debugger again.. --Juan __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

1 0

Resolution switches in full screen mode
by Ciprian Enache 30 Nov '03

30 Nov '03

My first post! Here we go: To make resolution switches work OK in Wine full-screen apps (mostly games) there are a couple of SYSMETRICS that need to be kept updated (SM_CYSCREEN, SM_CXSCREEN - the vertical and horizontal resolution) There are 2 ways to do it: 1. Call SYSMETRICS_Set from x11drv when the resolution changes and update the values of SM_CXSCREEN, SM_CYSCREEN etc. Disadvantage: probably breaks DLL separation. 2. Add 2 calls to USER_Driver GetWidth and GetHeight (in x11drv) - and dynamically call those when we are asked about SM_CXSCREEN and SM_CYSCREEN. I wrote a patch for this. Any feedback? Sentimente.ro - www.sentimente.ro Peste 50.000 de prieteni te asteapta!

2 1

Re: FontDlg sample text
by Rein Klazes 30 Nov '03

30 Nov '03

On Sun, 30 Nov 2003 03:43:04 +0200, you wrote: > + {'C','c','D','d',0}, /* Symbol */ With native win98, ME and win2k the example string for symbol I get is spelled 'S','y','m','b','o','l' BTW, I have a patch for this and other fontdlg enhancements as well. Do you plan to submit any more patches soon? Rein. -- Rein Klazes rklazes(a)xs4all.nl

3 4

Re: [Curses] Choose curses so library at startup (4/5)
by Alexandre Julliard 30 Nov '03

30 Nov '03

Peter Berg Larsen <pebl(a)math.ku.dk> writes: > Changelog: > - Try ncursesw, ncurses and curses so library before giving up at startup You can't do that, there's no guarantee that the different libraries are binary compatible. We need to load the one we built against. -- Alexandre Julliard julliard(a)winehq.com

3 5

Re: kernel: implement a few morevxd ioctls
by Eric Pouech 30 Nov '03

30 Nov '03

Juan Lang wrote: > ChangeLog: partially implement DeviceIoControl for > VDHCP, VNETBIOS, and VNB, gets rid of FIXMEs for some > apps. > > In particular, ipconfig.exe and winipcfg.exe work more > completely (and less slowly without the FIXMEs). Hope > to see fewer bug reports complaining about the FIXMEs > too, since they usually didn't hurt anything. just for performance reasons, which don't you declare your fonction pointers as static ? (this would also prevent from bumping the load count of the DLL you use every time the app issues a deviceioctl call). A+ -- Eric Pouech

1 0

Nice work - OpenOffice 1.1 under WINE
by Steven Edwards 30 Nov '03

30 Nov '03

Hello, I have just compleated a full install of OO 1.1 under WINE. No outsite packages are required to install and configure OpenOffice for Win32 under Wine. There are a few minor bugs with some of the strings in menus but I would rate it at 99%. If anyone is interested in a good hobby project a Winelib port of this would be nice to see. With a little luck we may be able to have this running for WineConf under ReactOS. Thanks Steven __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

3 4

Re: Last Comdlg16/32 split patch
by Steven Edwards 30 Nov '03

30 Nov '03

Whoops!!!! Here it is for real. Thanks Steven --- Steven Edwards <steven_ed4153(a)yahoo.com> wrote: > After this is just header cleanup for the MS_VC and Mingw ports. > > Changlog: > Split the Win16/32 color dialog by duplicating two internal > functions. __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

1 0

Re: debugger problems
by Chris Morgan 30 Nov '03

30 Nov '03

Still isn't working with build from todays cvs. Is this patch in there? Chris On Saturday 29 November 2003 05:20 am, Eric Pouech wrote: > Chris Morgan wrote: > > Just rebuilt using 2.95 by changing the symlink /usr/bin/gcc to point to > > /usr/bin/gcc-2.95 and it still doesn't appear to be working. Did: > > > > make clean > > ./configure&&make depend&&make > > make install > > > > This enough to ensure that everything rebuilt? It looked like it. > > Running debian unstable here. > > ok, so it might not be compiler related. > There's a last fix to debug.l which has been contributed which might > help too. Could you give it a spin. > > A+

2 1

Crypt32 - CryptProtectData
by Thomas Brix Larsen 30 Nov '03

30 Nov '03

Hi list, I've been trying to get the application "Skype" (http://skype.org) working in wine. But it complains about that it can't locate the function CryptProtectData, which MSDN says belongs to crypt32.dll. I've been trying to implement this function as a stub. By adding this to crypt32/main.c: BOOL WINAPI CryptProtectData(DATA_BLOB* pDataIn, LPCWSTR szDataDescr, DATA_BLOB* pOptionalEntropy, PVOID pvReserved, void* pPromptStruct, DWORD dwFlags, DATA_BLOB* pDataOut) { FIXME("stub!\n"); return FALSE; } I know the args aren't correct but I had a problem with CRYPTPROTECT_PROMPTSTRUCT*, which isn't implented, so I just replaced with void*. I added: @ stdcall CryptProtectData(ptr wstr ptr ptr ptr long ptr) to crypt32.spec But, the app still says it can't locate CryptProtectData, so what needs to be done? Greetings, --Thomas _________________ My worst enemy gave me a copy of Windows...

1 0

Direct Sound problem
by Kris 'Spike' J 30 Nov '03

30 Nov '03

Hello there, I get an error when starting a voice communication tool that uses dsound: err:win32:PE_fixup_imports No implementation for DSOUND.dll.12 imported from C:\Programme\Ventrilo\Ventrilo.exe, setting to 0xdeadbeef a guy called TD from #winehq @ irc.freenode.net told me to mail this to the list. Done. Spike :>

2 1

Re: [winegcc10] Search standard libraries last
by Dimitrie O. Paun 30 Nov '03

30 Nov '03

On November 28, 2003 08:32 am, Richard Cohen wrote: > Dimi, I imagine that the 'other_lib_files' are going to be .so's. If > so, shouldn't we search for them first so that by default, we link > dynamically ? I guess we can, I can't remember right now why I had this order. We should just try, I guess if there was reason behind madness we'll soon find out :) -- Dimi.

1 0

Re: Last Comdlg16/32 split patch
by Dimitrie O. Paun 30 Nov '03

30 Nov '03

On November 29, 2003 09:14 pm, Steven Edwards wrote: > After this is just header cleanup for the MS_VC and Mingw ports. > > Changlog: > Split the Win16/32 color dialog by duplicating two internal functions. Dude, where's the patch? -- Dimi.

1 0

Dropped wildcards patch
by Shachar Shemesh 30 Nov '03

30 Nov '03

Hi Alexandre, Just wondering whether there was a reason that the patch at http://www.winehq.org/hypermail/wine-patches/2003/11/0339.html was not commited. My understanding of the ensuing debate was that it was acceptable. Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...

2 4

Re: version resource for regsvr32
by Dmitry Timoshkov 30 Nov '03

30 Nov '03

"Stefan Leichter" <Stefan.Leichter(a)camLine.com> wrote: > ChangeLog > -------------- > added version info resource to regsvr32 It's too late since Alxandre has committed the patch, but it's worth to mention that it's better to use a common pattern for creating version resources for Wine DLLSs, which uses wine/wine_common_ver.rc. Could you send a new patch for that? -- Dmitry.

4 3

SystemParametersInfoA very slow
by Andrew de Quincey 29 Nov '03

29 Nov '03

Hi, as I'm quite new to this project, I thought I'd check before starting to do stuff to avoid duplication/stepping on peoples toes. Initially, I've been trying to get Datarescue IDA working... the actual application works fine, but certain operations take a long time to complete (e.g. the open file dialogue takes 20 seconds to appear on my 2GHz machine). Some tracing shows the problem is SystemParametersInfoA... IDA calls this thousands of times when doing certain things, and as the current implementation is a bit slow, it really adds up. I hacked a quick test into to cache a couple of the parameters it accesses, which really helped the problem. Is anyone else working on this area right now? If not, I'll get going on doing something properly.

2 2

Re: sysparams: slight optimsation for IDA
by Dmitry Timoshkov 29 Nov '03

29 Nov '03

"Andrew de Quincey" <adq_dvb(a)lidskialf.net> wrote: > Hi, this patch optimises the SPI_GETNONCLIENTMETRICS and > SPI_GETICONTITLELOGFONT SystemParameters. These are loaded *continually* by > IDA Pro. As these properties weren't cached previously, this really slowed > everything down as it hit the disk every time. Is it possible to regenerate the patch avoiding the unnecessary changes in formatting and white space? -- Dmitry.

2 3

Re: winsock: remove annoying message
by Rein Klazes 29 Nov '03

29 Nov '03

On Thu, 27 Nov 2003 14:31:45 -0800 (PST), you wrote: > ChangeLog: remove annoying message about missing entry > in /etc/services > > The behavior when the entry is missing is already > correct, so the warning isn't useful. Well if that call fails on Wine+Linux but succeeds on Windows I don't call that correct, even if is not technically Wine that is wrong. Point is that there is no other place then inside Wine to put this message. ( Compare this to a recent discussion on the gethostbyname(NULL) behavior on wine-dev, which goes even further..) I put this in, for a banking program that uses a FTP protocol on a pair of non standard ports. AFAIK the program is not used anymore, so I don't care the message going away. But it must go, if would change it to a WARN or a TRACE, so that at least a winsock trace will reveal the problem easy. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 3

Re: debugger problems
by Chris Morgan 29 Nov '03

29 Nov '03

Just rebuilt using 2.95 by changing the symlink /usr/bin/gcc to point to /usr/bin/gcc-2.95 and it still doesn't appear to be working. Did: make clean ./configure&&make depend&&make make install This enough to ensure that everything rebuilt? It looked like it. Running debian unstable here. Chris

2 1

Re: debugger problems
by Chris Morgan 29 Nov '03

29 Nov '03

Anyone taking a look at this? Eric? Chris On Wednesday 26 November 2003 11:01 am, Rein Klazes wrote: > On Wed, 26 Nov 2003 09:01:10 -0500, you wrote: > > I'm using gcc 3.3.2, running debian unstable, maybe this > > is the issue? > > Same as here, and I have the same problem for at least a week. Gdb can > still see the symbols anyway. > > Rein.

3 2

Unhandled exception c06d007f ?
by Sylvain Petreolle 29 Nov '03

29 Nov '03

Hi, Running windows xp regedit.exe raises an unhandled exception : c06d007f. To reproduce it, copy : aclui.dll (generates the exception) authz.dll clb.dll regedit.exe :) ulib.dll Then run regedit and click on Edit, Authorizations. A google search shows that c06d007f is 'DelayLoad Export Missing', according to bugtoaster. What should be done to handle this ? ===== 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!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

Supported Applications List - Screenshots
by Sylvain Petreolle 29 Nov '03

29 Nov '03

Looking at Shachar Schemech's slides, I see that all the screenshots of the supported applications gold list are in todo state. I can install the apps & provide these. What should be the characteristics of such a screenshot to be accepted on the website ? Should I mail them to wine-patches or directly to you ? ===== 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!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Linking on the mingw build
by Steven Edwards 28 Nov '03

28 Nov '03

Hello, When linking quite a few dll on the mingw build I am getting the following error: vapi32 -lkernel32 -lntdll -L../../libs/wine -lwine -L../../libs/unicode -lwine_unicode -L../../libs/port -lwine_port -lm ../../libs/port/libwine_port.a(sigsetjmp.o.b)(.text+0x10): In function `sigsetjmp': e:/source/winehq/wine/libs/port/sigsetjmp.c:28: undefined reference to `_setjmp' ../../libs/port/libwine_port.a(sigsetjmp.o.b)(.text+0x30): In function `siglongjmp': e:/source/winehq/wine/libs/port/sigsetjmp.c:33: undefined reference to `longjmp' C:\mingw\bin\dllwrap.exe: C:\mingw\bin\gcc exited with status 1 make: *** [user32.dll] Error 1 A simple work around for me is to use the Mingw msvcrt import lib and link all of the dlls to it but I know this is not going to be the solution to get merged in to WINE. Should I add stubs for _setjmp and longjmp to libwine_port? Thanks Steven __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

2 1

RFH: div()/ldiv() compatibility
by Dimitrie O. Paun 28 Nov '03

28 Nov '03

Hi folks, We currently have a bit of a problem with div()/ldiv() (from msvcrt). Namely, they are defined to return a structure of type div_t/ldiv_t respectively. However, on i386, this is returned in windows in the eax/edx registers (the same as a long long). Now, before I go search for the ABI about returning small structures, can someone tell me if there is any way to maintain both source and binary compatibility? -- Dimi.

6 15

Mysterious icon-change
by Jakob Eriksson 28 Nov '03

28 Nov '03

I am told this is what the Internet Explorer icon looks like after winetests.exe is run. Strange eh? http://vmlinux.org/~jakov/crazy-icon.jpg

3 2

Re: Move the system.ini/[drivers32] section to the registry
by Eric Pouech 28 Nov '03

28 Nov '03

Dimitrie O. Paun wrote: > Alexandre, > > After this patch (provided you have applied the MCI one), you > should remove documentation/samples/system.ini: > $ cvs rm -f documentation/samples/system.ini > > ChangeLog > Move the system.ini/[drivers32] section to the registry. This will break any native Win9x driver configuration. A+ -- Eric Pouech

3 7

vxd deviceiocontrol hmm
by Juan Lang 28 Nov '03

28 Nov '03

Folks, I'm looking for advice on implementing DeviceIoControl for vnetbios. It's pretty simple, lpvInBuffer is a pointer to an NCB, the only parameter to Netbios(). Trouble is, I implemented Netbios() with some state, all maintained in netapi32.dll. I need to load netapi32.dll, and keep it open as long as the handle to vnetbios is open (if I close netapi32, the state is lost). I could: - use a static HANDLE to netapi32.dll in kernel - store the handle in the server - move all the netbios code to kernel, and use DeviceIoControl to call it from netapi32 Anyone have any suggestions or preferences? Thanks, --Juan __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

3 2

Re: [PATCH] [CVS] Fix int21 get disk space call
by Hannu Valtonen 28 Nov '03

28 Nov '03

Andrew de Quincey wrote: >Hi, my first patch to WINE ever. > >Theres a bug in wine/dlls/winedos/int21.c/INT21_GetFreeDiskSpace() > > I don't want to be negative but, a fix was committed to the CVS on 25.11. It's nice to see new people submitting patches. ;) - Hannu Valtonen Hannu.Valtonen(a)hut.fi

2 1

More slides - final draft?
by Shachar Shemesh 28 Nov '03

28 Nov '03

This time, I actually installed a spell checker. Believe it or not. http://www.shemesh.biz/wine holds the PDF and the openoffice of the slides. I'm hoping this is the last draft. You know youv'e stayed up for too long when you start putting stuff into your sig. A huge thanks for everyone for their input. Shachar P.S. Don't complain about "challenges" rolling off the page. That's on purpose. We have lots of challenges :-) -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/ The opinions expressed in this mail are my own, and do not necessarily represent the opinions of my employer. Wait! I am self employed! Hmm...

2 2

Default printer and patch management
by Mike Hearn 28 Nov '03

28 Nov '03

Hi, I've got a couple of questions tonight: 1) Currently the default printer is read from win.ini - setting this is annoying and doesn't work out of the box. I think it'd make more sense to have it also in the wine configuration, so if no win.ini string is retrieved it'll still work. I have an app here that dies if there is no default printer. Is it acceptable to make a fallback in the registry/config branch? The default would be "Wine Postscript Driver", though I guess we could be clever - enumerate the printers actually installed and pick the first. I don't know enough about printing to say. Huw? 2) The reason I've been so quiet on the winecfg front lately (ignoring university) is because I'm working on porting an app commercially. As a part of that process, I'm generating patches and committing to a private branch. However, I'm not sure how best to manage patch submission. There are a few alternatives: a) Just keep them "secret" until I get paid, at which point I send them in all together. Pros: Simple, Cons: people might duplicate my work. b) Notify the Wine community of what the patches do/are but keep their contents secret. Pros: Less chance of duplication, Cons: if people need the patch, knowing I have one won't be much use and it'd be hard to notify people without spamming the mailing list. Not enough people monitor bugzilla for me to be sure it'd work. c) Post them all to wine-devel but under a license that prevents them being merged unless you get a special exception from me. That way people can see, peer review the patches etc but they don't get committed. Of course, as this is just supposed to be insurance anyway, that seems a bit worthless. d) Say "screw it", submit as usual and just hope I'm dealing with trustworthy people (unfortunately no contract in this case, the job isn't really big enough to warrant one). Does anybody have any experience of this? What is the best approach? thanks -mike

3 4

Re: Mysterious icon-change
by Rolf Kalbermatter 28 Nov '03

28 Nov '03

Mike Hearn <mike(a)theoretic.com> wrote: >The Windows icon cache has always been one of the buggiest pieces of >code. I always assumed they fixed it for NT/2000/XP but it wouldn't >surprise me in the slightest if it still gets corrupted at times. > >On Thu, 2003-11-27 at 02:36, Jakob Eriksson wrote: >> I am told this is what the Internet Explorer icon looks like after >> winetests.exe is run. >> Strange eh? >> >> http://vmlinux.org/~jakov/crazy-icon.jpg It does on my W2K SP4. At random the icon cache gets mixed up and suddenly a lot of icons don't match anymore. It is especially bad with Icon Overlays. I use Tortoise CVS, a CVS shell extension, and their newest version has a special command built into their context menu to rebuild the icon cache. I do have some suspicions that Tortoise CVS may be responsible for some of the icon distortion but it happens regularly even when using normal MS applications. Rolf Kalbermatter

1 0

BUG: Debug channels get initialized too late
by Dmitry Timoshkov 28 Nov '03

28 Nov '03

Hello Alexandre, currently debug channels are initialized too late. Due to that debugging with +nls turned on doesn't show traces produced by dlls/kernel/locale.c,LOCALE_Init(). -- Dmitry.

3 5

Re: Mysterious icon-change
by Ivan Leo Murray-Smith 27 Nov '03

27 Nov '03

I get the IE icon to stay the same in quick launch, but all the desktop icons are messed up. For example, I have m$ cart trial installed, and the link to my computer (You don't have it on the desktop in win2k3 so I linked it) has the m$ cart icon, midtown madnesss trial has the icon of starlancer, motocross madness 2 had the icon of age of empires expantion, monster truck madness trial has the icon of age of empires the conquerors, age of empires has the icon of max paynem and the few icons are OK. Now this is a test box where (For a while) I can install/format/break configuration/change OS as much as I like, but someone in a production environment (Or even on a pc used for normal use from time to time) may find this irritating. Apart from this, the directx tests are very impressive. I'm posting the test results to wine-tests-results.

1 0

Re: Default printer and patch management
by Ivan Leo Murray-Smith 27 Nov '03

27 Nov '03

For all wine files that contain code written by others: >a) Just keep them "secret" until I get paid, at which point I send them >in all together. Pros: Simple, Cons: people might duplicate my work. Good idea >b) Notify the Wine community of what the patches do/are but keep their >contents secret. LGPL violation, if you give your customer a LGPL'ed binary of wine, you must give them (Or at least offer them) access to the source, and you can't legally stop him/them from sending the code to wine-patches (Even if he/they may not have any interest in doing so) >c) Post them all to wine-devel but under a license that prevents them >being merged unless you get a special exception from me. That way people >can see, peer review the patches etc but they don't get committed. Of >course, as this is just supposed to be insurance anyway, that seems a >bit worthless. Obvious and explicit LGPL violation. >d) Say "screw it", submit as usual and just hope I'm dealing with >trustworthy people (unfortunately no contract in this case, the job >isn't really big enough to warrant one). Probably in your interest to opt for A, you can never be sure. Of course, if the code you've written is just say a dll that's linked to/by wine,and you're the only author of that file/dll/whatever, you can even keep if proprietary and choose options b or c or just keep the code totally secret(That's what Transgaming and Codeweavers do). Alternatively, you can ask the copyright holders of the files you've modified for a special license that allows commercial use, in this case you can keep the code closed, and opt for b or d, or keep the code totally secret. Have a good look at http://www.gnu.org/licenses/lgpl.txt

1 0

compiler warnings
by Ivan Leo Murray-Smith 27 Nov '03

27 Nov '03

The current code compiles with a few warnings, in the attachment. BTW you can see how code degenerates rapidly when it's not free software any more, probably 10% of all the output when compiling winex 3.2 is compiler warnings.

1 0

Re: Prevent wildcards from being accepted in filenames (NT mode)
by Dmitry Timoshkov 27 Nov '03

27 Nov '03

"Shachar Shemesh" <wine-patches(a)shemesh.biz> wrote: > + /* If wer'e in NT mode - don't allow wildcards in file name */ > + if( (strchrW(name, '?') || strchrW(name, '*')) && (GetVersion()&0x80000000)==0 ) (GetVersion() & 0x80000000)==0) construct is very inefficient. It forces compiler generate both a bit mask test and a comparison operation. While many modern processors have very effective bit test instructions, and we have to tell to the compiler that we want only a bit test. Simple !(GetVersion() & 0x80000000) is much better IMO. -- Dmitry.

7 8

More spare time = New Winetests build
by Jakob Eriksson 27 Nov '03

27 Nov '03

winetests has still not made it to CVS so one month later I have another build for you: Tests built with MSVC 7 from CVS 20031127. (Testing shell cross built with mingw32.) http://vmlinux.org/jakov/Wine/ And as Brian Vincent put it: "All you have to do is download winetests.exe and just run it. All of the collected results get displayed in a browser window with the option of submitting them to the wine-tests-results mailing list." Don't be afraid it the screen turns blank for a second. It's normal. regards, Jakob .

1 0

winearts & KDE 3.2-beta1
by Kevin Koltzau 27 Nov '03

27 Nov '03

I decided to give KDE 3.2-beta1 a try (just for reference I'm using the Gentoo ebuild), and found a problem with compiling winearts under KDE 3.1 "artsc-config --cflags" gives me -I/usr/kde/3.1/include/artsc but under KDE 3.2-beta1 I get -I/usr/kde/3.2/include/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include which causes a problem because this value is passed to makedep during compilation, which fails with "Unknown option '-pthread'"

2 1

Debug channel list
by Mike Hearn 27 Nov '03

27 Nov '03

Here's a more readable version of what I just posted to wine-patches. There are quite a few, aren't there? Full marks to anybody who can actually describe what they all monitor :) accel adpcm advapi animate aspi atom avicap avifile bidi bitblt bitmap cabinet capi caret cdrom cfgmgr32 class clipboard clipping combo comboex comm commctrl commdlg computername console crtdll crypt curses cursor d3d d3d_shader d3d_surface datetime dc ddeml ddraw ddraw_fps ddraw_geom ddraw_tex debugstr devenum dialog dinput dll dma dmband dmcompos dmfile dmfiledat dmime dmloader dmscript dmstyle dmsynth dmusic dosfs dosmem dplay dplayx dpnhpast driver dsound dsound3d edit enhmetafile environ event eventlog exec file fixup font fps g711 gdi global glu graphics header heap hook hotkey icmp icon imagehlp imagelist imm int int21 int31 io ipaddress iphlpapi jack joystick key keyboard listbox listview loaddll local mapi mci mcianim mciavi mcicda mcimidi mciwave mdi menu menubuilder message metafile midi mmaux mmio mmsys mmtime module monthcal mpeg3 mpr msacm msdmo msg mshtml msi msimg32 msisys msrle32 msvcrt msvideo mswsock nativefont netapi32 netbios nls nonclient ntdll odbc ole oledlg olerelay opengl pager palette pidl powermgnt print process profile progress propsheet psapi psdrv qcap quartz ras rebar reg region relay resource richedit rundll32 sblaster scroll seh selector server setupapi shdocvw shell shlctrl snmpapi snoop sound static statusbar storage stress string syscolor system tab tape tapi task text thread thunk tid timer toolbar toolhelp tooltips trackbar treeview ttydrv twain typelib uninstaller updown urlmon uxtheme ver virtual vxd wave wc_font win win32 wineboot winecfg wineconsole wine_d3d winevdm wing winhelp wininet winmm winsock winspool wintab wintab32 wnet x11drv x11settings xdnd xrandr xrender xvidmode

1 0

Re: Fun projects?
by Ivan Leo Murray-Smith 27 Nov '03

27 Nov '03

>The easiest way is simply to convert the Gimp into a >Windows program by compiling it with WineLib >That means that in order to use Photoshop >plugins in the Gimp you'd need a special build of the Gimp Special build? Wouldn't it be easier to use the native version of gimp for windows?

2 1

Re: Winealsa : add support for Alsa 1.0
by Dimitrie O. Paun 27 Nov '03

27 Nov '03

On November 27, 2003 06:21 am, Sylvain Petreolle wrote: > Is this second attempt better ? > (not tested with alsa 0.9) Why don't you define the snd_pcm_hw_params_* macros for alsa 0.9. For example, this bit: - snd_pcm_format_t format = snd_pcm_hw_params_get_format(hw_params); - snd_pcm_access_t access = snd_pcm_hw_params_get_access(hw_params); + snd_pcm_format_t format; + snd_pcm_access_t access; + snd_pcm_uframes_t buffer_size, bufsize_min, bufsize_max; + int dir=0, channels, channels_min, channels_max; + long int period_size, periods_min=0, periods_max=0; + +#if (SND_LIB_MAJOR == 0) + format = snd_pcm_hw_params_get_format(hw_params); + access = snd_pcm_hw_params_get_access(hw_params); +#else + snd_pcm_hw_params_get_format(hw_params,&format); + snd_pcm_hw_params_get_access(hw_params,&access); +#endif Could have been coded like so: +#if (SND_LIB_MAJOR == 0) +# define snd_pcm_hw_params_get_format(hw_params,format) do{ *format = snd_pcm_hw_params_get_format(hw_params);} while(0) +# define snd_pcm_hw_params_get_access(hw_params,access) do{ *access = snd_pcm_hw_params_get_access(hw_params);} while(0) ... more snd_pcm_hw_params_* definitions +#endif ... - snd_pcm_format_t format = snd_pcm_hw_params_get_format(hw_params); - snd_pcm_access_t access = snd_pcm_hw_params_get_access(hw_params); + snd_pcm_format_t format; + snd_pcm_access_t access; + snd_pcm_uframes_t buffer_size, bufsize_min, bufsize_max; + int dir=0, channels, channels_min, channels_max; + long int period_size, periods_min=0, periods_max=0; + + snd_pcm_hw_params_get_format(hw_params,&format); + snd_pcm_hw_params_get_access(hw_params,&access); Eliminates a lot of #ifdefs, cleaner code, etc. -- Dimi.

2 1

Wine lecture slides
by Shachar Shemesh 27 Nov '03

27 Nov '03

Hi all, The updated slides for the lecture I'll be giving on Sunday are at http://www.shemesh.biz/wine/slides.pdf. I tried to incorporate all of the feedback from you guys. I would, still, appretiate any further feedback you may wish to give. I also have specific questions, if anyone knows the answers: - What is the current status of "--with-nptl" on RH9? Is it positively necessary to include that when running ./configure? I know it's not necessary when running wineinstall. - Can someone please verify my knowledge of Corel's wine history Hmm, that list turned out shorter Corel-wine: As far as I could discern from the good ol' web, Corel started it's Wine initiative in 1999 as an alternative to actually porting WordPerfect and friends to Linux. They created a branch called "Corel-wine", which was also open source (wine was X11 at the time, so they did have the choice). At some point, corel-wine died. Why did it die? When did that happen? Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

3 2

MSVC build log of wine conformance tests
by Jakob Eriksson 27 Nov '03

27 Nov '03

MSVC build log of wine conformance tests: http://vmlinux.org/jakov/Wine/build_log_MSVC_CVS_2003-11-27.txt All in all, 14 tests compile and 7 do not. AFAIK I use an up to date VC++ 7. (I reinstalled Windows though, so I _might_ have missed something.) regards, Jakob

1 0

Re: Winealsa : add support for Alsa 1.0
by Alexandre Julliard 27 Nov '03

27 Nov '03

Sylvain Petreolle <spetreolle(a)yahoo.fr> writes: > this patch is an attempt to provide Alsa 1.0 support into winealsa. > > the file audio_09.c is the current audio.c for alsa 0.9 with small > modifications to > ensure compatibility with the new alsa API. I don't think we want yet another duplicate of that code. Please try to support both in the same file, there aren't that many differences. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: RFH: *ReAlloc* mess
by Juan Lang 27 Nov '03

27 Nov '03

NetApiBufferReallocate: - does not allocate memory when NULL is the original pointer passed in - frees memory when the new size is 0 HTH, --Juan __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

1 0

Descrepancy between Windows and GLIBC version of [v]snprintf
by Daniel Gehriger 26 Nov '03

26 Nov '03

Hi, I found a problem with the _snprintf() / _vsnprintf() functions. Wine seems to use the forward these function calls to their native implementation (eg. in GLIBC). The problem is that they behave differently under Windows and GLIBC: Both function take a parameter to specify the maximum number of characters to write. Under Windows, if the formated string is equal in length to or exceeds the specified number, the terminating NULL will NOT be written to the buffer. Under Linux, the terminating NULL is ALWAYS written. The test program below produces the following output (only when linked dynamically, of course) : Under Windows: 0000000001**** Under Wine: 000000000 When compiled on Linux: 000000000 --------------------------------------------------------- #include <stdio.h> #include <memory.h> int main() { char buffer[16]; memset(buffer, 0, 16); memset(buffer, '*', 15); int len = _snprintf(buffer, 10, "%010d", 1); printf("%d : %s\n", len, buffer); return 0; } --------------------------------------------------------- Regards, Daniel

3 3

PRIVATE flag sends dllwrap for a loop.
by Steven Edwards 26 Nov '03

26 Nov '03

Hello, This is a problem I have had for a while building WINE dlls for use on Windows and ReactOS. When linking the dlls dllwrap always complains that it cant find the symbol private that is added to the .def file. When I remove this symbol and rebuild my import libs and dlls I dont have any problems so lets disable it for now. Changelog: Disable PRIVATE name on for exports in def files. Index: spec32.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/spec32.c,v retrieving revision 1.72 diff -u -r1.72 spec32.c --- spec32.c 3 Nov 2003 22:19:44 -0000 1.72 +++ spec32.c 20 Nov 2003 18:21:56 -0000 @@ -900,7 +900,9 @@ fprintf( outfile, " @%d", odp->ordinal ); if (!odp->name) fprintf( outfile, " NONAME" ); if (is_data) fprintf( outfile, " DATA" ); +#if 0 if (odp->flags & FLAG_PRIVATE) fprintf( outfile, " PRIVATE" ); +#endif fprintf( outfile, "\n" ); } } __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

2 3

Re: netapi32: implement Netbios()
by Juan Lang 26 Nov '03

26 Nov '03

Hi Uwe et al.. Uwe said: > Saying a little more may help. > > What's needed to test you patch? What programs show > improvement? Good questions. I have little test programs that I've been using, but NetBIOS is hard to test without knowing something about your network configuration, so they're not much use for netapi32/tests. I don't know of any programs that work now that didn't, except what I'm working on: I'm trying to implement the Network Neighborhood. I've been tweaking WINE's SMB code to use Netbios() rather than implementing the netbios-over-tcpip stuff directly. That work isn't done yet, watch this space for more :) There was an article a while back linked here about some HP management program (for their NAS appliance) that didn't discover their box under WINE because of lack of NetBIOS support. I suspect this may now work, but I don't know. > Any configuration items needed in a .ini file or the > registry? Needed? No, should work as-is. You may configure some things in the registry if you need to. Many are configured in the same way as Win98's reg, but not all. I didn't know a good place to document these; comments in winedefault.reg??? > And thanks for your work :-) You're very welcome :) --Juan __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

1 0

Re: netapi32: implement Netbios()
by Uwe Bonnes 26 Nov '03

26 Nov '03

>>>>> "Juan" == Juan Lang <juan_lang(a)yahoo.com> writes: Juan> Apologies for the size of the patch, I didn't see any useful way Juan> to shrink it. Juan> ChangeLog: implement rather a lot of Netbios() Juan> I could say a bit more than that, but it wouldn't mean much to Juan> most people. Where there was nearly none, now there is some. Saying a little more may help. What's needed to test you patch? What programs show improvement? Any configuration items needed in a .ini file or the registry? Just some thoughts. And thanks for your work :-) 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

debugger problems
by Chris Morgan 26 Nov '03

26 Nov '03

I'm trying to debug a crash in some changes to the jack audio driver and can't seem to have the wine debugger show me the actual source code of the crash. I start up the debugger and get this: oaded debug information from ELF 'wine' ((nil)) No debug information in 32bit DLL 'C:\Program Files\winamp\Winamp.exe' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x401d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x404b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x408c0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x40840000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x406f0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x40a00000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x40980000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHLWAPI.DLL' (0x40a50000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' (0x40aa0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHELL32.DLL' (0x40900000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x40b50000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINSPOOL.DRV' (0x40c40000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMDLG32.DLL' (0x40bd0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLEAUT32.DLL' (0x40c80000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40e10000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEJACK.DRV' (0x410e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x41130000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x41120000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x41270000) In 32-bit mode. Wine-dbg> I run and get a crash: Backtrace: =>0 0x41101541 (WINEJACK.DRV..data+0x14541) (ebp=42b87748) 1 0x410e6cbf (WINEJACK.DRV..text+0x5cbf in WINEJACK.DRV) (ebp=42b877cc) 2 0x410e7e10 (WINEJACK.DRV..text+0x6e10 in WINEJACK.DRV) (ebp=42b87804) 3 0x410e9111 (WINEJACK.DRV.wodMessage+0x131 in WINEJACK.DRV) (ebp=42b8783c) 4 0x40b70999 (WINMM.DLL.joySetThreshold+0xd89 in WINMM.DLL) (ebp=42b878ac) 5 0x40b711a4 (WINMM.DLL.joySetThreshold+0x1594 in WINMM.DLL) (ebp=42b878dc) 6 0x40b813e6 (WINMM.DLL.midiStreamStop+0x266 in WINMM.DLL) (ebp=42b87948) 7 0x40b818f4 (WINMM.DLL.waveOutOpen+0x54 in WINMM.DLL) (ebp=42b87974) 8 0x41121362 (MSACM.DRV..text+0x362 in MSACM.DRV) (ebp=42b879a8) 9 0x4112158b (MSACM.DRV..text+0x58b in MSACM.DRV) (ebp=42b87a14) 10 0x411225e7 (MSACM.DRV.wodMessage+0xe7 in MSACM.DRV) (ebp=42b87a4c) 11 0x40b70999 (WINMM.DLL.joySetThreshold+0xd89 in WINMM.DLL) (ebp=42b87abc) 12 0x40b711a4 (WINMM.DLL.joySetThreshold+0x1594 in WINMM.DLL) (ebp=42b87aec) 13 0x40b813e6 (WINMM.DLL.midiStreamStop+0x266 in WINMM.DLL) (ebp=42b87b58) 14 0x40b818f4 (WINMM.DLL.waveOutOpen+0x54 in WINMM.DLL) (ebp=42b87b84) 15 0x42a69ca6 (DSOUND.DLL.DirectSoundCreate8+0x5d6 in DSOUND.DLL) (ebp=42b87c44) 16 0x425f90eb (OUT_DS.DLL..text+0x10eb in OUT_DS.DLL) (ebp=00000000) 0x41101541 (WINEJACK.DRV..data+0x14541): movb %al,0x0(%edx) Wine-dbg>list Enter path to file '': What am I doing wrong here? Chris

3 3

Re: Intresting page
by Ivan Leo Murray-Smith 26 Nov '03

26 Nov '03

> Hmm. I'd be wary of trusting a page with such obviously manipulated > screenshots (check out the different background colours/fonts of some of > the labels), and "Write in HERE or die LMAO!" as the link to the > guestbook :-) I think they manipulated the screenshots to avoid someone hosting them and saying "I took this screenshot on my pc". Also, if you look on google you can find links to pages that talk about neptune, nashville and so on.

1 0

Intresting page
by Ivan Leo Murray-Smith 26 Nov '03

26 Nov '03

Lists (And screenshots) of lots of stuff m$ never released, like windows neptune, Whistler Advanced Server, Cairo, Nashville (Windows 96), windows titanium, windows 99, and more. http://ad-iso.mine.nu/~air101/

2 1

PE stack trick not working on lowmem machines
by Marcus Meissner 26 Nov '03

26 Nov '03

Hi, On SuSE 8.2, i586 glibc, loader/wine-* crash due to the 256 MB static array in main(). The test machine has just 64MB RAM and 200MB swap. If I start decreasing the array it works, up to 201MB. $ /lib/ld-linux.so.2 ./wine-kthread ./wine-kthread: error while loading shared libraries: ./wine-kthread: cannot map zero-fill pages: Cannot allocate memory $ So ld.so really wants to get 20xMB memory but fails. -> Not good on low memory machines. (Not sure if we should fix it.) Btw, why don't we use -Wa,--noexecstack ? Ciao, Marcus

3 3

Re: Reject wildcards in directory names
by Rolf Kalbermatter 26 Nov '03

26 Nov '03

Alexandre Julliard <julliard(a)winehq.org> wrote: > > As for the invalid characters, [Create|Remove]File[A|W] only check > > for '?', '*', which I just copied for [Create|Remove]Directory[A|W]. > > I take it you will accept a patch that also extends the checks in > > [Create|Remove]File*? > > Yes, and of course it should use a common routine to do the checks, so > that it's consistent everywhere. Also the Create and Remove cases > should be handled differently IMO, a Remove should succeed if the > specified file exists, even if it contains illegal characters. I would actually agree with Alexandre here, but W2K at least behaves differently. My tests show that RemoveDirectory just as CreateDirectory rejects all paths which contain one of the wildcards ": * ? \" < > |" with error 123 completely independent where that character occurs (not just in the path element which is created). And as far as I can say DeleteFile just as much behaves also this way. So should we attempt to be smarter than Windows in this case? Rolf Kalbermatter

5 12

Re: winehq name
by Alexandre Julliard 26 Nov '03

26 Nov '03

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > I know we've discussed this before, but I feel things > have changed and it's worth another try :) Namely, > have the winehq.org name be the default one. It seems > virtually everybody (except you) prefer the .org name > over the .com name, it's way more community friendly, > and it seems to be the default one on WineHQ for a > while, without any negative side effects. It's not that I prefer the .com name, frankly I couldn't care less, it's just that I think it's silly to change a perfectly good name that everybody was used to, simply to achieve some questionable ideal of "purity" of the domain name; and even more silly to have to change all references to try to reduce the confusion that would never have happened if we hadn't changed it in the first place. But I don't really care enough to keep fighting about it, so I put your patch in... -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine/programs/winedbg debug.l
by Dimitrie O. Paun 26 Nov '03

26 Nov '03

On November 25, 2003 11:10 pm, Alexandre Julliard wrote: > Modified files: > programs/winedbg: debug.l > > Log message: > Fixed one more HeapReAlloc call. Good catch! I didn't lie when I said all calls were reviewed, it's just that I didn't search .l files... -- Dimi.

1 0

RE: wine/ windows/win.c windows/message.c programs ...
by Robert Shearman 26 Nov '03

26 Nov '03

> -----Original Message----- > From: wine-cvs-admin(a)winehq.com [mailto:wine-cvs-admin@winehq.com]On > Behalf Of Alexandre Julliard > Sent: 26 November 2003 04:09 > To: wine-cvs(a)winehq.com > Subject: wine/ windows/win.c windows/message.c programs ... > > Log message: > Fixed declarations of BroadcastSystemMessage and > TranslateAccelerator > in winuser.h. Added GetWindowModuleFileName. > +LONG WINAPI BroadcastSystemMessageA(DWORD,LPDWORD,UINT,WPARAM,LPARAM); > +LONG WINAPI BroadcastSystemMessageW(DWORD,LPDWORD,UINT,WPARAM,LPARAM); > +#define BroadcastSystemMessage WINELIB_NAME_A(BroadcastSystemMessage) Should this not be WINELIB_NAME_AW? Rob

1 0

Strange problem with wine
by Gerhard W. Gruber 25 Nov '03

25 Nov '03

I'm using a build that is about one month old, but I don't think that this is the problem. I will update in the next few days and then I will see if this goes away. OK. I have written this small tool which you can download at http://sourceforge.net/projects/launchmen. The Linux port uses a normal fork() and then executes the specifed application when the entry is selected from the menu. It works for every application but only with wine/Agent I have to select the entry twice to make it run. When I select the entry wich should run wine with Agent nothing happens. When I look into the process list the first time I can see this: 1506 ? S 0:00 /usr/local/bin/wine /home/user/wine/D/home/agent/agent.exe 1507 ? S 0:00 \_ wineserver 1508 ? S 0:00 \_ wineserver Which is strange because I have two wineservers running. When I launch exactly the same commandline from the shell everything is normal. I see one Agent, one wineserver and Agent comes up fine. In the case of my application I can see the above list and Agent doesn't start. Only when I launch Agent a second time from my app then it starts fine. When I exit Agent then and look again I can still see the old Agent hanging, but as long as this one is there my app can launch Agent normally. When I kill this Agent and wineserver the same happens again and I have to start it twice. Any ideas what this could be? Since I only have this problem with wine I thought I ask if somebody could say something about this. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu

1 0

Re: unicows update and PE memory format
by Rolf Kalbermatter 25 Nov '03

25 Nov '03

Message: 4 Subject: Re: PE stack trick not working on lowmem machines From: Mike Hearn <mike(a)theoretic.com> To: Alexandre Julliard <julliard(a)winehq.org> Cc: Marcus Meissner <meissner(a)suse.de>, wine-devel(a)winehq.com Date: Mon, 24 Nov 2003 21:00:33 +0000 On Mon, 2003-11-24 at 20:38, Alexandre Julliard wrote: > > Btw, why don't we use -Wa,--noexecstack ? > > It doesn't help with prelink AFAICT. Is it really too late to get some kind of hook into prelink to stop it interfering with Wine? It seems daft that we need such a big hack when surely a flag in the elf headers would work just as well with co-operation from the rtld. --__--__-- >Shachar Shemesh <wine-devel(a)shemesh.biz> writes: >Now here's the puzzle - GetProcAddress is never called. Neither are >these functions imported from the DLL in the PE header. In fact, >unicows.dll does not even appear in the PE header (which makes sense - >on NT you don't even want to install it). This means that unicows.lib >manages to call GetProcAddress, without actually calling GetProcAddress. > >Some tracing leads me to suspect (I have not done enough research to >determine yet) that it accesses the PE header of kernel32 directly. It >appears that unicows.dll enountered the exact same problem we have vis a >vis GetProcAddress, and have happily hacked their way around it using >direct memory access. What I see them do is call "GetModuleHandle" on >"kernel32.dll", and then use the resulting handle as a struct/array >pointer, and access offsets into it. This is not exactly very nice but it is also not to surprising. The PE header is actually documented on MSDN including the import and export tables. GetModuleHandle actually also just returns the HMODULE which at least for Win32 is the same as the HINSTANCE returned by LoadLibrary. The difference is if I'm not mistaken, that GetModuleHandle will usually not try to load the module if it isn't already loaded, but for kernel32 you can safely assume that a process has it already loaded implicitedly or even explicitedly. An HMODULE on Win32 is nothing else than the base address of a loaded module image, and with some offset calculations using Macros from winnt.h you can get at anything in that image including the export table and from there you can then search GetProcAddress. One possible problem is that the unicows GetProcAddress implementation might not search the function in the export table by name but rather by ordinal and our ordinal or ordinal base is different from what Unicows expects. Rolf Kalbermatter

2 1

Re: Small fontdlg fix.
by Shachar Shemesh 25 Nov '03

25 Nov '03

Rein Klazes wrote: > HPEN hOrigPen; > HFONT hOrigFont; > COLORREF rgbPrev; >- WCHAR sample[SAMPLE_EXTLEN+5]={'A','a','B','b'}; >+ WCHAR sample[SAMPLE_EXTLEN+9]={'A','a','B','b','Y','y','Z','z'}; > > This is wrong. "YyZz" are only added if it's a western encoding. This already happens (a patch I submitted earlier this year, and forgot to add my copyright to the file). With this patch, if you view a font in it's Western encoding, you get a sample that says "AaBbYyZzYyZz". If you view a font in another encoding (say, Hebrew, because that's the only one that was fed in), you get "AaBbYyZz��", instead of "AaBb��", like it is on Windows 2000, and like it makes sense (we want to spare some space). Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

2 3

Re: [PATCH] wininet.dll compile time defines
by Vincent Béron 25 Nov '03

25 Nov '03

Le mar 25/11/2003 à 00:37, Alex Tribble a écrit : > Hi, > When upgrading to Fedora Core 1 (the new RedHat release, sort of), > wine stopped compiling for me. I was getting errors while parsing > <openssl/ssl.h>, et al. -DOPENSSL_NO_KRB5 makes these go away. > > Any thoughts? Please CC me, as I'm not subscribed to the devel list. The patch http://cvs.winehq.com/patch.py?id=10182 (applied yesterday in CVS) fixes the issue. Vincent

1 0

Re: Mach-O Support for imageSize in NtHeader
by Alexandre Julliard 25 Nov '03

25 Nov '03

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > Here is my second try for a replacement of the _end symbol. I think > that since there is no support of it we need a kind of emulation > function, which I thought should be located in the wine_port lib. So I > add a mach-o.c port file, with the needed function. But should it be > done this way? No, the static char _end[] thing should be enough, you don't have to store anything in there (which won't do what you want anyway). The only thing that matters is the address of the _end symbol. -- Alexandre Julliard julliard(a)winehq.com

2 1

unicows update and PE memory format
by Shachar Shemesh 25 Nov '03

25 Nov '03

Hi list, Here is a quick update. It seems that I won't be able to use the forwarding inside the spec file. I'm not sure exactly why that is, but I think the unicows.lib link time library tries to load stuff by doing "GetModuleHandle", and then fetching relative values from that place. Is there a plausable assumption about PE memory layout? Is this something that Win32 properly defines? Do we have such a format for winelib dlls? Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

3 5

RFH: *ReAlloc* mess
by Dimitrie O. Paun 25 Nov '03

25 Nov '03

Hi folks, I need some help to figure out how the following realloc functions behave: GlobalReAlloc LocalReAlloc Local32ReAlloc16 NetApiBufferReallocate SysReAllocStringLen So, I need to know: -- do they allocate memory when a NULL is passed in? -- do they free memory when the size is passed in as 0? Help with this matter is much appreciated! -- Dimi.

1 0

Re: Update comctl spec
by Alexandre Julliard 24 Nov '03

24 Nov '03

Hans Leidekker <hans(a)it.vu.nl> writes: > Changelog: > - Export more functions by name. This will break the import libraries. Why do you want to do that? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Compile Bug: dlls/wininet/cookie.c .. and its cause
by Alexandre Julliard 24 Nov '03

24 Nov '03

Ivan Gyurdiev <ivg2(a)cornell.edu> writes: > I have no clue what the FAR macro does, but wouldn't it be better to > just rename the wine FAR macro to something different if you dont want > it to conflict w/ the other FAR macro? It's a Windows thing, we can't change it. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: heap: fix RtlHeapReAllocate()
by Dimitrie O. Paun 24 Nov '03

24 Nov '03

On November 21, 2003 03:21 pm, Eric Pouech wrote: > this will not compile on Win9x. You have to take care of: Good point, sorry about that, I was being lazy. To force people to do the dyn load, we shouldn't import ntdll, no? ChangeLog RtlHeapReAllocate() should not allocate memory. Add small test to make sure it doesn't return. Don't import ntdll for tests, we need to load it dynamically. Index: dlls/ntdll/heap.c =================================================================== RCS file: /var/cvs/wine/dlls/ntdll/heap.c,v retrieving revision 1.25 diff -u -r1.25 heap.c --- dlls/ntdll/heap.c 10 Oct 2003 00:12:17 -0000 1.25 +++ dlls/ntdll/heap.c 20 Nov 2003 21:00:39 -0000 @@ -1231,11 +1231,11 @@ HEAP *heapPtr; SUBHEAP *subheap; - if (!ptr) return RtlAllocateHeap( heap, flags, size ); /* FIXME: correct? */ + if (!ptr) return NULL; if (!(heapPtr = HEAP_GetPtr( heap ))) { set_status( STATUS_INVALID_HANDLE ); - return FALSE; + return NULL; } /* Validate the parameters */ Index: dlls/ntdll/tests/Makefile.in =================================================================== RCS file: /var/cvs/wine/dlls/ntdll/tests/Makefile.in,v retrieving revision 1.9 diff -u -r1.9 Makefile.in --- dlls/ntdll/tests/Makefile.in 8 May 2003 03:47:24 -0000 1.9 +++ dlls/ntdll/tests/Makefile.in 24 Nov 2003 07:19:04 -0000 @@ -3,12 +3,12 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ TESTDLL = ntdll.dll -IMPORTS = ntdll CTESTS = \ env.c \ error.c \ generated.c \ + heap.c \ large_int.c \ path.c \ rtl.c \ --- /dev/null 2003-01-30 05:24:37.000000000 -0500 +++ dlls/ntdll/tests/heap.c 2003-11-24 02:17:07.000000000 -0500 @@ -0,0 +1,49 @@ +/* + * Unit test suite for heap functions + * + * Copyright 2003 Dimitrie O. Paun + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include <stdarg.h> +#include <stdlib.h> + +#include "ntstatus.h" +#include "windef.h" +#include "winbase.h" +#include "wine/test.h" +#include "winnt.h" +#include "winnls.h" +#include "winreg.h" +#include "winternl.h" + +PVOID (WINAPI *pRtlReAllocateHeap)(HANDLE,ULONG,PVOID,ULONG); + +static void test_realloc( void ) +{ + void *mem = NULL; + + mem = pRtlReAllocateHeap(GetProcessHeap(), 0, mem, 10); + ok(mem == NULL, "memory allocated"); +} + +START_TEST(heap) +{ + HMODULE mod = GetModuleHandle("ntdll.dll"); + if (!mod) return; + pRtlReAllocateHeap = (void *)GetProcAddress(mod, "RtlReAllocateHeap"); + if (pRtlReAllocateHeap) test_realloc(); +} -- Dimi.

3 3

Compile Bug: dlls/wininet/cookie.c .. and its cause
by Ivan Gyurdiev 24 Nov '03

24 Nov '03

Macro __WINESRC__ is defined for dlls/wininet/cookie.c in the Makefile. The file cookie.c includes wine/debug.h. wine/debug.h includes windef.h. windef.h defines the macro FAR to __ONLY_IN_WINELIB() __ONLY_IN_WINELIB() defines to do_not_use_this_in_wine if __WINESRC__ The file dlls/wininet/cookie.c also includes dlls/wininet/internet.h dlls/wininet/internet.h includes openssl/ssl.h for my machine openssl/ssl.h includes openssl/kssl.h openssl/kssl.h has the following code using the FAR macro: #ifdef KRB5_HEIMDAL typedef unsigned char krb5_octet; #endif #ifndef FAR #define FAR #endif ... Line 136: krb5_octet FAR *key; This is on a Fedora core system, which applies a patch to openssl that changes the original openssl-devel regarding this, but I think the issue's with wine, and is still there. The original openssl-devel looks like this: #ifdef KRB5_HEIMDAL typedef unsigned char krb5_octet; define FAR #endif Either way, the point is the FAR macro is being used in kssl.h, and it's defined in windef.h, as do_not_use_this_in_wine, resulting in this: gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_WINX32_ -D_REENTRANT -fPIC -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o cookie.o cookie.c In file included from /usr/include/openssl/ssl.h:179, from internet.h:36, from cookie.c:39: /usr/include/openssl/kssl.h:136: error: syntax error before '*' token /usr/include/openssl/kssl.h:149: error: syntax error before '*' token /usr/include/openssl/kssl.h:150: error: syntax error before '*' token /usr/include/openssl/kssl.h:151: error: syntax error before '*' token /usr/include/openssl/kssl.h:151: error: syntax error before '*' token /usr/include/openssl/kssl.h:152: error: syntax error before '*' token /usr/include/openssl/kssl.h:153: error: syntax error before '*' token /usr/include/openssl/kssl.h:155: error: syntax error before '*' token /usr/include/openssl/kssl.h:157: error: syntax error before '*' token /usr/include/openssl/kssl.h:159: error: syntax error before '*' token /usr/include/openssl/kssl.h:167: error: syntax error before '*' token In file included from internet.h:36, from cookie.c:39: /usr/include/openssl/ssl.h:909: error: syntax error before "KSSL_CTX" /usr/include/openssl/ssl.h:931: error: syntax error before '}' token make[2]: *** [cookie.o] Error 1 make[2]: Leaving directory `/home/phantom/tmp/firebird-downloads/wine-20031118/dlls/wininet' make[1]: *** [wininet] Error 2 make[1]: Leaving directory `/home/phantom/tmp/firebird-downloads/wine-20031118/dlls' make: *** [dlls] Error 2 ===================================================================== I am not subscribed to this list. If you'd like to email back write to ivg2(a)cornell.edu. Also, some unrelated questions: does anyone know what causes this: err:module:NE_LoadBuiltinModule loaded .so but dll winealsa.drv still not found (the file is there... oss is there too, and works great) ....or why keyboard focus is always lost (characters appear in the console, kb doesn't work in application) when playing most games under a window manager like gnome or kde, but not under twm? This bug has been there forever and is really annoying.

3 2

Re: winmm: move MCI settings from system.ini to the registry
by Andreas Mohr 24 Nov '03

24 Nov '03

Hi, On Mon, Nov 24, 2003 at 12:10:20PM -0500, Dimitrie O. Paun wrote: > On November 22, 2003 03:02 am, Eric Pouech wrote: > > I won't have too much time to look at this in details right now, so if > > someone wants to jump in, I'll be happy to give him (her ?) a hand. > > To be honest, > My interest in doing this work is to get rid of system.ini from the > Wine tree. While I agree that there's more to do, it's just not up > my alley :) So, this version of the patch still maintains support > for system.ini, just like the old code does, but it also adds support > for registry, which should allow us to move stuff there. To be honest, I'm not sure why one would want that. After all the system.ini settings are an essential part of a Windows environment, and removing the whole file will break many (admittedly older) programs, if I'm not mistaken... (nevermind the duplication of the parameters, which does exist) Andreas Mohr

1 0

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