- wine-devel - winehq.org

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 23 Oct '02

23 Oct '02

> Actually there is a portable solution. Here's what i did when > I compiled > the Wine tests on Windows: > > Run 'vcvars32.bat' first. When you install Microsoft Visual C++ you > can either tell it to add environment variables with the useful stuff > (either in autoexec.bat or the registry for NT), or just rely on > 'vcvars32.bat'. This script is usually in the include directory: > c:\Program Files\Microsoft Visual Studio\VC98\include\vcvars32.bat > > Well, … [View More]

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 23 Oct '02

23 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > Of course compiling every DLL with the Microsoft headers requires > > fixing all of include/wine/ but then as long as we have a solution > > when we get where eventually is good enough IMHO, doing that is no > > particular rush. Having the Wine tests work properly sooner > > rather than later is much more important though. > > I agree getting the Wine tests to work soon is important, but you > don'… [View More]

1 0

message box fix.
by Rein Klazes 23 Oct '02

23 Oct '02

Hi, Fix for recent Messagebox breakage. windows/ : msgbox.c In MessageBoxIndirectW call FindResourceEx with arguments in the right order. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

Docu fix for builtin/native apps
by Sylvain Petreolle 23 Oct '02

23 Oct '02

Changelog : Added valid entries into samples/config to specify if an app should be loaded builtin or native. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

wine not detecting wine printers
by Dan Fer 23 Oct '02

23 Oct '02

Has anyone tried using cups under Wine in any of the latest builds? I tried to builds from this month and none detect any printer. Is there a patch? Anything I could use to fix it? _________________________________________________________________ MSN. Más Útil Cada Día http://www.msn.es/intmap/

1 0

Re: Treeview fix
by Jeff Smith 23 Oct '02

23 Oct '02

This patch did the trick. Well I cannot test it at the moment, but as the value INT_MAX (0x7fffffff) was the issue, I know this will fix it. The limit works a lot better (is a lot safer) than the 'special' value. ... - if (i == 0x7fff) + if (i >= 0x7fff) i = hdpa->nItemCount; ... >From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > >On October 23, 2002 01:29 am, Jeff Smith wrote: > > Oops, your previous message got lost in the shuffle... > > … [View More]

1 0

Re: Treeview fix
by Jeff Smith 23 Oct '02

23 Oct '02

Oops, your previous message got lost in the shuffle... I'm sure anything is better than the little patch I wrote. I was just taking a minimalist approach to get treeview working. -- Jeff S Dimi wrote: >On October 23, 2002 12:44 am, Jeff Smith wrote: > > I discovered treeview uses DSA's and Dimi recently > > changed the max element number in DSA's to 0x7fff (SHRT_MAX). > > Note this value has the special meaning in DSA_InsertPtr > > functions of 'add new element to … [View More]

2 1

LogonUser(), netapi work
by Martin Wilck 23 Oct '02

23 Oct '02

Hi, after having been busy with other stuff for a while, I'd like to inquire the status of my LogonUser() patch (http://www.winehq.com/hypermail/wine-devel/2002/09/0448.html) I have had almost no feedback, positive or negative, on this, and it wasn't applied either. I still think it could be useful, although it is clear that wine won't (shouldn't) be able to change personality in the foreseeable future. Andriy, what is the status of your netapi work? Martin -- Martin Wilck … [View More]

2 1

Re: Using winbind with Wine
by Martin Wilck 23 Oct '02

23 Oct '02

Am Mit, 2002-09-25 um 00.55 schrieb Andrew Bartlett: > Firstly, it's good to see that winbind is starting to get some interest > :-) I have been ignoring it so far, but in the context of the current inquiries I tried it out and was impressed :-) > Secondly, don't fall into the trap squid (with my encouragement I might > add...) fell into - don't use the winbind pipe directly. The winbind > API is an internal Samba API, and can change without warning. Hmm - what other APIs … [View More]

8 12

Marshalling code for me to use?
by Greg Turner 23 Oct '02

23 Oct '02

Before I go off and duplicate a bunch of work somebody already did, I wanted to verify that wine has no existing implementation of NDR data marshalling? I don't know of such a thing, but I don't necessarily have the big picture. rpcrt4 needs this for somewhat obvious reasons, and the format is well documented by OpenGroup if we need to start an implementation from scratch. -- gmt

4 8

another snapshot (F_PL1_pre1)
by Greg Turner 23 Oct '02

23 Oct '02

relative to yesterday's RPC_E_PL15_unmerged.diff. LICENSE: X11 CHANGELOG: * dlls/rpcrt4: ndr_marshall.c, ndr_midl.c, ndr_misc.h, rpcrt4_main.c, ndr_stubless.c; include: rpcndr.h, wine/rpcfc.h: Greg Turner <gmturner007(a)ameritech.net> - make explicit some hidden include dependencies - Implement NdrGetBuffer, NdrFreeBuffer, NdrConformantStringBufferSize and NdrConformantStringMarshall - define the RPC_FC_C_CSTRING constant - perhaps I don't want those MIDL_*_FORMAT_STRING … [View More]

1 0

Treeview fix
by Jeff Smith 23 Oct '02

23 Oct '02

Intro: Once I got wine to finally execute the native regedit, treeview was bringing it down. Background: I discovered treeview uses DSA's and Dimi recently changed the max element number in DSA's to 0x7fff (SHRT_MAX). Note this value has the special meaning in DSA_InsertPtr functions of 'add new element to end of array'. Problem: INT_MAX (0x7fffffff) was being passed from treeview to DSA_InsertPtr. This caused failure returns and eventually a seg fault. Conclusion: This patch fixes the … [View More]

2 1

Re: using native regedit
by Jeff Smith 23 Oct '02

23 Oct '02

I agree that the example should be changed to indicate a 'valid' entry if this is the way it is supposed to be. This would have saved me a lot of trouble and confusion. Now I can work on getting native regedit working again. -- Jeff S. >Shouldn't we update the sample entry in documentation/sample/config ? > > ; you can specify applications too >-"*\\notepad.exe" = "native, builtin" >+"notepad.exe" = "native, builtin" > ; default for all other dlls > "*" = "builtin, … [View More]

2 1

Re: using native regedit
by Jeff Smith 23 Oct '02

23 Oct '02

Found something: it works if I fully qualify the command name. I was trying this in the DllOverrides / command-line respectively: "regedit.exe" = "native, builtin" --dll regedit.exe=n,b What I have to do for it to work is this: "C:\\Windows\\regedit.exe" = "native, builtin" --dll C:\\Windows\\regedit.exe=n,b I still do not think this is *exactly* as it should be, but I'm finally on the track to figuring it out. -- Jeff S. … [View More]

3 2

[RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 23 Oct '02

23 Oct '02

As some of you probably know I have been working on compiling Wine on Windows using Microsoft Visual C/C++ (MSVC). Even though it doesn't really work that well yet there have been at least some success. Anyway recently I have began trying to get the Wine tests to compile and work using MSVC. More specifically I have been trying to get the my generated tests for data structure packing (tests/generated.c) to work. This currently works quite well. A few patches regarding errors found coming soon.… [View More] However there are at least two intresting ways to compile and run the tests on Windows. 1. Compile using the Wine headers. 2. Compile using the Microsoft headers. Currently only (1) works in a portable way. To get (2) to work I had to add the directory of the Microsoft includes to the begining of the include path. This is not very portable since it differs from installation to installation. I have currently hardcoding my specific directory. The above have to be done because the Wine tests includes include/wine/test.h as thus ..\..\..\include (or similar depending on directory depth have to be added the the include). This overides the Microsoft headers!!! Microsoft C unlike GNU C have no option to avoid this other than adding the path the Microsoft include directory which as I previously mention varies depend on installation. :-) However I finally think I have found a portable solution, that will work not only with the Wine test but also with Wine itself (eventhough that is perhaps less instresting right now). We currently have the directory structure like include: Wine's version of Windows headers include/wine: Wine's internal and "extension" headers I would like to have a directory structure like include: Wine's version of Windows headers include/wine: Wine's internal headers include/wine/wine: Wine's "extension" headers With "extension" headers I mean that headers that are exported and usuable by Winelib applications. This would allow me to, using MSVC, just do /I ..\..\..\include\wine instead of the current very ugly and unportable /I d:\program files\microsoft visual studio\vc98\include /I ..\..\..\include So concretely what I think needs to be done (not tested) is the following. cd include/wine mkdir wine mv exception.h test.h unicode.h wine # Then include/Makefile.in needs to be changed accordingly as well. # In principle all the include/wine/ files named in include/Makefile.in # should be moved as well. However the files named above is enough for # the Wine tests AFAICS. --- Make.rules.in 19 Oct 2002 17:15:00 -0000 1.131 +++ Make.rules.in 21 Oct 2002 12:58:35 -0000 @@ -45,7 +45,7 @@ LN = @LN@ LN_S = @LN_S@ TOOLSDIR = @TOOLSDIR@ -DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include $(EXTRAINCL) +DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include -I$(TOPSRCDIR)/include/wine $(EXTRAINCL) ALLCFLAGS = $(DIVINCL) $(CFLAGS) $(DEFS) $(OPTIONS) LD = @LD@ LDFLAGS = @LDFLAGS@ So what do you think? Note that compiling Winelib applications under Linux might benefit from this as well since it makes it easier to use the real Microsoft headers together the Wine extensions (wine/*.h). Sure currently GNU C chokes on this but one day some compiler (GNU C or some other) might not... [View Less]

3 2

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > We could do that following instead: > > (1) /usr/include/wine => /usr/include/wine/windows > > (2) /usr/include/wine/wine => /usr/include/wine/windows/wine > > (3) /usr/include/wine/wine/wine => /usr/include/wine > > > > Also note (2) will disappear eventually. > > Well, it's somewhat better, but it's still too complex IMO. Where is the complexity? If you want to port a … [View More]Window application, you add -I/usr/include/wine/windows and everything as much as like under Windows as possible. If you in addition wish to call some Wine "extension" no problem just do #include "wine/foo.h" or similar. If you just want to use the Windows API in an Unix application you need anything at all. Just do #include "wine/windows/wincrypt.h" and you're done. [Linking is a separate problem, of course. But then, this changes nothing as far as this is concerned] > Maybe what > we should do is put the (3) headers directly in /usr/include, like > /usr/include/wine_unicode.h. But this would work only if we don't have > many of them, so we probably want to work on simplifying this first. I can't see any principal difference between /usr/include/wine_foo.h or /usr/include/wine/foo.h None of them requires any -I. It is more a convention that if you have many .h you have a directory, if not, well then you can have a directory anyway, it is up to you. > Also note that this is not going to solve your problem, because > wine/test.h is more a category (2) header Well wine/test.h is really kind of a special case anyway it could be moved to programs/winetest/include/wine or something under whatever name it is not really a concern. Perhaps we should move programs/winetest/wtmain.c to test/ and make it a library similar to library/ and unicode/. This is what I did with MSVC, eventhough I did it in programs/winetest instead. > (or maybe you need a new > category for Wine internal headers that don't get installed). You mean for files like windef16.h? Well, in the long run such files really belongs in the dlls/* directories. In the extent that that can't they really are Wine "extension" that might as well be used by any Winelib application not just internally should IMHO be installed. But yes, we certainly need some place to put them in the meantime, since this isn't happing over night. However I think that they can remain in include/wine/ until we move them one by one. See below. > > PS. Of course we could move include/*.h to include/wine/windows or > > something like that but then it is no real use and beside it ruins > > the cvs patch log. Better stick to the ugly include/wine/wine > > solution interally IMHO. > > Not an option. If we have to move the files we'll move them; it's > better to avoid moving things around too much. but we shouldn't let > CVS limitations impose a broken structure. OK. > Now if we can find a non > broken structure that also doesn't involve moving files that's better. Perhaps this would work: mkdir library/wine mv include/wine/{library,port}.h library/wine mkdir unicode/wine mv include/wine/unicode.h unicode/wine mkdir dlls/ntdll/wine mv include/wine/exception.h dlls/ntdll/wine Sure it would mean a few more -I internally but it would not be that bad. Then during install all these files as well as some files from include/wine/ ends up in /usr/include/wine and the include/ files end up in /usr/include/wine/windows or /usr/include/wine/win32 not sure what is best. That would require moving a minimum of files. As before eventually far in the future include/wine/ would be empty. Transition done. We needn't move everything right now either. As mentioned before running the Wine test with the Microsoft headers currently AFAICS only requires that we fix wine/{exception,test,unicode}.h. Of course compiling every DLL with the Microsoft headers requires fixing all of include/wine/ but then as long as we have a solution when we get where eventually is good enough IMHO, doing that is no particular rush. Having the Wine tests work properly sooner rather than later is much more important though. [View Less]

3 2

using native regedit
by Jeff Smith 22 Oct '02

22 Oct '02

3 2

Re: updated dlls/comctl32/commctrl.c comments
by Dimitrie O. Paun 22 Oct '02

22 Oct '02

On October 22, 2002 03:02 pm, Christian Neumair wrote: > Dimitrie started posting a header doc patch for listview.c, so I got > motivated and wrote the same thing for commctrl.c. > I hope it's complete. Thanks, Chris. In many respects, this is more important than code. For many reasons I will not go into here, I think it is vital that we have a header giving a _clear_ pictures of what remains to be done. I just hope others will do the same. -- Dimi.

1 0

Re: Don't return FILE_ATTRIBUTE_SYMLINK
by Dimitrie O. Paun 22 Oct '02

22 Oct '02

On October 22, 2002 04:25 pm, Medland, Bill wrote: > diff105.diff Can you please insert such files in the body of the message? It gets combersome to review patches in attachments... -- Dimi.

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > I suggest that we gradually move the files in include/wine > > to include/wine/wine or in some cases other places like the DLL > > directories. Eventually, far in the future, the > include/wine directory > > will be empty (save for a wine directory). > > > > This provides a slow and steady migration path from the old > > to the new that doesn't have any of the problems you described. … [View More] > > What more can you ask for? > > A clean solution? Seriously this is ugly as hell; It would have been nice if had been cleaner yes, but then you can't have everything can you? :-) Seriously, I think we can do a little better. See below. > especially when you > consider that after you install you will get Wine headers in > /usr/include/wine, /usr/include/wine/wine and > /usr/include/wine/wine/wine. Correct. [I think we understand each other at least this time] > Tell me this isn't confusing... First of all you have /usr/include/wine and /usr/include/wine/wine even today. Which already is a little confusing. But hey it works for most thing so I'm not complaining that much. But yes, it is a little confusing. Hmm. Thinking.... We could do that following instead: (1) /usr/include/wine => /usr/include/wine/windows (2) /usr/include/wine/wine => /usr/include/wine/windows/wine (3) /usr/include/wine/wine/wine => /usr/include/wine Also note (2) will disappear eventually. This would be very nice since now normal Winelib applications ie ports from Windows can do -I/usr/include/wine/windows regardless of whether they use the Wine "extensions" or not since #include "wine/test.h" for example will work without a -I. "Special" Winelib application could do #include "wine/windows/wincrypt.h" without any -I if somebody for example wanted to use the Windows encryption API in a normal Unix application. Hmm. Perhaps /usr/include/wine/windows should be /usr/include/wine/win32 instead, with perhaps /usr/include/wine/windows as symbolic link to /usr/include/wine/win32. But that is just details, what do you think in principle. > If you really want to make it possible to mix and match headers from > different sources, you need a more serious redesign of the whole > include layout, and you need to ensure that the normal case is at > least as easy and clean as it is today. I think the suggestion above would do nicely. Internally in the wine tree I think we might have to choose the ugly include/wine/wine solution, but we could install to the solution above which is what's really important. PS. Of course we could move include/*.h to include/wine/windows or something like that but then it is no real use and beside it ruins the cvs patch log. Better stick to the ugly include/wine/wine solution interally IMHO. [View Less]

2 1

An RPC progress report
by Greg Turner 22 Oct '02

22 Oct '02

On Tuesday 22 October 2002 12:47 pm, you wrote: > Greg - > > I've been following the RPC merges lately, > looks like a lot of stuff added. I browsed > the code, but I couldn't really get a grasp > on some of it. That's OK, I'm not sure /I've/ got a grasp on some of it !! ;) > I was just wondering if > you'd like to write an update (short, long, > whatever) about what you've done, what's left > to do, major stumbling blocks, etc. I'll > include it in the … [View More]next issue of Wine Weekly > News. Above what Ove already implemented, I really haven't done all that much. Frankly, in its current state, it is quite possible that the RPC work I am doing will /detract/ from the stability of wine, until the implementation is more complete. RPC is painfully complicated, and a victim of serious creeping featurism. Microsoft makes it worse by providing poorly documented extentions to the protocol, and a largely undocumented marshalling API (much of which developers typically don't have to learn because the API calls are generated by the MIDL compiler). My target right now is to get a "hello world" API invocation to work across processes using wine RPC. Once that is achieved, I plan to create a unit test for this. Then, we'll have a framework that we can begin to extend and implement "properly." I am not there yet, but I think I'm getting close. I just have to implement marshalling for strings, which, in theory, looks pretty easy. There are probably many bugs that need squashing before it works, and maybe some additional gaps in functionality that I don't even realize exist yet... but I do think I'm pretty near. Now, what remains to be done? Well, as Ove mentions in the TODO for his units, "a whole lot." Here are several things in no particular order: - widl is like MIDL for wine. For wine to be a useful RPC platform, quite a bit of work needs to be done here. widl currently doesn't generate stubs for RPC invocation -- it will need to; this is tricky because the MIDL compiler does some really wierd stuff. Then again, we don't neccesarily have to make widl work like MIDL, so it could be worse. - RPC has a quite featureful error handling mechanism; none of it is implemented right now. - The server portions of the patch don't seem to be getting accepted by Alexandre. My guess is that once I have a working test he'll conceed to let this in. To implement this properly is tricky and possibly beyond my abilities; Ove seems to think the right way to do this is to use LPC (Local Procedure Call, another undocumented monster). LPC has no implementation in wine and is not going to be trivial to create. - there are several different memory allocation schemes for MSRPC. I don't even understand what they all are yet, much less have them properly implemented. - MSRPC provides impersonation capabilities which currently are not possible to implement in wine. - Some transports are not yet implemented. The existing transport implementations are incomplete. (By transports I mean, tcp/ip, named-pipes, local procedure call, etc --- the various types of low-level plumbing that can be used to connect the client and the server). - Data marshalling is the means by which RPC represents data across process and machine boundaries. MSRPC extends NDR format for this. The wire protocol is mostly documented, but the MS API's to convert data-types in memory into NDR are not. This, alone, is a sizable chunk of work. - ORPC is RPC for OLE; once we have a working RPC framework, we can use it to implement out-of-process OLE client/server communications. This will be a huge win for wine. But again, it's a lot of work, and I'm no OLE expert (hell, I'm no RPC expert :) - Surely there is much more stuff I am forgetting. Like Ove said, it's "a whole lot" of stuff, approximately as big a project as, say, DirectX. Basically, RPC for wine is a huge beast of a project. IMO it is probably the biggest and most difficult-to-fill hole in wine's feature-completeness ATM. In the short term, don't expect any miracles --- I really doubt that I'm going to "solve" this (in my spare time!) anytime soon. But, once I start getting some results, I imagine others will be enticed to help out, as contributors like Ove already have. (To be clear: Ove enticed me, not the other way around: He did all the "real" work, and deserves way more credit than me for any success I may achieve in the near future). wish me luck, -- gmt "Oh, and of course, the fastest way to dig a tunnel is to dig at both sides." -- The Linux Advanced Routing HOWTO [View Less]

2 2

Re: using native regedit
by Jeff Smith 22 Oct '02

22 Oct '02

Thanks for the advice, this should get me by for now. Of course I would still like DllOverrides section to work as advertised, but maybe I can hack on it some more when I am more in the mood. P.S. Sorry about the HTML message, the Hotmail admins seem to be playing around with default settings. -- Jeff S. >From: Greg Turner To: "Jeff Smith" , wine-devel(a)winehq.com On Tuesday 22 >October 2002 01:01 pm, Jeff Smith wrote: > I know I must be missing > >something very simple,… [View More]

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Perhaps (2) and (3) are not much different (se below), > > but (1) and (2/3) are clearly different. > > Well yes, that why they are in different directories. (1) is in > include and (2/3) is in include/wine. Yes, but because of how they are positioned in the filesystemet and used by C they are effectively "packaged together" in a bad way. It seems that I'm not the only one having this problem as well. … [View More]Steven Edwards also wants a way to use the Mingw/W32api package together with Wine in a sane way. But I have a plan how to smoothly migrated from the current layout to a new layout. See below. > > That is why I think "-I../../include" shouldn't automatically give > > you (2) and (3) as it does now. Having to add -I../../include/wine > > or whatever to get it would make it possible in addition to > > solving my MSVC Microsoft header problem to make it possible to > > uses the Microsoft headers or whomevers headers even on Linux. > > The problem is that then you require everybody who wants to use > Winelib to add stuff to their include path, even if they don't use any > Wine header directly (since our Windows headers reference the Wine > ones). They currently do, yes. That is why I initially suggested creating a include/wine/wine and only moving the "extension" headers like over to include/wine/wine. The "extension" headers are files in include/wine like debug.h, exception.h, library.h, port.h, server.h, test.h, unicode.h that isn't or shouldn't be included by our Windows headers. In the extent that they are it is a bug IMHO and AFAICS one that is quite easily fixed in most cases as well. However, in the first phase to get the all the tests running I AFAICS only need exception.h, test.h and unicode.h. Of them only unicode.h is currently used by the Wine headers (file.h and heap.h). However fixing that shouldn't really be a problem. I will look into it. I suggest that we gradually move the files in include/wine to include/wine/wine or in some cases other places like the DLL directories. Eventually, far in the future, the include/wine directory will be empty (save for a wine directory). This provides a slow and steady migration path from the old to the new that doesn't have any of the problems you described. What more can you ask for? > So you are making the normal case more complex to simplify the > very unusual case of mixing headers. I prefer to ask people who want > to mix headers to do some extra steps and make the common case as easy > as possible. As stated above the problem can be solved. Wine itself is AFAIU (not tested) fixed by this patch. Nothing more should be needed. Index: Make.rules.in =================================================================== RCS file: /home/wine/wine/Make.rules.in,v retrieving revision 1.131 diff -u -r1.131 Make.rules.in --- Make.rules.in 19 Oct 2002 17:15:00 -0000 1.131 +++ Make.rules.in 22 Oct 2002 09:02:33 -0000 @@ -45,7 +45,7 @@ LN = @LN@ LN_S = @LN_S@ TOOLSDIR = @TOOLSDIR@ -DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include $(EXTRAINCL) +DIVINCL = -I$(SRCDIR) -I. -I$(TOPSRCDIR)/include -I$(TOPOBJDIR)/include -I$(TOPSRCDIR)/include/wine $(EXTRAINCL) ALLCFLAGS = $(DIVINCL) $(CFLAGS) $(DEFS) $(OPTIONS) LD = @LD@ LDFLAGS = @LDFLAGS@ Normal Winelib application have shouldn't (and needn't) use the Wine "extension" header so they don't need the in the include path them. The few application that does, can be very easily fixed simply by adding an additional -I, which isn't to much to ask IMHO. [View Less]

3 2

Problem with X11 driver
by Till Mossakowski 22 Oct '02

22 Oct '02

Hi, I have a problem with the X11 driver (it seems), related to bug 1027. When I run my program (Fitch.exe), wine gets stuck. All threads do a WaitForMultipleObjects, the main thread a WaitMessage. And I get an error err:ntdll:RtlpWaitForCriticalSection section 0x40af4b04 "x11drv_main.c: X11DRV_CritSection" wait timed out, retrying (60 sec) tid=080b8780 I read the FAQ about critical section errors, and it helped my to get the following calling stack: KERNEL32.DLL.WaitForMultipleObjectsEx+… [View More]

2 7

OleAut32.dll.DispCallFunc
by Fabian Cenedese 22 Oct '02

22 Oct '02

Hi all My app stumbled over a not implemented function from oleaut32.dll called DispCallFunc. It's only available as stub. I tried to find some info about this but it's an undocumented "feature". MSDN doesn't mention it at all (obviously) and on the net I could only find this short description: *** ITypeInfo::Invoke (or DispInvoke) needs v-table to call-in a method. But when we are talking about pure disp-interfaces - they don't have any info about v-table, but just a mapping between … [View More]

2 1

Re: MZ_Exec() patch, try 3
by Jukka Heinonen 22 Oct '02

22 Oct '02

The patch starts to look good, only one tiny thing left: you most likely want to return FALSE from MZ_Exec if CreateProcessA fails. If you want to read all comments to posts on wine-devel you have to take into account different time zones and different mail reading habits - waiting 24 hours should be enough to get replies from all active readers during weekdays. But, anyway, good to see I didn't scare you by being critical :) -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

VS6 Package & Deployment Wizard regression
by Ender 22 Oct '02

22 Oct '02

Oddly, some recent change has broken some of the command buttons in VS6's Package/Deployment wizard's dialogs.. Does anyone have any suggestions on what'd be some good traces to turn on? Or want to fix it themselves? <grin> - Ender

1 0

RE: [RFC] Adding an include/wine/wine directory?
by Patrik Stridvall 22 Oct '02

22 Oct '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > I would like to have a directory structure like > > > > include: Wine's version of Windows headers > > include/wine: Wine's internal headers > > include/wine/wine: Wine's "extension" headers > > > > With "extension" headers I mean that headers that > > are exported and usuable by Winelib applications. > > That's ugly IMO. The specific solution above, perhaps. However I … [View More]think it would be very useful to make a proper distinction between 1. The Wine version of Microsoft headers 2. Anything that Wine uses to communicate internal 3. Extensions that Winelib applications can use. Perhaps (2) and (3) are not much different (se below), but (1) and (2/3) are clearly different. That is why I think "-I../../include" shouldn't automatically give you (2) and (3) as it does now. Having to add -I../../include/wine or whatever to get it would make it possible in addition to solving my MSVC Microsoft header problem to make it possible to uses the Microsoft headers or whomevers headers even on Linux. > Besides there is no such distinction between internal > and "extension" headers, all the headers in include/wine are supposed > to be usable by Winelib app. Sure there are. Not all header from include/wine are copied to /usr/local/include/wine/wine during. The ones that are not copied are "internal" and the ones there are are "extensions" in some meaning. Only the "exension" headers (ie header that are copied during install) can be used by Winelib applications. However that might perhaps only be a temporary distiction. Anyway cd include/wine mkdir wine mv *.h wine work for me as well if you prefer that. > I'd suggest you simply copy the ones you > need with MSVC somewhere else to avoid conflicts. Hmm. Yes, that is another possibillity (read: kludge). Don't really like copying source files around, but it would work (with the possible exception of dependecies, but then "Rebuild all" is your friend :-). In short: I still think that we should require another -I to access the Wine specific (internal and extension) headers. However I don't really care if we do (1) -I$(TOPSRCDIR)/include -I$(TOPSRCDIR)/include/wine (2) -I$(TOPSRCDIR)/include -I$(TOPSRCDIR)/$(WHATEVER) I just don't think just doing -I$(TOPSRCDIR)/include like now is good for the reasons given above and below. Sometime you only want the Wine specific header sometimes you only want Wine's version of the Windows header. "Forcing" everybody to take them as a package only gives rise to unnessary problem like the one I'm trying to solve. Sure I could kludge it, but why not try to solve it properly? [View Less]

3 2

MZ_Exec() patch, try 3
by chrismorgan＠rcn.com 22 Oct '02

22 Oct '02

Alright, yet another revision of this patch. This one uses dynamic memory allocation via HeapAlloc/Free(), doesn't modify the input command line and doesn't try to close process handles if CreateProcess failed. Third time a charm? ;-) * dlls/winedos/module.c: Chris Morgan <cmorgan(a)alum.wpi.edu> Call CreateProcessA() when executing non-dos applications from a dos application. Index: dlls/winedos/module.c =================================================================== RCS file: … [View More]/home/wine/wine/dlls/winedos/module.c,v retrieving revision 1.23 diff -u -r1.23 module.c --- dlls/winedos/module.c 18 Oct 2002 23:48:58 -0000 1.23 +++ dlls/winedos/module.c 21 Oct 2002 22:00:16 -0000 @@ -339,17 +339,78 @@ /*********************************************************************** * MZ_Exec + * + * this may only be called from existing DOS processes */ BOOL WINAPI MZ_Exec( CONTEXT86 *context, LPCSTR filename, BYTE func, LPVOID paramblk ) { - /* this may only be called from existing DOS processes - * (i.e. one DOS app spawning another) */ - /* FIXME: do we want to check binary type first, to check - * whether it's a NE/PE executable? */ + DWORD binType; + STARTUPINFOA st; + PROCESS_INFORMATION pe; + BOOL status; + HANDLE hFile = CreateFileA( filename, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, 0); BOOL ret = FALSE; + + if(!GetBinaryTypeA(filename, &binType)) /* determine what kind of binary this is */ + { + return FALSE; /* binary is not an executable */ + } + if (hFile == INVALID_HANDLE_VALUE) return FALSE; + + /* handle non-dos executables */ + if(binType != SCS_DOS_BINARY) + { + if(func == 0) /* load and execute */ + { + LPBYTE fullCmdLine; + WORD fullCmdLength; + LPBYTE psp_start = (LPBYTE)((DWORD)DOSVM_psp << 4); + PDB16 *psp = (PDB16 *)psp_start; + ExecBlock *blk = (ExecBlock *)paramblk; + LPBYTE cmdline = PTR_REAL_TO_LIN(SELECTOROF(blk->cmdline),OFFSETOF(blk->cmdline)); + LPBYTE envblock = PTR_REAL_TO_LIN(psp->environment, 0); + BYTE cmdLength = cmdline[0]; + + fullCmdLength = (strlen(filename) + 1) + cmdLength + 1; /* filename + space + cmdline + terminating null character */ + + fullCmdLine = HeapAlloc(GetProcessHeap(), 0, fullCmdLength); + + /* build the full command line from the executable file and the command line being passed in */ + snprintf(fullCmdLine, fullCmdLength, "%s ", filename); /* start off with the executable filename and a space */ + memcpy(fullCmdLine + strlen(fullCmdLine), cmdline + 1, cmdLength); /* append cmdline onto the end */ + fullCmdLine[fullCmdLength - 1] = 0; /* null terminate string */ + + ZeroMemory (&st, sizeof(STARTUPINFOA)); + st.cb = sizeof(STARTUPINFOA); + status = CreateProcessA (NULL, fullCmdLine, NULL, NULL, TRUE, + 0, envblock, NULL, &st, &pe); + + WaitForSingleObject(pe.hProcess, INFINITE); /* wait here until the child process is complete */ + + HeapFree(GetProcessHeap(), 0, fullCmdLine); /* free the memory we allocated */ + + /* clean up PROCESS_INFORMATION handles if necessary */ + if(status) + { + CloseHandle(pe.hProcess); + CloseHandle(pe.hThread); + } + + ret = TRUE; + } else + { + FIXME("EXEC type of %d not implemented for non-dos executables\n", func); + ret = FALSE; + } + + CloseHandle(hFile); + return ret; + } /* if(binType != SCS_DOS_BINARY) */ + + /* handle dos executables */ switch (func) { case 0: /* load and execute */ case 1: /* load but don't execute */ [View Less]

3 4

Re: Listview V15
by Bobby Bingham 21 Oct '02

21 Oct '02

On Mon, Oct 21, 2002 at 10:51:35AM -0400, Dimitrie O. Paun wrote: > > ChangeLog > Updated header documentation to the latest, and greatest. > <snip> > + * -- LVIS_ACTIVATING (not currently supported my comctl32.dll version 6.0) you mean "by" comctl32.dll version 6.0 ? <snip> > + * -- LVN_BEGINDRAG, LVN_BEGINRDRAG hmmm ... how about "LVN_BEGINFRAG, LVN_ENDDRAG" -- Bobby Bingham

2 2

compile with -DSTRICT
by Michael Stefaniuc 21 Oct '02

21 Oct '02

Hello, i'm not 100% sure what -DWINE_NO_STRICT should do, but i suspect it should negate the effect of -DSTRICT. The attached patch enables that and lets wine compile with -DSTRICT where WINE_NO_STRICT isn't defined. Comments? bye michael P.S.: is this -DSTRICT a m$ windows thing or a wine only thing? -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com … [View More]

2 2

Small DDraw problem...
by Lionel Ulmer 21 Oct '02

21 Oct '02

Hi all, I looked at this problem a long time and did not find what the problem is... So I ask for the help of people here :-) Some TRACE extracts : trace:ddraw:DirectDrawCreate ((null),0x406a2b80,(nil)) trace:ddraw:DDRAW_Create Returning interface 0x403b48bc | the DirectDraw interface trace:ddraw:Main_DirectDraw_QueryInterface (0x403b48b0)->({9c59509a-39bd-11d1-8c4a-00c04fd930c5},0x406a2b84) trace:ddraw:Main_DirectDraw_QueryInterface … [View More]

2 2

Second Listview status update
by Dimitrie O. Paun 21 Oct '02

21 Oct '02

Folks, The listview should now be better than before I started working on it. If there are regressions, I would like to know about them. During my work, the REPORT mode got a lot faster rendering. The Q-series patches undoes partly those speed enhancements. However, the situation is temporary, and when I'm done with it, we'll have pretty much as fast a rendering as possible. For this to happen, I need to do a bit more infrastructure work. Namely, we have to keep track of column information,… [View More]

3 19

WM_COPYDATA linear/SEGPTR crash
by Andreas Mohr 21 Oct '02

21 Oct '02

Hi all, Dr. Hardware crashes like that: Backtrace: 0 0x0297:0x01c0 1 0x00f7:0x0000 2 WINPROC_CallWndProc16+0x211(proc=0x2970186, hwnd=0xa4, msg=WM_COPYDATA, wParam=0xab, lParam=0x403cbc48) 3 WINPROC_CallProc32WTo16+0x99(...., , wParam=0x200ab, ...) 4 CallWindowProcW+0x6f(func=0x4ce0458, hwnd=0x400a4, msg=WM_COPYDATA,wParam=0x200ab, lParam=0x403cbc48) 5 call_window_proc(...) 6 MSG_peek_message+0x409(msg=0x410b2a74, hwnd=0x0, first=0x0, last=0xffffffff, flags=1) 7 PeekMessageW+0x7c(msg_out=… [View More]

1 0

RE: LVM_* defs
by Patrik Stridvall 21 Oct '02

21 Oct '02

> Can anyone help me with the definition of these > listview messages? TIA. [snip] grep LVM_ commctrl.h | grep define #define LVM_FIRST 0x1000 // ListView messages #define LVM_SETUNICODEFORMAT CCM_SETUNICODEFORMAT #define LVM_GETUNICODEFORMAT CCM_GETUNICODEFORMAT #define LVM_GETBKCOLOR (LVM_FIRST + 0) #define LVM_SETBKCOLOR (LVM_FIRST + 1) #define LVM_GETIMAGELIST (LVM_FIRST + 2) #define LVM_SETIMAGELIST (LVM_FIRST + 3) #define … [View More]LVM_GETITEMCOUNT (LVM_FIRST + 4) #define LVM_GETITEMA (LVM_FIRST + 5) #define LVM_GETITEMW (LVM_FIRST + 75) #define LVM_GETITEM LVM_GETITEMW #define LVM_GETITEM LVM_GETITEMA #define LVM_SETITEMA (LVM_FIRST + 6) #define LVM_SETITEMW (LVM_FIRST + 76) #define LVM_SETITEM LVM_SETITEMW #define LVM_SETITEM LVM_SETITEMA #define LVM_INSERTITEMA (LVM_FIRST + 7) #define LVM_INSERTITEMW (LVM_FIRST + 77) #define LVM_INSERTITEM LVM_INSERTITEMW #define LVM_INSERTITEM LVM_INSERTITEMA #define LVM_DELETEITEM (LVM_FIRST + 8) #define LVM_DELETEALLITEMS (LVM_FIRST + 9) #define LVM_GETCALLBACKMASK (LVM_FIRST + 10) #define LVM_SETCALLBACKMASK (LVM_FIRST + 11) #define LVM_GETNEXTITEM (LVM_FIRST + 12) #define LVM_FINDITEMA (LVM_FIRST + 13) #define LVM_FINDITEMW (LVM_FIRST + 83) #define LVM_FINDITEM LVM_FINDITEMW #define LVM_FINDITEM LVM_FINDITEMA #define LVM_GETITEMRECT (LVM_FIRST + 14) #define LVM_SETITEMPOSITION (LVM_FIRST + 15) #define LVM_GETITEMPOSITION (LVM_FIRST + 16) #define LVM_GETSTRINGWIDTHA (LVM_FIRST + 17) #define LVM_GETSTRINGWIDTHW (LVM_FIRST + 87) #define LVM_GETSTRINGWIDTH LVM_GETSTRINGWIDTHW #define LVM_GETSTRINGWIDTH LVM_GETSTRINGWIDTHA #define LVM_HITTEST (LVM_FIRST + 18) #define LVM_ENSUREVISIBLE (LVM_FIRST + 19) #define LVM_SCROLL (LVM_FIRST + 20) #define LVM_REDRAWITEMS (LVM_FIRST + 21) #define LVM_ARRANGE (LVM_FIRST + 22) #define LVM_EDITLABELA (LVM_FIRST + 23) #define LVM_EDITLABELW (LVM_FIRST + 118) #define LVM_EDITLABEL LVM_EDITLABELW #define LVM_EDITLABEL LVM_EDITLABELA #define LVM_GETEDITCONTROL (LVM_FIRST + 24) #define LVM_GETCOLUMNA (LVM_FIRST + 25) #define LVM_GETCOLUMNW (LVM_FIRST + 95) #define LVM_GETCOLUMN LVM_GETCOLUMNW #define LVM_GETCOLUMN LVM_GETCOLUMNA #define LVM_SETCOLUMNA (LVM_FIRST + 26) #define LVM_SETCOLUMNW (LVM_FIRST + 96) #define LVM_SETCOLUMN LVM_SETCOLUMNW #define LVM_SETCOLUMN LVM_SETCOLUMNA #define LVM_INSERTCOLUMNA (LVM_FIRST + 27) #define LVM_INSERTCOLUMNW (LVM_FIRST + 97) # define LVM_INSERTCOLUMN LVM_INSERTCOLUMNW # define LVM_INSERTCOLUMN LVM_INSERTCOLUMNA #define LVM_DELETECOLUMN (LVM_FIRST + 28) #define LVM_GETCOLUMNWIDTH (LVM_FIRST + 29) #define LVM_SETCOLUMNWIDTH (LVM_FIRST + 30) #define LVM_GETHEADER (LVM_FIRST + 31) #define LVM_CREATEDRAGIMAGE (LVM_FIRST + 33) #define LVM_GETVIEWRECT (LVM_FIRST + 34) #define LVM_GETTEXTCOLOR (LVM_FIRST + 35) #define LVM_SETTEXTCOLOR (LVM_FIRST + 36) #define LVM_GETTEXTBKCOLOR (LVM_FIRST + 37) #define LVM_SETTEXTBKCOLOR (LVM_FIRST + 38) #define LVM_GETTOPINDEX (LVM_FIRST + 39) #define LVM_GETCOUNTPERPAGE (LVM_FIRST + 40) #define LVM_GETORIGIN (LVM_FIRST + 41) #define LVM_UPDATE (LVM_FIRST + 42) #define LVM_SETITEMSTATE (LVM_FIRST + 43) #define LVM_GETITEMSTATE (LVM_FIRST + 44) #define LVM_GETITEMTEXTA (LVM_FIRST + 45) #define LVM_GETITEMTEXTW (LVM_FIRST + 115) #define LVM_GETITEMTEXT LVM_GETITEMTEXTW #define LVM_GETITEMTEXT LVM_GETITEMTEXTA #define LVM_SETITEMTEXTA (LVM_FIRST + 46) #define LVM_SETITEMTEXTW (LVM_FIRST + 116) #define LVM_SETITEMTEXT LVM_SETITEMTEXTW #define LVM_SETITEMTEXT LVM_SETITEMTEXTA #define LVM_SETITEMCOUNT (LVM_FIRST + 47) #define LVM_SORTITEMS (LVM_FIRST + 48) #define LVM_SETITEMPOSITION32 (LVM_FIRST + 49) #define LVM_GETSELECTEDCOUNT (LVM_FIRST + 50) #define LVM_GETITEMSPACING (LVM_FIRST + 51) #define LVM_GETISEARCHSTRINGA (LVM_FIRST + 52) #define LVM_GETISEARCHSTRINGW (LVM_FIRST + 117) #define LVM_GETISEARCHSTRING LVM_GETISEARCHSTRINGW #define LVM_GETISEARCHSTRING LVM_GETISEARCHSTRINGA #define LVM_SETICONSPACING (LVM_FIRST + 53) #define LVM_SETEXTENDEDLISTVIEWSTYLE (LVM_FIRST + 54) // optional wParam == mask #define LVM_GETEXTENDEDLISTVIEWSTYLE (LVM_FIRST + 55) #define LVM_GETSUBITEMRECT (LVM_FIRST + 56) #define LVM_SUBITEMHITTEST (LVM_FIRST + 57) #define LVM_SETCOLUMNORDERARRAY (LVM_FIRST + 58) #define LVM_GETCOLUMNORDERARRAY (LVM_FIRST + 59) #define LVM_SETHOTITEM (LVM_FIRST + 60) #define LVM_GETHOTITEM (LVM_FIRST + 61) #define LVM_SETHOTCURSOR (LVM_FIRST + 62) #define LVM_GETHOTCURSOR (LVM_FIRST + 63) #define LVM_APPROXIMATEVIEWRECT (LVM_FIRST + 64) #define LVM_SETWORKAREAS (LVM_FIRST + 65) #define LVM_GETWORKAREAS (LVM_FIRST + 70) #define LVM_GETNUMBEROFWORKAREAS (LVM_FIRST + 73) #define LVM_GETSELECTIONMARK (LVM_FIRST + 66) #define LVM_SETSELECTIONMARK (LVM_FIRST + 67) #define LVM_SETHOVERTIME (LVM_FIRST + 71) #define LVM_GETHOVERTIME (LVM_FIRST + 72) #define LVM_SETTOOLTIPS (LVM_FIRST + 74) #define LVM_GETTOOLTIPS (LVM_FIRST + 78) #define LVM_SORTITEMSEX (LVM_FIRST + 81) #define LVM_SETBKIMAGEA (LVM_FIRST + 68) #define LVM_SETBKIMAGEW (LVM_FIRST + 138) #define LVM_GETBKIMAGEA (LVM_FIRST + 69) #define LVM_GETBKIMAGEW (LVM_FIRST + 139) #define LVM_SETSELECTEDCOLUMN (LVM_FIRST + 140) #define LVM_SETTILEWIDTH (LVM_FIRST + 141) #define LVM_SETVIEW (LVM_FIRST + 142) #define LVM_GETVIEW (LVM_FIRST + 143) #define LVM_INSERTGROUP (LVM_FIRST + 145) #define LVM_SETGROUPINFO (LVM_FIRST + 147) #define LVM_GETGROUPINFO (LVM_FIRST + 149) #define LVM_REMOVEGROUP (LVM_FIRST + 150) #define LVM_MOVEGROUP (LVM_FIRST + 151) #define LVM_MOVEITEMTOGROUP (LVM_FIRST + 154) #define LVM_SETGROUPMETRICS (LVM_FIRST + 155) #define LVM_GETGROUPMETRICS (LVM_FIRST + 156) #define LVM_ENABLEGROUPVIEW (LVM_FIRST + 157) #define LVM_SORTGROUPS (LVM_FIRST + 158) #define LVM_INSERTGROUPSORTED (LVM_FIRST + 159) #define LVM_REMOVEALLGROUPS (LVM_FIRST + 160) #define LVM_HASGROUP (LVM_FIRST + 161) #define LVM_SETTILEVIEWINFO (LVM_FIRST + 162) #define LVM_GETTILEVIEWINFO (LVM_FIRST + 163) #define LVM_SETTILEINFO (LVM_FIRST + 164) #define LVM_GETTILEINFO (LVM_FIRST + 165) #define LVM_SETINSERTMARK (LVM_FIRST + 166) #define LVM_GETINSERTMARK (LVM_FIRST + 167) #define LVM_INSERTMARKHITTEST (LVM_FIRST + 168) #define LVM_GETINSERTMARKRECT (LVM_FIRST + 169) #define LVM_SETINSERTMARKCOLOR (LVM_FIRST + 170) #define LVM_GETINSERTMARKCOLOR (LVM_FIRST + 171) #define LVM_SETINFOTIP (LVM_FIRST + 173) #define LVM_GETSELECTEDCOLUMN (LVM_FIRST + 174) #define LVM_ISGROUPVIEWENABLED (LVM_FIRST + 175) #define LVM_GETOUTLINECOLOR (LVM_FIRST + 176) #define LVM_SETOUTLINECOLOR (LVM_FIRST + 177) #define LVM_CANCELEDITLABEL (LVM_FIRST + 179) #define LVM_MAPINDEXTOID (LVM_FIRST + 180) #define LVM_MAPIDTOINDEX (LVM_FIRST + 181) #define LVM_SETBKIMAGE LVM_SETBKIMAGEW #define LVM_GETBKIMAGE LVM_GETBKIMAGEW #define LVM_SETBKIMAGE LVM_SETBKIMAGEA #define LVM_GETBKIMAGE LVM_GETBKIMAGEA [View Less]

1 0

LVM_* defs
by Dimitrie O. Paun 21 Oct '02

21 Oct '02

Can anyone help me with the definition of these listview messages? TIA. LVM_CANCELEDITLABEL LVM_CREATEDRAGIMAGE LVM_ENABLEGROUPVIEW LVM_GETBKIMAGE LVM_GETGROUPINFO LVM_GETGROUPMETRICS LVM_GETINSERTMARK LVM_GETINSERTMARKCOLOR LVM_GETINSERTMARKRECT LVM_GETOUTLINECOLOR LVM_GETSELECTEDCOLUMN LVM_GETTILEINFO LVM_GETTILEVIEWINFO LVM_GETUNICODEFORMAT LVM_GETVIEW LVM_HASGROUP LVM_INSERTGROUP LVM_INSERTGROUPSORTED LVM_INSERTMARKHITTEST LVM_ISGROUPVIEWENABLED LVM_MAPIDTOINDEX LVM_MAPINDEXTOID … [View More]

1 0

Msg help
by Dimitrie O. Paun 21 Oct '02

21 Oct '02

Anyone know the message name for the codes: 2486 2793 The progress bar receives them, and complains because it doesn't know what they are... -- Dimi.

1 0

RtlAllocateHeap crash
by Dimitrie O. Paun 21 Oct '02

21 Oct '02

While I was playing around with Newsbin Pro, I stumbled over this: Unhandled exception: page fault on write access to 0x0000000c in 32-bit code (0x400c2eaa). In 32-bit mode. 0x400c2eaa (RtlAllocateHeap+0xda [heap.c:1039] in libntdll.dll.so): movl %eax,0xc(%edx) 1040 pArena->prev->next = pArena->next; Is it worth investigating? -- Dimi.

1 0

Re: WebBrowser
by Dimitrie O. Paun 21 Oct '02

21 Oct '02

On October 19, 2002 03:27 am, Malte Starostik wrote: > ChangeLog > * Fixed IWebBrowser::Navigate() parameter type > * Added IWebBrowserApp and related typedefs BTW, any taker on implementing IWebBrowser & Co. in terms of the Gecko API, so we can get Mozilla working through Wine? -- Dimi.

3 4

Re: glibc 2.3 pthread patch
by Alexandre Julliard 20 Oct '02

20 Oct '02

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Now that glibc 2.3 is available for those bleeding-edge folks on debian > unstable, it seems that Wines compiled on 2.2 won't run on 2.3 systems. > The glibc folks did warn us about this a while ago though, so here's a > patch that implements their suggestion for making wine compatible with as > many glibc versions as possible. Perhaps Alexandre wants to use his > WINE_GET_SONAME stuff to detect the name of the libc at … [View More]configure time > instead of at runtime like I do, though. Funny, I was working on the same thing right now... But do you really need to fetch the real libc handle? It seems to me RTLD_NEXT should be enough. Here's how I did it: Index: scheduler/pthread.c =================================================================== RCS file: /opt/cvs-commit/wine/scheduler/pthread.c,v retrieving revision 1.26 diff -u -r1.26 pthread.c --- scheduler/pthread.c 12 Sep 2002 22:07:06 -0000 1.26 +++ scheduler/pthread.c 20 Oct 2002 21:45:13 -0000 @@ -38,13 +38,6 @@ #include "thread.h" #include "winternl.h" -static int init_done; - -void PTHREAD_init_done(void) -{ - init_done = 1; -} - /* Currently this probably works only for glibc2, * which checks for the presence of double-underscore-prepended * pthread primitives, and use them if available. @@ -62,28 +55,18 @@ asm(".globl " PSTR(alias) "\n" \ "\t.set " PSTR(alias) "," PSTR(orig)) -/* strong_alias does not work on external symbols (.o format limitation?), - * so for those, we need to use the pogo stick */ -#if defined(__i386__) && !defined(__PIC__) -/* FIXME: PIC */ -#define jump_alias(orig, alias) __ASM_GLOBAL_FUNC( alias, "jmp " PSTR(orig)) -#endif +static int init_done; -/* get necessary libc symbols */ -#if (__GLIBC__ == 2) && (__GLIBC_MINOR__ >= 1) && defined(HAVE___LIBC_FORK) -#define LIBC_FORK __libc_fork -#define PTHREAD_FORK __fork -#define ALIAS_FORK -#else -#define LIBC_FORK __fork -#define PTHREAD_FORK fork -#endif -extern pid_t LIBC_FORK(void); +static pid_t (*libc_fork)(void); +static int (*libc_sigaction)(int signum, const struct sigaction *act, struct sigaction *oldact); + +void PTHREAD_init_done(void) +{ + init_done = 1; + if (!libc_fork) libc_fork = dlsym( RTLD_NEXT, "fork" ); + if (!libc_sigaction) libc_sigaction = dlsym( RTLD_NEXT, "sigaction" ); +} -#define LIBC_SIGACTION __sigaction -extern int LIBC_SIGACTION(int signum, - const struct sigaction *act, - struct sigaction *oldact); /* NOTE: This is a truly extremely incredibly ugly hack! * But it does seem to work... */ @@ -255,15 +238,20 @@ } strong_alias(__pthread_atfork, pthread_atfork); -pid_t PTHREAD_FORK(void) +pid_t __fork(void) { pid_t pid; int i; + if (!libc_fork) + { + libc_fork = dlsym( RTLD_NEXT, "fork" ); + assert( libc_fork ); + } EnterCriticalSection( &atfork_section ); /* prepare handlers are called in reverse insertion order */ for (i = atfork_count - 1; i >= 0; i--) if (atfork_prepare[i]) atfork_prepare[i](); - if (!(pid = LIBC_FORK())) + if (!(pid = libc_fork())) { InitializeCriticalSection( &atfork_section ); for (i = 0; i < atfork_count; i++) if (atfork_child[i]) atfork_child[i](); @@ -275,9 +263,7 @@ } return pid; } -#ifdef ALIAS_FORK -strong_alias(PTHREAD_FORK, fork); -#endif +strong_alias(__fork, fork); /***** MUTEXES *****/ @@ -658,13 +644,20 @@ /***** ANTI-OVERRIDES *****/ /* pthreads tries to override these, point them back to libc */ -#ifdef jump_alias -jump_alias(LIBC_SIGACTION, sigaction); -#else int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact) { - return LIBC_SIGACTION(signum, act, oldact); + if (!libc_sigaction) + { + libc_sigaction = dlsym( RTLD_NEXT, "sigaction" ); + assert( libc_sigaction ); + } + return libc_sigaction(signum, act, oldact); +} + +#else /* __GLIBC__ */ + +void PTHREAD_init_done(void) +{ } -#endif #endif /* __GLIBC__ */ -- Alexandre Julliard julliard(a)winehq.com [View Less]

2 2

Known listview problems
by Dimitrie O. Paun 20 Oct '02

20 Oct '02

Folks, Things look pretty good on the listview front. In fact, I am kindda happy the way things are, as the S-series patches were rather tricky at points... Currently, I know of the following problems: -- Newsbin dies swiftly (reported my Rein Klazes) -- FTPCommander seems to experience some listview-related faults (reported by Carlos Lozano) -- Xnews has some minor focus rectangle problems (discovered by myself :)) -- IDAdemo _may_ have some minor drawing glitches … [View More]

3 6

configuration
by Eric Pouech 20 Oct '02

20 Oct '02

I dunno if Alexandre will like this patch, but - when compiling with --disable-win16 turned on - the glue generation is based on the C_SRCS16 files as well as the C_SRCS - this, of course, brings in lots of unneed imports (triggered by the non needed glue code) the attached patch, when wine compilation is configured with --disable-win16, removes all 16 bit .c files from the inspection for glue generation this might not be sufficient: - the .glue.c file is generated in any case - however, it … [View More]

2 1

Listview regression
by David D. Hagood 20 Oct '02

20 Oct '02

I've just applied/built/installed/tested the U series patches, and I have 2 regressions in the AAA MapNGo program: First, the first column of the directions window (which shows the type of road) is missing. Second, when I do the "Along the way", the program cores out. The log, and a screen cap showing (or rather, NOT showing) the missing field in the directions window, are in a tarball: http://sktc.net/~wowbagger/listview3.tar.gz

2 10

Fw: Wine problem
by Leonardo Bocalon 20 Oct '02

20 Oct '02

Hello it´s me again , i tried the procedure that you told me to do, I downloaded the last version of the wine, i installed it and still not working the keyboard display. Trying to explain to you more specifically the problem I´m going to send you the log which was the problem!!(I compacted whit .lha). I also want to know how to register (use) the files virtual drivers ( VXD)! Thanks again for you atention. Leonardo Bocalon Sysmo Informática / Brasil ----- Original … [View More]

5 4

Re: DPA_InsertPtr (A1)
by Dimitrie O. Paun 20 Oct '02

20 Oct '02

On October 20, 2002 12:33 pm, Paul Rupe wrote: > I was just looking at this same problem. Should we not also remove the > line hdpa->nItemCount++? DPA_SetPtr already does this (which is why we > needed the -1 you added), so I think we end up incrementing it twice. You are correct. I've actually sent the patch in about 5minutes ago ... :) > For comparison, here's the patch I was about to send (relative to the first > comctl32undoc.c patch): Yup, that's what we need to end … [View More]

1 0

Re: InstallShield
by Jeff Smith 20 Oct '02

20 Oct '02

Already running builtin ole32/oleaut32/rpcrt4. I have stdole2.tlb and stdole32.tlb, but no tbl files. Am I missing something? Any further thoughts? BTW, the only command-line message I get is: "fixme:seh:check_resource_write Broken app is writing to the resource data, enabling work-around" - Thanks - Jeff S. > >>>>> "Jeff" == Jeff Smith <whydoubt(a)hotmail.com> writes: > > Jeff> Trying to install the Music Ace Demo (harmonicvision.com), I get > … [View More]

2 1

DOS/Win16 interrupt handling architecture
by Jukka Heinonen 20 Oct '02

20 Oct '02

I have been thinking about interrupt handling in Wine because it needs some reworking in order to get DPMI32 programs to work. I have formed a proposal for refactoring current interrupt handling code and I would like to get some comments about this scheme before I decide whether I want to work on it or not. So, my proposal is to move all interrupt handlers to winedos dll and have only single interrupt handler routine per interrupt, instead of having separate real and protected mode handlers. … [View More]

3 4

WANTED (dead or alive): additional AppDB maintainer
by Andreas Mohr 20 Oct '02

20 Oct '02

Hi all, as I'm currently in my studies duties again and the AppDB submissions are piling up enormously (> 20 new entries in less than two weeks), I'm looking for one or two additional AppDB maintainers to do the Beowulf thingy ;-) (I'm talking about http://appdb.winehq.org, here) The job description can be found at http://www.winehq.org/about/index.php?contrib#active Sadly enough, this description page has been online for several months now, with (almost ?) nobody applying for any jobs listed. Thanks, Andi

4 3

InstallShield
by Jeff Smith 20 Oct '02

20 Oct '02

Trying to install the Music Ace Demo (harmonicvision.com), I get stopped by a messagethat "The InstallShield Engine (iKernel.exe) could not be installed. (0x20)" I think someone said DCOM98 needs to be installed for InstallShield to work properly, so I did, and nothing changed. Anybody got a take on what I need to try next? -- Jeff S. _________________________________________________________________ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp

2 1

Appplied U[1-5], still faults
by David D. Hagood 19 Oct '02

19 Oct '02

Applied and tested listview patches through U5 - The road type column in the directions window is back (good), but the system still dies on the Along the way (bad), with the same assertion failure as the previous report.

2 1

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