Re: [wined3d] Converting Wined3d to use WGL instead of GLX
On Friday 16 December 2005 23:07, Aric Cyr wrote:
> Last time I checked gcc doesn't enable optimizations unless a -O option is
> specified explicitly (don't know if this has changed though).
I realize it is a moot point wrt the topic, but as you may know, there's an
easy way to check. Running
sh$ echo 'main () {}' > bloated.c
sh$ gcc -v -Q $CFLAGS bloated.c
will, amongst other things, dump exactly what optimizations (in terms of
atomic gcc command-line optimizations) are used given the current setup and
CFLAGS environment variable.
My 3.4.4 does indeed do exactly the same thing with "-g" and "-g -O0".
--
gmt
Re: Software patents
On Friday 13 May 2005 19:07, Gregory M. Turner wrote: > Code using the C syntax described in the patent doesn't compile in winelib > yet [snip]. Give me a week or two... Imagine that, it seems I have once again imagined myself to have more spare time than I really do. Honestly, folks, I can't wait to lay into __TRY & family -- especially since that work brings me closer to __try & family for winelib, which, as far as I'm concerned, is unfinished business -- but I simply am not in a position to do anything about it until I finish my dissertation and take care of some other pressing matters. Regardless, I am still alive and still plan to do this, sooner than later. In the meanwhile, I'm glad to see that the rest of you are being better wine hackers than I! "I'll be back," -- gmt
Re: OK I give up
On Saturday 11 June 2005 03:37, James Hawkins wrote: > On 6/10/05, Gregory M. Turner <[EMAIL PROTECTED]> wrote: > > How do I run the wine test suite under Windows again? I want to do this > > by compiling from source. > > > > I know the answer is out there -- maybe I have even asked this once > > before and been given the answer? But I can't find it for the life of > > me. > > http://www.winehq.org/site/docs/wine-devel/testing-windows > > Check out that site and make sure you have the Platform SDK installed. > Everything should work for you then. If you have problems, write > back to the list and we'll help you out. d'oh! How embarrassing, right there in the developer's guide. Thanks. -- gmt
OK I give up
How do I run the wine test suite under Windows again? I want to do this by compiling from source. I know the answer is out there -- maybe I have even asked this once before and been given the answer? But I can't find it for the life of me. -- gmt
Re: [PATCH] FCI work for cabinet.dll [cabinet-fci-patch-02b.diff]
On Wednesday 08 June 2005 18:16, Dimi Paun wrote: > Also, I know you're modifying existing code, but if it's not > too much to ask, 2-space indent is hard to read, and the vast > majority of developers do prefer 4-space indent. So if you > don't mind, and we can find a solution, would be great if we > can stick to 4-spaces instead. Probably because I put all the cabinet.dll sources this way, as I am a two-space freak (and maybe because the code had too much nesting for four? Also it might have been this way when I cut-and-pasted it :P ) -- gmt
Getting back into the swing of things...
Hello, as you may recall I would like to start playing with SEH macros for winelib (and maybe wine). I have not done any wine development for a year or so, and have not followed the mailing list very carefully. Anyone have any advice for me wrt getting up-to-speed? I am aware of the wiki and will peruse it carefully. Also, I will look through winehq and try to see what is new there. Please let me know if you think of anything else I should definitely be looking at. Also, it seems that my work may involve some autoconf tinkering... I have tried to study up on autoconf in the past, with disappointing results. Does anyone know what is a good beginner's resource for learning the gnu auto.* tools? Thanks! -- gmt
Re: Software patents
On Friday 13 May 2005 15:09, Francois Gouget wrote: > * The Slashdot summary makes it sound like Wine is infringing on the > patent and that we will have to remove some code. Wine duplicates many of the data structures in Windows which are described in the patent. Code using the C syntax described in the patent doesn't compile in winelib yet, but this has nothing to do with the patent. Give me a week or two... I don't think you can implement a Windows compatible environment without the SEH datastructures described in the patent. IANAL, but saying "windows compatibility is patented by Borland" is just silly. I, for one, am not worried about it. -- gmt
Re: Revisiting exceptions
On Monday 09 May 2005 10:00, Boaz Harrosh wrote: > >"Jonathan Wilson" <[EMAIL PROTECTED]> wrote: > >>Why doesnt someone just implement the microsoft SEH keywords and > >> extentions into GCC like it should be? > > Do you have any knowledge of GCC, to be able to do it, or help me do it? The code exists to do it, or used to, but there are technical and institutional barriers to inclusion in mainline gcc. > Dmitry Timoshkov wrote: > >Because it's patented by Borland? > > Do you have any reference to the patent? It looks to me like it is easy > to by-pass by using different key words and than the user can Just > define them to the MS ones. US Patent #5,628,016, Kukol, May 6, 1997. And you can't patent a name, so changing names won't help. But you can patent wiping your ass after defecating. Which is basically what Borland has done here. -- gmt
Re: Revisiting exceptions
On Monday 09 May 2005 11:29, Mike Hearn wrote: > On Mon, 09 May 2005 07:41:46 +0000, Gregory M. Turner wrote: > > As for the portability issue, why not an autoconf test? Perhaps the > > answer is "because there are still people foolish enough to run distro's > > other than Gentoo." If so, then why not an autoconf test and a run-time > > test? > > Hurrah! Well, this doesn't need any runtime code AFAICT, just GCC support. > So a simple ifdef should be A-OK. Cool will be interesting to see how they did it. -- gmt
Re: Revisiting exceptions
On Friday 06 May 2005 18:51, Mike Hearn wrote: > On Fri, 2005-05-06 at 16:23 +0200, Alexandre Julliard wrote: > > They clearly won't work as is, but if your question is whether it's > > possible to use attribute((cleanup)), then yes you could probably use > > that to make the current macros more compatible. Obviously that would > > be only as an option for Winelib apps since it's not portable. > > Sure, that's what I was asking. I wanted to see if we could make > break/continue/return work inside TRY macros, which this technique seems > to give. As we already decided it'd need compiler support it's no big > deal that it's not portable (between compilers). At least it probably > works on an unmodified GCC. > > So now if somebody wants to go ahead and improve our SEH macros using > this technique, please, be my guest ... Mike, you wicked, evil man! I have exams to study for! BTW, hi everybody. No promises, but maybe in a few weeks, I will look at this. As for the portability issue, why not an autoconf test? Perhaps the answer is "because there are still people foolish enough to run distro's other than Gentoo." If so, then why not an autoconf test and a run-time test? -- gmt
Re: Wine and industrial communication like OPC
On Thursday 02 September 2004 10:27 am, Juan Lang wrote: > Greg, you still lurking around here? Yes. But I am worthless atm due to being totally swamped in preparation for going overseas to study. Unfortunately, I am not optimistic about how much time I will have once I am a student... however, eventually I will return to wine work -- I may not remember how to code but I'll be back :). In the meantime y'all are doing a great job of fixing my bugs :P ... I figure I can get y'all to complete my work at about a 50% rate just by ignoring it... Anyhow I have nothing positive to contribute to the discussion... the idea of hacking samba/kernel instead of wine is interesting though, I never gave that much thought but it sounds like a potentially quite effective approach. -- gmt
Re: Branching/version control [was Re: cards.dll]
On Wednesday 17 March 2004 07:44 am, Mike Hearn wrote:
> Another thing I'd really like to see is a move to GNU arch version control
>
> What do people think?
I'm using it at my new job and it's pretty dope imho. There are a few
downsides, some already have been mentioned (those--horrible--names, for
example). Others I have noticed:
o Too many VC files & VC Files mixed in too liberally with your real source
("inventory" helps ameliorate this, but still...)
o Not the best win32 support AFAIK
o working in /x/y/z amazingly requires write permission at /x/y! stupid.
o horrible, confusing error messages
o no fancy integration with your favorite GUI yet
Despite the above and a few other nits, I really like it. Even
those--damn--names start to get comfortable once your ring finger builds up
the requisite strength & dexterity :)
--
gmt
"How prone all human institutions have been to decay; how subject
the best-formed and most wisely organized governments have been
to lose their check and totally dissolve; how difficult it has
been for mankind, in all ages and countries, to preserve their
dearest rights and best privileges, impelled as it were by an
irresistible fate of despotism." --James Monroe
Re: RPC Update Patch
On Thursday 26 February 2004 03:25 pm, Mike Hearn wrote: > Wow, fantastic! One thing, could you write up some basic info on > the structure of format strings? I'm just a bit concerned that one > day we'll have to rewrite the typelib marshaller to use this interpreter > and not know how, as this stuff is pretty opaque :) They are actually pretty well-documented on MSDN: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/rpc_ndr_format_strings.asp Looks like a lot of work, Robert; thanks for your efforts. -- gmt "We lay it down as a fundamental, that laws, to be just, must give a reciprocation of right; that, without this, they are mere arbitrary rules of conduct, founded in force, and not in conscience." --Thomas Jefferson
Re: how to connect to com object "outside" from wine?
On Sunday 22 February 2004 03:49 pm, Robert van Herk wrote: > maman yonatan wrote: > >so if I understand you properly, you say that there is > >no way doing from _outside_ of wine (no matter what > >kind of com object I have), is that correct? > > Of course there is a way: you could make your own remote procedure call > mechanism. Might be a very cool project, actually, to make an interface > to call objects living a wine, that makes COM accessible from unix! > > However, it will be quite some work. You probably need a server kind of > application that lives in Wine, and a client application that lives in > Linux. Then, you got to make sure that the linux app can connect with > the server, and issue procedure calls to the wine server. Finally, the > wine server should forward actual calls into COM, and return the result > value back to the linux client. > > Thus something like this: > > 1. [COM object(Wine)] <-> 2. [Custom build COM-server(Wine)] <-> 3. > [Client application using the COM object(Linux)] > > Where layer 2 is something needs probably to be implemeted from scratch. > > I don't know how much is known about COM by the wine-people, but I guess > it that when they succeeded in replicating the COM API, it should also > be doable to make a Linux frontend to that... (??) This is a pretty good idea. It would definitely take some doing, but one could imagine cutting and pasting lots of code from rpcrt4 and the wineserver to achieve it via unix domain sockets... this would definitely be a big boon to projects like mplayer and mono which want some way to kick wine around from a normal linux ABI environment (seems like a pretty common problem actually, I see it mentioned on this list quite frequently). Although I've contemplated inventing something like this in the past, ATM I am /not/ volunteering. If you give me a few months (or pay me ;)) I will probably take a crack at it, but right now I am hopelessly busy :(. -- gmt "We lay it down as a fundamental, that laws, to be just, must give a reciprocation of right; that, without this, they are mere arbitrary rules of conduct, founded in force, and not in conscience." --Thomas Jefferson
Re: virus on cvs mailing list
On Saturday 24 January 2004 02:06 pm, Ivan Leo Murray-Smith wrote: > OK, I'm not sure it's a virus (Don't have a win box at the moment), but > this emails should go in any case. > http://www.winehq.com/hypermail/wine-cvs/2004/01/0319.html > > Ivan. It's almost surely Bagle, recently mentioned on the Drudge Report. http://www.ananova.com/news/story/sm_857408.html -gmt
Re: RFC on our new initiative
On Thursday 22 January 2004 12:05 am, Boaz Harrosh wrote: > Jeremy White wrote: > >>Did any one contact Xaim to see if they can send any MONO people to > >>wineconf? > >>Is there any vision on how these 2 integrate? > >> I haven't even touched MONO yet (& .NET for that mater), but from the > >>look of it they better use wine for some areas of .NET. Like .Forms. > >>And certainly Wine Loader should have an hook ready for sending .NET > >>code the MONO way. > > > >I haven't asked them directly, but I know that Alexandre chatted > >directly with some of the Mono guys (who, afaik, promptly disregarded > >his advice and hacked Wine to their own ends ). > > > >Cheers, > > > >Jer > > They can re patch to their harts content every wine release. Stupid but > doable. But are they releasing their wine source code ? They have to. So > that means we have yet another fork of wine on the net? > Nu well! Life! > > Free Life > Boaz Mono is LGPL/X11 (except the compiler) so we could beat them at their own game by forking /their/ code, turning it into a winelib app, and implementing Windows.Forms properly ;) If you're serious, here's where to start implementing your .NET hooks in wine: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/grfunUnmanagedAPIReference.asp I think CorBindToRuntimeEx is the standard entry-point API to the CLR. -- gmt "In accordance with the GPL, the source for pogo is available upon request, for a nominal fee to cover media and shipping costs.* "* = The source code will be provided to you as a series of large, neon-lit marquee letters shipped individually in wooden packing crates. Currently, the world's supply of neon gas limits our ability to ship large quantities of source code. The current expected wait time is 32 years, plus or minus 6 months, depending upon the condition of labor relations in countries with substantial noble gas exports. "For more information, please inject crystal meth directly into your eyeballs, and light yourself on fire while listening to the following song: "xmms http://www.ibiblio.org/propaganda/pogo/easteregg.mp3"; -- the pogo README, presumably written by Bowie J. Poag
Re: RFC on our new initiative
On Tuesday 20 January 2004 08:05 am, Jeremy Newman wrote: > From the desk of Jeremy White (who is at LinuxWorld ATM). > > Hey folks, > > We've just launched a major new initiative, the > CodeWeavers CrossOver Compatibility Center. > > You can check it out at > http://www.codeweavers.com/site/compatibility/ > but I think it's fair to describe it as the appdb > on steroids. Looks great to me; although there are not any discussions yet (or are there?) in the "forums" area to demonstrate the quality of the forum interface, if it's something along the lines of phpBB, then it's perfect. In my mind, the appdb is great, but better, threaded, discussion areas were needed for people to really get serious about it. As for wine vs Crossover -- I presume that "plain old wine" users are welcome to participate? If so, then there really isn't a problem. One layout nit: the images on the top don't line up right in Konqy 3.1.5. Looks pretty interesting, I hope it catches on. -- gmt "In accordance with the GPL, the source for pogo is available upon request, for a nominal fee to cover media and shipping costs.* "* = The source code will be provided to you as a series of large, neon-lit marquee letters shipped individually in wooden packing crates. Currently, the world's supply of neon gas limits our ability to ship large quantities of source code. The current expected wait time is 32 years, plus or minus 6 months, depending upon the condition of labor relations in countries with substantial noble gas exports. "For more information, please inject crystal meth directly into your eyeballs, and light yourself on fire while listening to the following song: "xmms http://www.ibiblio.org/propaganda/pogo/easteregg.mp3"; -- the pogo README, presumably written by Bowie J. Poag
Re: Running Wine under MS SFU under Wine ... ?
On Sunday 14 December 2003 10:05 pm, I 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). > > - Dan > > Don't get your hopes up; they are nothing to write home about. Perhaps I spoke too soon, although when I evaluated this long ago, it was probably true. MS has acquired (license to?) Interix and SFU3.5 is based on it; it is now available for download from Microsoft for free, I do not think it's supposed to be a limited-time offer this time. I recently learned that SFU (3.5, at least) is actually a Windows "subsystem," which supposedly should mean that it is not a compatibility layer like cygwin implemented on top of the Windows API. Could be fun, I definitely will give it a whorl presently... -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: Don't let cabinet Extract() crash IE
On Tuesday 06 January 2004 12:10 pm, Mike Hearn wrote:
> On Tue, 2004-01-06 at 17:59, Stefan Leichter wrote:
> > The pointer points to a structure like this:
> >
> > struct ExtractFileList {
> > LPSTR filename;
> > struct ExtractFileList *next;
> > DWORD unknown; // always 1L
> > } ;
>
> Could the unknown be a boolean?
>
> > Did your start modifying/fixing the extract function for this item? If
> > not i will do it.
>
> No, I didn't, please do it :)
>
> thanks -mike
Just a wild guess -- might this unknown boolean be whether or not (1 meaning
"not," I guess) to "run" the extracted file? This is one part of the
"standard" that is rather unclear (for example, what does "run" mean,
exactly, and who does the running?), so one never knows where it might pop
up, and it would make sense that real-world instances were "always" the
same...
Thanks for all these investigations; wish I was able to provide more help
right now, but I have very little time ATM.
-gmt
Re: netapi32: implement NetServerEnum and NetShareEnum
On Saturday 03 January 2004 05:13 pm, Juan Lang wrote: > having RPC be able to talk to a > remote RPC server (running on Windows) ... > That requires named pipes. or tcp support -gmt
Re: Question about replacing a stub...
On Sunday 28 December 2003 10:16 pm, Joshua Walker wrote:
> Hi all.
> On my ever winding quest to fill in the win32 API
> documentation, I have found, I think, an intresting
> issue.
> When the documentation is generated with
> c2man.pl, it checks the .spec file to see if the
> function is a stub or not. The problem is that if it
> is a stub, no documentation will be generated for that
> API. I've decieded to take it upon myself to "fill in
> the blankes" as it were, but I need to know if I'm
> doing this correctly.
>
> For my example I'm going to use the stubbed function
> "AdjustTokenGroups" that is found in avdapi32.dll.
>
> The fist thing I did was update the .spec file so
> c2man.pl will parse the function correctly.
>
> I changed
> @ stub AdjustTokenGroups
>
> to:
> @ stdcall AdjustTokenGroups (long long ptr long ptr
> ptr)
looks right (assuming you have the right calling convention).
> That allows c2man to parse the function. So now all I
> need to do is add that function to security.c. I added
> the following.
> -
> /**
> * AdjustTokenGroups [EMAIL PROTECTED]
> *
> * Adjust the group privileges of an open token
> handle.
> *
> */
>
> BOOL WINAPI
> AdjustTokenGroups(
> HANDLE TokenHandle,
> BOOL ResetToDefault,
> PTOKEN_GROUPS NewState,
> DWORD BufferLength,
> PTOKEN_GROUPS PreviousState,
> PDWORD ReturnLength
> )
>
>
> {
> }
> -
>
>
>
> And whamo-blamo, the documentation is generated...
hmm...
> Now, I'm not too hot on coding, did I just break
> something to get my API to document?
Yes, I'm afraid so. These are excellent questions, so I've annotated each
one.
> Should I be
> adding a fixme?
Yep. The pattern to follow would be to put a "stub" fixme, you will see
examples in the source... but see below for more caveats :)
> Should I be returning something even
> though it's an empty function?
Yes, "proper" C coding requires that any function with a return type other
than "void" return something. When you compile, you will see a new compiler
warning about this. Now, /what/ to return, may take some thinking, or,
depending on the function, even some code to construct dummy structures, etc,
even though there is no real functionality in your stub.
> I didn't compile it to
> see if it worked.
You probably would want to do so, if you take this approach. The best (well,
the quickest) way I know of is to compile a test with a Microsoft compiler,
run it in Windows to make sure it works, and then run it in wine. If you see
your fixme, and there is no crash, then you probably have it right.
> The AdjustTokenGroups.html file that
> was generated says "Not defined in a Wine header. The
> function is either undocumented, or missing from
> Wine." Is it ok to leave that right now? Should I me
> putting something in a header file somewhere?
Often, you need to ("ought to" might be more accurate) define a function in a
wine header somewhere. The trick is to get the Platform SDK from Microsoft
and grep for the function definition in their headers. Now you know which
header it belongs in :) So open that header in your editor, and follow the
existing coding conventions you see there (i.o.w., do not cut-and-paste from
the Microsoft header). However, the definition might already be in the wine
headers (even though the function wasn't in wine), so grep there first.
Now, here comes the bad news: many Windows programs do the following:
o Reach the point where it would be appropriate to call XYZFunction
o Call GetProcAddress for XYZFunction
o branch: if it comes back as NULL, assume it does not exist in this version
of windows. Go down codepath A. Otherwise, codepath B.
This means, sometimes, you could change the behavior of a program, by
implementing the stub. This has been a problem in wine before. It seems
tempting to just create stubs for everything, but this can break working apps
(or fix broken ones -- it's a balancing act).
With a function like AdjustTokenGroups, which I presume is NT-specific, I'm
afraid Alexandre is probably going to reject the patch unless the function
has some kind of meaningful implementation, or a stated reason to be there.
So, you have a couple choices:
1) Convince somebody to change the documentation thingy to work even though
there's a stub (or make this change yourself)
2) Stick to documenting functions wine already has.
Your call, but I suggest route #2: There are many, many, many functions
already implemented in wine, but undocumented. Enough to keep you busy for
years, I would bet. Furthermore, the functions implemented in wine are the
ones that are going to be used most frequently in Windows apps (for obvious
reasons).
Glad to see you are still at this -- good luck!
--
gmt
"It is to be the assent and ratification of the several States,
derived from the supreme authority in each State, the authority
of t
Re: cabinet.Extract
On Sunday 28 December 2003 02:53 pm, Stefan Leichter wrote: > Hello, > > during playing with ie5.5 installer i noticed that the installing of some > cab files failed directly after the extract call. Doing exactly the same > extract call with the same cabinet file and the same content of the first > parameter i got a crash with native cabinet dll. The debugger shows at the > end of the function a "ret 8" assembler comand. > This means to remove 8 words (not bytes) from the stack because the segment > attribute is set to 32 bit (the pop command right before the ret is done > for a 32 bit register and does not have the opcode 0x66 in front to change > the register length). > Therefore the function extract must have 4 parameters instead of two. > > The bad thing is that the installer throws an exception instead of > aborting. > > ChangeLog > -- > the function ectract has four parameters not two Hmm, sounds like you are more of a natural at deducing this stuff than I, so I am happy to defer to your judgement... but I am slightly surprised, as I vaguely recall convincing myself that I had verified that it was right. Since ie5setup was probably my test app, maybe I added arguments until I stopped seeing winedbg, and declared it to be a success :P ... or did someone else do this part? Can't remember. No objection -- if its an improvement in ie5setup, it's surely right. Just thinking "aloud". Thanks for debugging this. Out of curiosity, was it w98 or NT you were (not) emulating? -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: wchar_t on GNU and Win32 - two worlds apart !
What about libs/unicode? I have no idea about that stuff, but isn't a situation like this what those libs are for? -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: Implement RegFlushKey
On Saturday 27 December 2003 09:23 am, Shachar Shemesh wrote:
> Mike Hearn wrote:
> >This implementation is a little inefficient but without using a random
> >access binary db as Windows does (which I am not going to advocate) it's
> >the best we can do.
>
> Ok, I'm going to be flamed for this, but I'm going to go ahead and ask.
>
> This is a request to understand, not a suggestion (yet?).
> Why not use a general purpose DB system? (postgresql, mysql, whatever)
> After all, the registry is just a tree shaped database. We can do that
> using standard SQL, and fall back to our current method if a proper DB
> is not found.
>
> Shachar
The SQL thing is not an inherently bad idea, but why /not/ implement the NT
"hive" format (the random access binary db mentioned above) instead? This
might involve some ugly reverse engineering, but I think this would allow
registries saved out via Reg{Save,Restore}Key to work in fact, doesn't
wine already read this format when using a "Windows" installation? Some
months ago I tried to run an application I wrote for my employer, which used
those API's to import prefabricated chunks of registry stored in this format,
but it failed to read them in.
I guess this is another "hey, somebody other than me should do a crapload of
work" type of post... but I thought I'd mention it to remind everyone that
there is a Windows-API-compatibility justification suggesting that approach.
--
gmt
"It is to be the assent and ratification of the several States,
derived from the supreme authority in each State, the authority
of the people themselves. The act, therefore, establishing the
Constitution, will not be a NATIONAL, but a FEDERAL act." --James
Madison, Federalist No. 39
Re: Status ToDo's
On Friday 26 December 2003 06:27 am, Tom wrote: > Anyone have any comments, or something they believe I should add > before I send the patch? > > Tom Kernel32 Split 16/32 function, finish moving stuff into ntdll (review FS & device support) Implement non-local named pipes and mailslots over SMB Implement SMB over Netbios [...] RPCRT4 Implment the undocumented "NT Ports" API (aka "LPC") used by native NT Fill out the matrix of per-type /Oi marshalling API's. Some real RPC tests,although there are some tests of some peripheral rpcrt4 API's -- no actual RPC's are tested. Implement /Oicf "stubless" marshalling Implement full stub/proxy support for widl Invent, propose, and evangelize some solution to the Samba-vs-wine TCP/IP RPC port-grabbing problem. Get Wine's DCOM to use wine's RPC as appropriate. Fix the wire protocol If nonlocal named-pipes over SMB is to go into kernel, then it no longer falls upon rpcrt4 dev's to invent a solution to Samba-vs-wine... I guess this burden falls on the shoulders of Juan Lang now? What say you, Juan? Also, as a sort of subset of the wire-protocol task, you may want to add "Implement the OXID resolver and other ORPC peccadilloes". Finally, Implement is misspelled above. (The misspelling is probably cut-and-pasted from me :() -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: Fix for debugger breakage
On Monday 15 December 2003 04:25 pm, Mike Hearn wrote: > On Mon, 2003-12-15 at 21:58, Gregory M. Turner wrote: > > hmm, one minor difference... I use WINELOADER=/opt/wine/bin/wine (we > > happen to have the same wine prefix)... perhaps the word "simply" above > > was too strong ;) > > Well, that is exactly what I used for my first try: > > [EMAIL PROTECTED] tests]$ WINELOADER=/opt/wine/bin/wine winedbg ie6setup.exe > > so if it works for you but not me, hmmm, I wonder what else is different > in our environments. Well, lesee, I have /opt/wine/lib in /etc/ld.so.conf and /opt/wine/bin in $PATH. And winedbg only works right if I change cwd away from the wine build tree... that's about all I can think of, unless you want to start talking about glibc, gcc, pthreads, kernel version/.config, etc -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: Fix for debugger breakage
On Monday 15 December 2003 03:45 pm, Mike Hearn wrote:
> On Mon, 2003-12-15 at 21:04, Gregory M. Turner wrote:
> > FYI, I don't know if this makes things any different, but I simply
> > pointed WINELOADER to "wine", not wine-{p,k}thread, and it seems fine...
> > what errors?
>
> [EMAIL PROTECTED] tests]$ WINELOADER=/opt/wine/bin/wine winedbg ie6setup.exe
> fixme:console:SetConsoleCtrlHandler (0x403884e0,1) - no error checking or
> testing yet WineDbg starting on pid a
> Breakpoint 1 at 0x01005ae4
> Invalid address, can't set breakpoint
> You can turn on deferring breakpoints by address by setting
> $CanDeferOnBPByAddr to 1 Loaded debug information from ELF
> '/opt/wine/bin/wine-pthread' ((nil)) Breakpoint 2 at 0x3ffa9ea0
> (_end+0x2fe95ea0)
> Loaded debug information from ELF '/opt/wine/lib/libwine.so.1' (0x10114000)
> *** Invalid address 0xf441000 (pe_load+0xf32d000 in wine-pthread)
> *** Invalid address 0xf6db000 (pe_load+0xf5c7000 in wine-pthread)
> *** Invalid address 0xf6b5000 (pe_load+0xf5a1000 in wine-pthread)
> *** Invalid address 0xf6dc000 (pe_load+0xf5c8000 in wine-pthread)
> *** Invalid address 0x3f554000 (_end+0x2f428580)
>
> ...and so on...
>
> [EMAIL PROTECTED] tests]$ WINELOADER=wine winedbg ie6setup.exe
> wine: could not exec wine-pthread
>
> So, I dunno really...
hmm, one minor difference... I use WINELOADER=/opt/wine/bin/wine (we happen to
have the same wine prefix)... perhaps the word "simply" above was too
strong ;)
--
gmt
"It is to be the assent and ratification of the several States,
derived from the supreme authority in each State, the authority
of the people themselves. The act, therefore, establishing the
Constitution, will not be a NATIONAL, but a FEDERAL act." --James
Madison, Federalist No. 39
Re: Fix for debugger breakage
On Monday 15 December 2003 08:51 am, Mike Hearn wrote:
> Hi,
>
> What is the status of this problem? I tried setting WINELOADER to point to
> wine-pthread, and while that allowed winedbg to load symbols it spewed
> loads of errors while doing so. Is there a proper fix for this?
>
> BTW I think the recent URL Cache patch broke the IE setup program, I get a
> crash there calling InterlockedExchange with a null pointer dereference.
>
> thanks -mike
FYI, I don't know if this makes things any different, but I simply pointed
WINELOADER to "wine", not wine-{p,k}thread, and it seems fine... what errors?
Good luck,
--
gmt
"It is to be the assent and ratification of the several States,
derived from the supreme authority in each State, the authority
of the people themselves. The act, therefore, establishing the
Constitution, will not be a NATIONAL, but a FEDERAL act." --James
Madison, Federalist No. 39
Re: Running Wine under MS SFU under Wine ... ?
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). > - Dan Don't get your hopes up; they are nothing to write home about. -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: Wine in gdb brokenness
On Saturday 13 December 2003 10:39 am, Mike Hearn wrote: > Hi, > > Running wine in gdb appears to be broken with latest CVS: > > (gdb) file wine > Reading symbols from wine...done. > Using host libthread_db library "/lib/tls/libthread_db.so.1". > (gdb) run > Starting program: /opt/wine/bin/wine wine > [Thread debugging using libthread_db enabled] > [New Thread -108442 (LWP 30661)] > [New Thread -1084458064 (LWP 30662)] > Cannot find user-level thread for LWP 30661: generic error > > This is on fedora core 1. It looks like it might be the NPTL runtime > detection stuff, does anybody have any ideas? heh, same here :P -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: Internally maintained end-to-end API documentation
On Saturday 13 December 2003 04:40 am, Joshua Walker wrote: > 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. lol. That's about right. However, if you subscribe to MSDN Library, you can get snapshots of the Library on DVD. They are pretty complete, do not create logs at Microsoft every time you research any small thing, and they do not disappear at the whim or accident of Microsoft. Better still: I find that most info I need to develop wine is part of the Platform SDK; this is a freely downloadable subset of the Library from Microsoft (if you consider a click-through EULA "free"). > I think it's about time to take the various Windows > APIs and place them onto a fishbowl for safe keeping. Wine has its own internal (in-source) documentation which is robotically put somewhere on the web. Some if it is good, some of it sucks... you are welcome and encouraged to contribute. >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. that's a good thing. > 2) Many ideas have been announced here with no real > clear goal or steps of execution. They soon die of > atrophy shortly after. so is that :) Wine requires lots of brainstorming and tossing of ideas back and forth. Also, unpaid volunteers are probably less likely to follow through sometimes. For example, I'm guilty of this across several axes. Also, some projects, like the Internet Exploder replacement for example, are simply put on the backburner for technical or project-scope reasons, although they really are not discarded, and will eventually arrive. > 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? Good idea. > 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? For a start, just follow the conventions you see in the wine sources already. They will be picked up by the robot and put on-line AFAIK. > 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. I think this is overkill. In-source doc's are good enough for now, and if we eventually need something more sophisticated, one of the perl hackers around here will have a conversion plan. > 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. Again, there are existing conventions you can follow. They are quite simple and easy to implement, and there are abundant examples in the source. Good luck! I welcome your enthusiasm and look forward to your patches. One word of advice: I am not a big fan of legal nonsense, but please bear in mind that the Microsoft documentation is copyrighted. A good way to avoid infringement is to document the functionality you see implemented in the wine sources, using MSDN only for proofreading purposes, or not at all. -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: debugging problems (was Re: Suggestion - don't require sane and artsc)
On Wednesday 10 December 2003 04:30 pm, Alexandre Julliard wrote:
> "Gregory M. Turner" <[EMAIL PROTECTED]> writes:
> > actually, AFAICS it's just looking at "wine"... where is a good place to
> > verify this (with a trace)? Perhaps this is the whole problem? I am not
> > mentally up-to-date on the latest with wine-{k,p}thread, the wrapper,
> > etc... maybe it's time to read up.
>
> Does it make a difference if you set WINELOADER to point to your wine
> binary?
*embarrasment emoticon* yep. like a charm
--
gmt
"It is to be the assent and ratification of the several States,
derived from the supreme authority in each State, the authority
of the people themselves. The act, therefore, establishing the
Constitution, will not be a NATIONAL, but a FEDERAL act." --James
Madison, Federalist No. 39
Re: debugging problems (was Re: Suggestion - don't require sane and artsc)
On Wednesday 10 December 2003 01:52 pm, Eric Pouech wrote:
> > Indeed. Looking at the loop in DEBUG_ReadExecutableDbgInfo, the values
> > of dyn.d_tag it iterates through look nothing like the output of "readelf
> > -d wine" (they should, right?)
>
> yup
> The numbers it shows me (after adding a trace)
>
> > don't even map to the DT_ constants I see in elf.h at all... (again, I
> > presume that they should? fwiw, readelf -d does show a DEBUG tag) I
> > guess, this probably means there is a problem in DEBUG_ProcessElfFile
> > finding the right address for the .dynamic section?
>
> well, I suspect we could also lookup in the wrong file. Could you check
> that the name of the main ELF module we load in the debugger is actually
> the (full path) to the wine-(p|k)thread executable.
> A+
actually, AFAICS it's just looking at "wine"... where is a good place to
verify this (with a trace)? Perhaps this is the whole problem? I am not
mentally up-to-date on the latest with wine-{k,p}thread, the wrapper, etc...
maybe it's time to read up.
Here is one (partially homebrew) trace which may or may not already answer
this question for you (my wine prefix is '/opt/wine'):
trace:debug:DEBUG_ProcessElfObject dil = DIL_ERROR
trace:debug:DEBUG_ProcessElfObject dil = DIL_ERROR
trace:debug:DEBUG_ProcessElfObject dil = DIL_ERROR
trace:debug:DEBUG_ProcessElfObject dil = DIL_ERROR
trace:debug:DEBUG_ProcessElfFile Processing elf file 'wine'
trace:debug:DEBUG_ProcessElfObject dil = DIL_ERROR
trace:debug:DEBUG_ProcessElfObject dil = DIL_ERROR
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/bin/wrappers/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/local/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/opt/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file
'/usr/i686-pc-linux-gnu/gcc-bin/3.3/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/opt/ati/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/X11R6/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file
'/opt/sun-j2sdk-1.4.1/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file
'/opt/sun-j2sdk-1.4.1/jre/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/qt/3/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/kde/3.1/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/usr/qt/2/bin/wine'
trace:debug:DEBUG_ProcessElfFile Processing elf file '/opt/wine/bin/wine'
trace:debug:DEBUG_ProcessElfObject dil = DIL_LOADED
trace:debug:DEBUG_ProcessElfObject dil = DIL_LOADED
trace:debug:DEBUG_ProcessElfObject dil = DIL_LOADED
trace:debug:DEBUG_ProcessElfObject dil = DIL_LOADED
trace:debug:DEBUG_ReportDIL Loaded debug information from ELF 'wine' ((nil))
trace:debug:DEBUG_ProcessElfObject dil = DIL_LOADED
trace:debug:DEBUG_ReadExecutableDbgInfo JJJ
Note that I have managed to get it to load symbols for wine itself --
apparently the problem is that I was running wine with my cwd in root of the
build tree, although I don't understand that completely, as my $PATH does not
include "."
--
gmt
"It is to be the assent and ratification of the several States,
derived from the supreme authority in each State, the authority
of the people themselves. The act, therefore, establishing the
Constitution, will not be a NATIONAL, but a FEDERAL act." --James
Madison, Federalist No. 39
Re: debugging problems (was Re: Suggestion - don't require sane and artsc)
On Saturday 06 December 2003 12:15 am, Eric Pouech wrote:
> not really, in fact not reading .so file is linked to being able (or
> not) to read the .dynamic section of the ELF header
Indeed. Looking at the loop in DEBUG_ReadExecutableDbgInfo, the values of
dyn.d_tag it iterates through look nothing like the output of "readelf -d
wine" (they should, right?) The numbers it shows me (after adding a trace)
don't even map to the DT_ constants I see in elf.h at all... (again, I
presume that they should? fwiw, readelf -d does show a DEBUG tag) I guess,
this probably means there is a problem in DEBUG_ProcessElfFile finding the
right address for the .dynamic section?
> Basically, the way it goes is:
> 1/ load the main exec (from its pathname)
> 2/ get the loaded ELF information from file image
> 3/ get address of a specific function (in ELF loading) which gets
> called each time a .so shared lib is loaded/unloaded (in debuggee
> address space)
> 4/ set a breakpoint on this function (in debuggee address space)
> 5/ set a winedbg specific handler for this breakpoint which will load
> debug info for any new share lib when the bp is hit (we don't handle yet
> shared lib unloading).
> It seems, from what you describe, that step 1/ or 2/ is failing. Could
> you send me your wine-{kp}thread file so that I get a small glance at this.
I think I see what you are talking about -- this is supposed to be set up in
DEBUG_ReadExecutableDbgInfo, right? But where it says "if (dyn.d_tag ==
DT_NULL) goto leave;" my wine does indeed goto leave. My guess is, it's just
fishing through some pseudo-arbitrary ram until it finds a zero
--
gmt
"It is to be the assent and ratification of the several States,
derived from the supreme authority in each State, the authority
of the people themselves. The act, therefore, establishing the
Constitution, will not be a NATIONAL, but a FEDERAL act." --James
Madison, Federalist No. 39
Re: rpcrt4 and rpcss with WINE and ReactOS
On Monday 08 December 2003 06:21 pm, Steven Edwards wrote: > http://cvs.reactos.com/cvsweb.cgi/reactos/ntoskrnl/lpc/ Neat. Does it work well enough in ROS to support NT's native rpcrt4? -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: rpcrt4 and rpcss with WINE and ReactOS
On Monday 08 December 2003 04:44 pm, Casper Hornstrup wrote: > > -Oprindelig meddelelse- > > Fra: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] På vegne af Steven Edwards > > Sendt: 8. december 2003 23:05 > > Til: [EMAIL PROTECTED] > > Emne: rpcrt4 and rpcss with WINE and ReactOS > > > > > > 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 > > ReactOS can use the relatively fast LPC facility for > cross-process communication in rpcrt4. I'm not sure if WINE implements > this, but if both WINE and ReactOS implements it in the same > way, then I see no reason not to share implementations of this > component. Wine doesn't have LPC per se. If ReactOS does, I'd love to see their implementation and talk to you all about stealing it :) Rpcss (in wine) is really a nasty kludge at this time. It only performs a single function: mapping of endpoints. Eventually, this is where the Running Object Table, the OXID Resolver, and maybe some other things should go. Furthermore, the endpoint mapping is done in completely the wrong way: it uses an arbitrary protocol over named pipes. It is supposed to be using RPC according to a standard interface (maybe there are two standards, though, the MS ORPC one and the ONC RPC one, which are supposed to coexist). That's not particularly important, however, until the wire protocol is fixed. At the RPC API level, wine appears to support lpc -- but in fact it's using named pipes. The actual LPC API's (NT "Ports") are just do-nothing stubs. Implementing them might be easy; implementing them /well/ would probably require shared memory and be kinda scary. I have designs to do this myself (starting with the poor, easy implementation), but lately I'm not finding the time I want to dedicate to wine development. Uhh... so in answer to your question, rpcrt4 and rpcss are designed to work together, and shouldn't have too many ugly dependencies (except that rpcrt4 has some ole32 deps for its ndr implementation). For the most part, they only use high-level Windows-y stuff found in kernel32; there may be a few unixisms/wineisms, of course, but compared to other dlls these should be trivial. My advice: just run the code and see what happens. So long as ROS has working named-pipes, and a few other kernel essentials like critical sections, string atoms, etc, it ought to "just work", deficiencies and all. Just test with "/Oi" midl-generated code, and stick to the supported transports (lpc, ironically, or named pipes), or you will get no love. AFAIK, the only snag you may encounter is if your ole diverges from that of wine.. if that happens, just break the ndr types which require ole32 until you get your ole32 up to speed. Furthermore, you only need rpcss for dynamic endpoints!!! Fixed endpoints will work fine without rpcss. In real-world situations, due to the deficiencies of wine's RPC, there is almost never any reason to invoke rpcss, and it rarely runs. Sorry to fulfill the prophecy about "YALD (Yet Another Long Discussion) that wont go anywhere right away but..", -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: ATI driver crashes the system with wine
On Sunday 07 December 2003 02:58 pm, Lionel Ulmer wrote: > > I tried that but it still crashes. > > I think there is only the one in ~/.wine/config right? > > Anyway, even if Wine may be faulty, an X crash is always an X bug or an X > driver bug :-) > > Best way to fix this is to do a +relay trace with Synchronous set to On in > your config file and try to see where Wine stops (ie in which DLL > initialisation). > > Lionel FYI, I use nptl, 2.6, and ati-drivers-3.2.8 (/not/ in wine-compatibility mode), and it works fine AFAIK. -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
debugging problems (was Re: Suggestion - don't require sane and artsc)
On Friday 05 December 2003 04:15 pm, Chris Morgan wrote: > I can see about making this change as I did it once before > for the jack audio driver. > > Can someone fix the debug symbols issue? I've got a patch > for the jack driver that I'm having trouble debugging > without it :-P I think this may be going slow since the "right people" are not experiencing this problem, and are therefore unable to try to fix it. I'm still looking into it, since I have at least a minimal amount of experience toying with winedbg and my wine exhibits the problem, but of course I am a bit out of my depth with some of this stuff, and the fact that gdb doesn't work for me isn't making it any easier. Here's the latest I know, after spending very little time, so far, looking into it: First, the routine which Eric suggested I start my research with (DEBUG_ProcessElfObject), is not called, except for the wine executable itself. That is, DEBUG_ProcessElfObject is never called for any .dll.so files whatsoever. Secondly, in the case of the wine executable (by this I mean the "wine" file) DEBUG_ProcessElfObject fails to find symbols, as DEBUG_ProcessElfFile returns DIL_NOINFO (I'm not sure why, yet). Is it possible that the latter problem causes the former? That is, if "wine" is not found to contain debug symbols, will winedbg stop trying to load symbols for native wine libraries? Barring that, I ought to try to determine why it never runs... but I'm a bit confused as to how winedbg ever ends up at DEBUG_ProcessElfObject in the case of a library. Could someone with a working winedbg show me a stack trace at the point where winedbg calls DEBUG_ProcessElfObject for a .dll.so library? This might help me to figure out where my wine diverges from the expected execution path. Wish me luck. Depending on the complexity of the root cause I may just not have what it takes, but I'm happy to patiently plod forward until I hit a brick wall, as this situation is making it difficult for me to work, as well. -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: debugger problems
On Wednesday 03 December 2003 12:57 pm, Eric Pouech wrote: > > poking around I find that the for loop in DEBUG_RegisterStabsDebugInfo > > (in programs/winedbg/msc.c) never finds the .stab or .stabstr sections... > > not sure if they are really there or not. For example, for ntdll, it > > finds only .data and .text Not sure what's really wrong here; for > > now, it's my bedtime :P > > do you mean the one in msc.c or the one in stabs.c ? > the one in msc.c is only used to support PE modules when compiled under > mingw. The one you're interested in is in stabs.c (it's for ELF modules). > A+ aha! Well, I'm afraid I definitely was messing with msc.c (what you say makes perfect sense, I had wondered why stabs stuff was there (I guess for mingw as you mention)). Armed with this info I'll take another look. For presumably transient reasons which I don't quite fathom, my gdb won't debug wine right now either... so I'm simply using creative TRACE's for now... yuck. I had followed ctags from DEBUG_LoadModule32 in module.c into msc.c... I guess, instead, I should be looking at the path: winedbg.c:DEBUG_HandleDebugEvent -> stabs.c:DEBUG_ReadExecutableDbgInfo ? Thanks for your help. -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: debugger problems
On Tuesday 02 December 2003 01:02 am, Gregory M. Turner wrote: > On Monday 01 December 2003 12:31 am, Rein Klazes wrote: > > On Sun, 30 Nov 2003 22:01:22 +0100, you wrote: > > > Mike Hearn wrote: > > > > On Sun, 2003-11-30 at 19:51, Rein Klazes wrote: > > > >>Still the same here. It can be a bug in Debian Sid of course, and the > > > >>with the flow of updates stopped ... > > > > > > > > FWIW I see the same problem here now on RH9 > > > > > > I'm just trying to figure out what could be different on your side from > > > mine. > > > Are you all using nptl support ? > > > > I am not. glibc 2.3.2 on not-patched kernel 2.4.22. > > > > Rein. > > poking around I find that the for loop in DEBUG_RegisterStabsDebugInfo (in > programs/winedbg/msc.c) never finds the .stab or .stabstr sections... not > sure if they are really there or not. For example, for ntdll, it finds > only .data and .text Not sure what's really wrong here; for now, it's > my bedtime :P One more tidbit: readelf clearly shows the .stab and .stabstr sections are there... any thoughts on this? -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: debugger problems
On Monday 01 December 2003 12:31 am, Rein Klazes wrote: > On Sun, 30 Nov 2003 22:01:22 +0100, you wrote: > > Mike Hearn wrote: > > > On Sun, 2003-11-30 at 19:51, Rein Klazes wrote: > > >>Still the same here. It can be a bug in Debian Sid of course, and the > > >>with the flow of updates stopped ... > > > > > > FWIW I see the same problem here now on RH9 > > > > I'm just trying to figure out what could be different on your side from > > mine. > > Are you all using nptl support ? > > I am not. glibc 2.3.2 on not-patched kernel 2.4.22. > > Rein. poking around I find that the for loop in DEBUG_RegisterStabsDebugInfo (in programs/winedbg/msc.c) never finds the .stab or .stabstr sections... not sure if they are really there or not. For example, for ntdll, it finds only .data and .text Not sure what's really wrong here; for now, it's my bedtime :P -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: debugger problems
On Friday 28 November 2003 02:54 pm, Eric Pouech wrote: > Chris Morgan wrote: > > Anyone taking a look at this? Eric? > > is this only happening with gcc 3.3.2 ? (winedbg works as expected > here). Did Alexandre latest fixes to debug.l help ? > A+ Same here with gcc-3.3.1, and in my VM with gcc-3.2.3. I've been reading disassembly and adding lots of TRACEs :( My wine is a few days out-of-date; will report back once I update to cvs. -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: rpcrt4: fix NULL pointer access
On Thursday 20 November 2003 02:26 pm, Dimitrie O. Paun wrote:
> Ran into this while browsing the code, it seems to
> be a NULL pointer reference waiting to happen.
> Am I missing something?
>
> ChangeLog
> Bail when we're out of memory.
>
> Index: dlls/rpcrt4/rpc_binding.c
> ===
> RCS file: /var/cvs/wine/dlls/rpcrt4/rpc_binding.c,v
> retrieving revision 1.15
> diff -u -r1.15 rpc_binding.c
> --- dlls/rpcrt4/rpc_binding.c 7 Oct 2003 22:54:17 - 1.15
> +++ dlls/rpcrt4/rpc_binding.c 20 Nov 2003 06:33:52 -
> @@ -516,7 +516,11 @@
> {
>DWORD len = strlen(dst), slen = strlen(src);
>LPSTR ndst = HeapReAlloc(GetProcessHeap(), 0, dst,
> (len+slen+2)*sizeof(CHAR)); - if (!ndst) HeapFree(GetProcessHeap(), 0,
> dst);
> + if (!ndst)
> + {
> +HeapFree(GetProcessHeap(), 0, dst);
> +return NULL;
> + }
>ndst[len] = ',';
>memcpy(ndst+len+1, src, slen*sizeof(CHAR));
>ndst[len+slen+1] = 0;
> @@ -527,7 +531,11 @@
> {
>DWORD len = strlenW(dst), slen = strlenW(src);
>LPWSTR ndst = HeapReAlloc(GetProcessHeap(), 0, dst,
> (len+slen+2)*sizeof(WCHAR)); - if (!ndst) HeapFree(GetProcessHeap(), 0,
> dst);
> + if (!ndst)
> + {
> +HeapFree(GetProcessHeap(), 0, dst);
> +return NULL;
> + }
>ndst[len] = ',';
>memcpy(ndst+len+1, src, slen*sizeof(WCHAR));
>ndst[len+slen+1] = 0;
looks like a real bug to me... but the consumers of those functions
probably assume success, so maybe the right solution is really to raise
an exception. There are lots of places in rpcrt4 where exceptions ought
to raise on error conditions but don't, mainly due to developer laziness.
I guess it's hard to justify fixing error paths when success doesn't work
either ;)
So, at some point there needs to be an error-handling audit of rpcrt4;
until then, your patch is better than nothing, and probably should go in.
--
gmt
"It is to be the assent and ratification of the several States,
derived from the supreme authority in each State, the authority
of the people themselves. The act, therefore, establishing the
Constitution, will not be a NATIONAL, but a FEDERAL act." --James
Madison, Federalist No. 39
Re: wrc doesn't seem to accept -r option,even though it is automatically generated by make file
On Tuesday 11 November 2003 01:22 pm, Parzival Herzog wrote: > On November 11, 2003 11:39, Ivan Leo Murray-Smith wrote: > > I don't know how to solve your problem, but it would be a good idea if > > you just installed > > the latest CVS version. > > > > I' just too inexperienced and too isolated to use CVS right now: an 800 > page manual, configuring, using SSH, it threatens to take up the rest of > the year just to get started, and I'm off to another mailing list when the > inevitable "why doesn't it work" problems occur. > > I've also discovered that with non-rpm source distributions, there is a > "make install", but so far, nothing I have seen has a "make uninstall" that > does anything, and that concerns me, when I see 70 MB of stuff flying off > to 400 different places. (Maybe wine is not like that, but I just built the > "insight" gdb, and I thought it would use my existing gdb, but it built and > installed a new one, installed its own tk, (gee, what about the tk that is > a part of Python) and has no way to uninstall. > > I'm at a place where I'm wrestling with "how does the PATH get set", > "how do you build a static library", "how do you build a shared library", > "how does the loader find a shared library". Wrestling with ten > thousand-line makefiles is sheer insanity from my perspective. I just hope > that I can get my little program to compile and run with winelib, because > if it that works, I won't have to use Windows in my day-to-day work. > > There, there, no need to , it's going to be OK! Try following the instructions on this page: http://www.winehq.com/site/cvs Just do what it says, step-by-step. You don't need ssh for this, just cvs. That page even tells you how to keep your wine up-to-date via cvs once you get it. And, wine just happens to support "make uninstall". Sounds to me like you are letting yourself get overwhelmed by the scope of what you do not know. For example, very few people here (although there are probably one or two) would actually know the full answer to "how does the loader find a shared library". You don't need to know that for your experiment. Instead, just read the "ld.so" manpage and the pages it references. Think of it like your television: you don't care how the "ion gun" works... just how to change the channel, volume, etc. (As for the make uninstall thing, you hit the nail on the head: where did all those binaries go? Many unixy programs support a "--prefix=[path]" argument at the "configure" stage of the build; so all your binaries go under that directory; for example, to install my wine, I use --prefix=/opt/wine, which puts wine in /opt/wine/bin, /opt/wine/lib, etc. But it certainly can get tricky keeping track of this if you are building tons of stuff from source and putting it all in "/usr" or "/usr/local", as is common practice. The best solution I know of, if you are building lots of stuff from source, is to use gentoo, which really does rigorously keep track of what 'make install' did. But I should warn you that gentoo is not always so easy to get up and running as other distributions.) Good luck! You are now in the nasty horizontal part of the learning curve for unix programming and wine. It does get better, just be patient and persistent, and you will prevail. -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: copy protection - was: Re: Is it time for playing games on WINE?
On Thursday 06 November 2003 03:31 pm, Geoff Thorpe wrote: > War crime tribunals, environmental protection treaties, privacy > legislation, ... the ability to let chilling effects meet little or no > significant organised obstacle has become the trademark of a certain > breed of "freedom-loving" people. Bruce Schneier once said that the "war > on drugs" was the root password to the US constitution. I think they > changed the password recently to use "terrorism" instead of "drugs", but > it's still much the same dance - ridiculous legislation is ushered in in > the name of "protecting rights" when in fact it is invariably used to > achieve quite the opposite. The issue is not whether you exercise a > personal disobedience to it, because Wine itself certainly can't, but > whether something can be done to aid efforts to overturn these laws. In > the mean time, (and as long as people in the US are involved in Wine,) > we're stuck with them. Here here! It is really unfortunate that wine is another victim of the DMCA, but I'd rather Alexandre played it safe, lest we be made an "example." If some rebellious individuals want to contribute these sorts of patches, as sort of an act of civil disobedience, I suggest they post them to /freenet/. Once the DMCA is eliminated (one can hope...), then A can reconsider. -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39
Re: Misc wine debugging questions
On Thursday 30 October 2003 04:16 pm, Mike Hearn wrote: > ncalrpc? The preferred transport for local-to-self RPC/DCOM communications. In NT it's implemented on top of "NT Ports" (see Undocumented NT), the advantge being that this is fast. This RPC transport (but not the NT ports themselves) is simulated using named pipes in wine. For example, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/midl/midl/ncalrpc.asp The whole family is nicely summarized here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/string_binding.asp Sheesh, so much to do... it's enough to make me want to finish my cabinet work rather than confront it ;) BTW, note that transports like http, tcp, etc, could allow wine to do DCOM without resolving the "priveleged ports" issue (at least for fixed endpoints) of course, our wire protocol is way off and will need fixing before that's possible... luckily I have archived the spec (enclosed for your amusement), which AFAIK fell off the 'net. Older revisions are available by searching (http://www.brassroots.org/google.html";>do not Google!) the 'net; the enclosed version was linked to by Don Box's delicious blog back when it existed at http://www.globecom.net/ietf/draft/draft-brown-dcom-v1-spec-03.html. -- gmt "To take from one, because it is thought his own industry and that of his fathers has acquired too much, in order to spare to others, who, or whose fathers, have not exercised equal industry and skill, is to violate arbitrarily the first principle of association, the guarantee to everyone the free exercise of his industry and the fruits acquired by it." --Thomas Jefferson draft-brown-dcom-v1-spec-03.html.bz2 Description: BZip2 compressed data
Re: Misc wine debugging questions
On Thursday 30 October 2003 02:35 pm, Mike Hearn wrote: > Thirdly, Greg recently mentioned "stubless proxies". Does anybody know > where I can read about these? > > thanks -mike Unfortunately, there isn't a ton of documentation -- or, more accurately, the documentation that you may find is scattered throughout MSDN and the internet, instead of being in an "obvious" place. The MSDN documentation for NdrClientCall2, for example, is almost worthless from the wine implementer's perspective, just stating something like "This is the entry-point for stubless proxies." From the perspective of most users, stubless proxies are a behind-the-scenes implementation detail that isn't worth learning too much about. The end-programmer's perspective is as follows: pass /Oicf to MIDL, and MIDL will magically generate stubless proxies. I forget if /Oic is considered "stubless" as well, I think it may be. The resulting client proxy code generated by MIDL will contain "NdrClientCall2" or "NdrClientCall" instead of the usual multi-step proxy code (there is no in-proxy marshalling, exception-handling, etc -- just the single call). In wine, NdrClientCall2 (the more common entry-point) is totally unimplemented -- it simply emits a FIXME and returns indicating success. The server side is analogous. You will see some code by Ove floating around to generate the manager entry-point thunks in asm, but I don't think they are used yet (?). Unfortunately, stubless proxies have been the recommended (by Microsoft) mode of generating code from MIDL for many years. Increasingly, I see calls to NdrClientCall2. The only solution (aside from coding wine) is to use native rpcrt4/ole32 -- but this, in turn, means you must use Windows 98 dll's or else you will bump up against the missing "Ports" API if ncalrpc is used (it usually is -- this is why I keep musing that I want to take a crack at implementing this). I think, the way to code those is to use the structures provided by MIDL (and eventually widl) to determine the necessary steps. In particular, I think this is where the format strings come in handy -- presumably, NdrClientCall2 should parse the format strings and determine what to marshall/unmarshall using those. My theory is that the steps taken in NdrClientCall2 would look very much like those MIDL would spit out in /Oi mode. Stated succinctly, stubless proxies are the RPC/DCOM holy grail for wine. Unfortunately, it doesn't make much sense to start working /Oic[f] until /Oi mode is working a lot better. Things like the OXID Resolver, IObjectExporter, RpcObjectSetType, etc, really ought to be in place before we start complicating matters by implementing subless proxies... of course, if someone wants to prove me wrong, be my guest ;) -- gmt "To take from one, because it is thought his own industry and that of his fathers has acquired too much, in order to spare to others, who, or whose fathers, have not exercised equal industry and skill, is to violate arbitrarily the first principle of association, the guarantee to everyone the free exercise of his industry and the fruits acquired by it." --Thomas Jefferson
Re: Installshield7 notes
On Wednesday 29 October 2003 03:29 pm, Carlos Lozano wrote: > Hello, > > Here goes some notes about how to install installshield 7 programs > with the actual wine releases (sorry, i haven't been able to install > without some natives DLLs). 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. -- gmt "To take from one, because it is thought his own industry and that of his fathers has acquired too much, in order to spare to others, who, or whose fathers, have not exercised equal industry and skill, is to violate arbitrarily the first principle of association, the guarantee to everyone the free exercise of his industry and the fruits acquired by it." --Thomas Jefferson
Re: Proposal to resolve the issue of the broken wine-users gateway
On Thursday 23 October 2003 05:25 pm, Jeremy Newman wrote: > On Thu, 2003-10-23 at 17:15, Dimitrie O. Paun wrote: > > > > For example, when posting an interview people may > > want to ask little questions, etc., stuff that does not > > belong on the mailing lists. > > Exactly, whenever a news post, or new WWN, or Wine version is posted, I > can start a new thread in the forum, and link to that thread from the > news article on the front page. Easy, and effective. Just my $.02, but where winehq really needs forums is in the appdb. The discussions associated with each app can be very useful, especially for those who want wine to "just work" -- but people would probably contribute more if these were a bit easier on the eyes. -- gmt "class 'SfxPoolCancelManager' only defines a private destructor and has no friends" -- gcc, resorting to unnecessary character attacks
Re: Fix comctl32 conformance test
On Tuesday 21 October 2003 08:17 am, Rolf Kalbermatter wrote: > Mmh! I have downloaded the PSDK from the MSDN site, and although it > says Microsoft Platform SDK February 2003 in the Start menu it really > was just downloaded one month ago and my comctl32.lib does not contain > symbols for at least DPA_Create() and DPA_GetPtr() while it does contain > most of the other DPA symbols. > > What am I missing here? Nothing. For some reason, February is the latest PSDK release. -- gmt "class 'SfxPoolCancelManager' only defines a private destructor and has no friends" -- gcc, resorting to unnecessary character attacks
Re: named pipes problem?
On Sunday 19 October 2003 05:20 am, Mike Hearn wrote: > On Sun, 19 Oct 2003 01:00:51 -0500, Sir Gregory M. Turner scribed thus: > > which ostensibly would seem to contradict your prognosis... (although I > > assume you are nevertheless correct -- this is not the root-dir > > configure, so maybe it's misleading me. I will poke at it again to see > > what gentoo is really doing next time I boot up that box). > > Just run libc: > > [EMAIL PROTECTED] downloads]$ /lib/i686/libc-2.3.2.so > GNU C Library stable release version 2.3.2, by Roland McGrath et al. > Copyright (C) 2003 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE. > Compiled by GNU CC version 3.2.2 20030222 (Red Hat Linux 3.2.2-5). > Compiled on a Linux 2.4.20 system on 2003-04-07. > Available extensions: > GNU libio by Per Bothner > crypt add-on version 2.1 by Michael Glad and others > linuxthreads-0.10 by Xavier Leroy > The C stubs add-on version 2.1.2. > BIND-8.2.3-T5B > NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk > Glibc-2.0 compatibility add-on by Cristian Gafton > libthread_db work sponsored by Alpha Processor Inc > Thread-local storage support included. < > Report bugs using the `glibcbug' script to <[EMAIL PROTECTED]>. cool trick. an ironic side-note (I have not tried this on my without-nptl system yet, so the following is not relevant to my problem): on my nptl system (the one that works now), I get: # /lib/libc-2.3.2.so Inconsistency detected by ld.so: rtld.c: 1238: dl_main: Assertion `_rtld_local._dl_rtld_map.l_prev->l_next == _rtld_local._dl_rtld_map.l_next' failed! oy! I wonder, does this indicate a real problem that I should be worried about? ... -- gmt "class 'SfxPoolCancelManager' only defines a private destructor and has no friends" -- gcc, resorting to unnecessary character attacks
Re: named pipes problem?
On Saturday 18 October 2003 12:38 pm, Alexandre Julliard wrote: > Mike Hearn <[EMAIL PROTECTED]> writes: > > Alexandre - this is your area. Any ideas? > > Your glibc is using TLS. Support for that is not ready yet. Depending > on your system you need to either set LD_ASSUME_KERNEL=2.4 or install > another glibc that doesn't use TLS. hmm... "emerge glibc" says: ../../linuxthreads/configure' '--with-gd=no' '--without-cvs' '--disable-profile' '--without-tls' '--without-__thread' '--enable-add-ons=linuxthreads' '--enable-kernel=2.4.1' '--srcdir=../../linuxthreads' which ostensibly would seem to contradict your prognosis... (although I assume you are nevertheless correct -- this is not the root-dir configure, so maybe it's misleading me. I will poke at it again to see what gentoo is really doing next time I boot up that box). As for LD_ASSUME_KERNEL=2.4... the result is very similar to that of "rm -rf /," or at least "rm -rf /lib /usr/lib" -- no love. However, I do not despair. I upgraded my nptl box to nptl 0.60, gcc 3.3.1, and glibc2.3.2-branch-update-20030927, and it's running wine now, at long last. yay! Far more satisfying than running it in that nasty vm anyhow So, whereas before I had without-nptl wine and no with-nptl wine, now I have with-nptl wine and no without-nptl wine. *sigh* when will I learn my lesson and just run Red Hat? ;) -- gmt "class 'SfxPoolCancelManager' only defines a private destructor and has no friends" -- gcc, resorting to unnecessary character attacks
Re: Setupapi Win16/32 (Again) and PSDK porting fixes
On Saturday 18 October 2003 02:15 pm, Gregory M. Turner wrote:
> On Saturday 18 October 2003 01:57 pm, Steven Edwards wrote:
> > With this
> > patch all of the objects for setupapi.dll can be built on
> > MS_VC with the PSDK. There are a few minor issues but nothing
> > to major
>
> doesn't this:
>
> -typedef struct _CABINET_INFOA {
> +typedef struct _CABINET_INFO_A {
>PCSTR CabinetPath;
>PCSTR CabinetFile;
>PCSTR DiskName;
>USHORT SetId;
>USHORT CabinetNumber;
> -} CABINET_INFOA, *PCABINET_INFOA;
> +} CABINET_INFO_A, *PCABINET_INFO_A;
>
> -typedef struct _CABINET_INFOW {
> +typedef struct _CABINET_INFO_W {
>PCWSTR CabinetPath;
>PCWSTR CabinetFile;
>PCWSTR DiskName;
>USHORT SetId;
>USHORT CabinetNumber;
> -} CABINET_INFOW, *PCABINET_INFOW;
> +} CABINET_INFO_W, *PCABINET_INFO_W;
>
> mean we should do this:
>
> -DECL_WINELIB_TYPE_AW(CABINET_INFO);
> -DECL_WINELIB_TYPE_AW(PCABINET_INFO);
> +DECL_WINELIB_TYPE_AW(CABINET_INFO_);
> +DECL_WINELIB_TYPE_AW(PCABINET_INFO_);
>
> ?
Hmm, now that I think about it, for full compatibility with winelib, maybe we
require something like:
typedef stuct ... { ... } CABINET_INFO_W, CABINET_INFOW;
typedef struct ... { ... } CABINET_INFO_A, CABINET_INFOA;
DECL_WINELIB_TYPE_AW(CABINET_INFO_); /* probably unnecessary */
DECL_WINELIB_TYPE_AW(CABINET_INFO);
and likewise for the pointer types. yucky.
The problem, I guess, is that wine is specifically naming the A/W types,
whereas most other proggies would just use the automagical ones... any idea
why wine isn't adding an underscore in DECL_WINELIB_TYPE_AW? Isn't that the
standard MS convention?
--
gmt
"class 'SfxPoolCancelManager' only defines a
private destructor and has no friends"
-- gcc, resorting to unnecessary character attacks
Re: Setupapi Win16/32 (Again) and PSDK porting fixes
On Saturday 18 October 2003 01:57 pm, Steven Edwards wrote:
> With this
> patch all of the objects for setupapi.dll can be built on
> MS_VC with the PSDK. There are a few minor issues but nothing
> to major
doesn't this:
-typedef struct _CABINET_INFOA {
+typedef struct _CABINET_INFO_A {
PCSTR CabinetPath;
PCSTR CabinetFile;
PCSTR DiskName;
USHORT SetId;
USHORT CabinetNumber;
-} CABINET_INFOA, *PCABINET_INFOA;
+} CABINET_INFO_A, *PCABINET_INFO_A;
-typedef struct _CABINET_INFOW {
+typedef struct _CABINET_INFO_W {
PCWSTR CabinetPath;
PCWSTR CabinetFile;
PCWSTR DiskName;
USHORT SetId;
USHORT CabinetNumber;
-} CABINET_INFOW, *PCABINET_INFOW;
+} CABINET_INFO_W, *PCABINET_INFO_W;
mean we should do this:
-DECL_WINELIB_TYPE_AW(CABINET_INFO);
-DECL_WINELIB_TYPE_AW(PCABINET_INFO);
+DECL_WINELIB_TYPE_AW(CABINET_INFO_);
+DECL_WINELIB_TYPE_AW(PCABINET_INFO_);
?
--
gmt
"class 'SfxPoolCancelManager' only defines a
private destructor and has no friends"
-- gcc, resorting to unnecessary character attacks
named pipes problem?
Does everybody's kernel32 named pipes test pass (in wine)? Named pipes are
acting very wierd here, lots of segfaults and other wierdness... the test
seems to freeze attempting to create the alarmThread in test_NamedPipe_2
(test 3 of 4). The wineserver holds up OK, but the client side looks a mess.
This is similar to other behavior I see in other contexts... perhaps, the
pattern is, after I create a named pipe, subsequent calls to CreateThread
never return or cause segfaults and general instability.
Am I the only one? The following is a snippet from "strace -f wine
kernel32_test.exe.so pipe" where wine starts to go south
[pid 28568] write(1, "pipe.c:459:", 11pipe.c:459:) = 11
[pid 28568] write(1, "exercizeServer starting\n", 24exercizeServer starting
) = 24
[pid 28568] write(1, "pipe.c:470:", 11pipe.c:470:) = 11
[pid 28568] write(1, "Client connecting...\n", 21Client connecting...
) = 21
[pid 28568] rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM IO], [RTMIN], 8)
= 0
[pid 28568] writev(4,
[{"\207\0\0\0\222\0\0\0\0\0\0\0\0\0\0\300\0\0\0\0\0\0\0\0"..., 64},
{"\\\0\\\0.\0\\\0P\0i\0P\0e\0\\\0t\0e\0s\0t\0s\0_\0.\0"..., 146}], 2
[pid 28570] <... poll resumed> [{fd=5, events=POLLIN}, {fd=4, events=POLLIN},
{fd=7, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=13,
events=POLLIN}, {fd=15, events=POLLIN}, {fd=16, events=POLLIN,
revents=POLLIN}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=-1},
{fd=24, events=POLLIN}, {fd=23, events=POLLIN}], 16, -1) = 1
[pid 28570] read(16,
"\207\0\0\0\222\0\0\0\0\0\0\0\0\0\0\300\0\0\0\0\0\0\0\0"..., 64) = 64
[pid 28570] read(16,
"\\\0\\\0.\0\\\0P\0i\0P\0e\0\\\0t\0e\0s\0t\0s\0_\0.\0"..., 146) = 146
[pid 28570] write(17,
"\17\0\0\300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
[pid 28570] poll(
[pid 28568] <... writev resumed> ) = 210
[pid 28568] read(5,
"\17\0\0\300\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
[pid 28568] rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0
[pid 28568] write(1, "pipe.c:481:", 11pipe.c:481:) = 11
[pid 28568] write(1, "connect failed, retrying\n", 25connect failed, retrying
) = 25
[pid 28568] gettimeofday({1066424342, 296207}, NULL) = 0
[pid 28568] gettimeofday({1066424342, 296363}, NULL) = 0
[pid 28568] select(0, NULL, NULL, NULL, {0, 199844}
[pid 28575] --- SIGSTOP (Stopped (signal)) @ 0 (0) ---
[pid 28574] --- SIGSTOP (Stopped (signal)) @ 0 (0) ---
[pid 28575] modify_ldt(17, {entry_number:40, base_addr:0x40af3000, limit:4095,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:0,
seg_not_present:0, useable:0}, 16
[pid 28574] modify_ldt(17, {entry_number:39, base_addr:0x408c3000, limit:4095,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:0,
seg_not_present:0, useable:0}, 16
[pid 28575] <... modify_ldt resumed> ) = 0
[pid 28574] <... modify_ldt resumed> ) = 0
[pid 28575] sigaltstack({ss_sp=0x408d1000, ss_flags=0, ss_size=1048576}
[pid 28574] brk(0
[pid 28575] <... sigaltstack resumed> , NULL) = 0
[pid 28574] <... brk resumed> ) = 0x3c009000
[pid 28575] rt_sigaction(SIGINT, {0x40081bf2, [INT USR2],
SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8},
[pid 28574] brk(0x3c00a000
[pid 28575] <... rt_sigaction resumed> NULL, 8) = 0
[pid 28574] <... brk resumed> ) = 0x3c00a000
[pid 28575] rt_sigaction(SIGFPE, {0x40081b76, [INT USR2],
SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8},
[pid 28574] sigaltstack({ss_sp=0x406a1000, ss_flags=0, ss_size=1048576}
[pid 28575] <... rt_sigaction resumed> NULL, 8) = 0
[pid 28574] <... sigaltstack resumed> , NULL) = 0
[pid 28575] rt_sigaction(SIGSEGV, {0x40081aa4, [INT USR2],
SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8},
[pid 28574] rt_sigaction(SIGINT, {0x40081bf2, [INT USR2],
SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8},
[pid 28575] <... rt_sigaction resumed> NULL, 8) = 0
[pid 28574] <... rt_sigaction resumed> NULL, 8) = 0
[pid 28575] rt_sigaction(SIGILL, {0x40081aa4, [INT USR2],
SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8},
[pid 28574] rt_sigaction(SIGFPE, {0x40081b76, [INT USR2],
SA_RESTORER|SA_STACK|SA_RESTART, 0x45a14eb8},
[pid 28575] <... rt_sigaction resumed> NULL, 8) = 0
[pid 28574] <... rt_sigaction resumed> NULL, 8) = 0
from there it just degrades into a soup of SIGSEGV and rt_sigprocmask(), like:
[pid 28575] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 28574] <... rt_sigprocmask resumed> NULL, 8) = 0
[pid 28575] rt_sigprocmask(SIG_UNBLOCK, ~[],
[pid 28574] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 28575] <... rt_sigprocmask resumed> NULL, 8) = 0
[pid 28574] rt_sigprocmask(SIG_UNBLOCK, ~[],
[pid 28575] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 28574] <... rt_sigprocmask resumed> NULL, 8) = 0
[pid 28575] rt_sigprocmask(SIG_UNBLOCK, ~[],
[pid 28574] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 28575] <... rt_sigprocmask resumed> NULL, 8) = 0
[pid 28574] rt_sigprocmask(SIG_UNBLOCK, ~[],
[pid 28575] --- SIGSEGV (Segmentation fault) @ 0 (0) --
Re: Wine Start menu
On Monday 13 October 2003 04:56 pm, Ivan Leo Murray-Smith wrote: > There already is an app that can do the menus, the ros explorer. If it was > compiled as a winelib app, it would solve the menu problem, at least for > who likes desktop mode (And the ros explorer makes wine look like a "real" > emulator) Yes but I think what Robert van Herk wants is something integrated with the window manager. For example his recent post suggests a picture like [wine .exe server] <--> [native linux client] <--> [kde / gnome / twm] The real challenge would presumably be on the linux client side, and obviously the data transport provides some exciting open questions. There is a certain logic to this arrangement imo... who wants some wacky "explorer.exe" if they are simply thumbing through the kde or gnome menus? Not that I disapprove of ros explorer, quite the contrary! ros explorer approximates the behavior of windows explorer, which wine needs for a number of reasons, not the least of which is that it's an integral part of the OS... whereas I think Robert van Herk means to create a bridge or portal allowing native frameworks like gnome to integrate the wine menus into their own... Correct me if I have this all wrong of course :P But if that's the case then it's a different animal from ros explorer, and imo a worthwhile effort. -- gmt "The vice I am talking about is Pride or Self-Conceit: and the virtue opposite to it, in Christian morals, is called Humility. ... According to Christian teachers, the essential vice, the utmost evil, is Pride. Unchastity, greed, drunkenness, and all that, are mere flea-bites in comparison: it was through Pride that the devil became the devil: Pride leads to every other vice: it is the complete anti-God state of mind." --C. S. Lewis
Re: Wine Start menu
On Monday 13 October 2003 01:46 pm, Robert van Herk wrote: > So, my question is: would it be enough to create just a Linux program > that synchronizes with this directory? Can anyone give me an example of > a lnk file that IS actually missing in a Start Menu directory, but is > there in his Program folder in the Windows start menu? Not offhand, but my guess is that, eventually, some fancy feature will be lacking unless wine/winelib is brought into the picture, for example, control-panel, "My Computer" or context-sensitive right-click menu-actions, the fancy docking capability of Windows Media Player 9, etc. One thing I do know for sure -- those don't /have/ to be .lnk files in there... they could be .exe's or .mp3's or whatever, and in Windows, "the right thing" would happen That is not to say that a rational cost/bene analysis will not ultimately favor a pure-linux implementation, depending on where your code is going but my bias would be towards a wine/winelib implementation. Do you forsee this code going into wine or into kde/gnome, or remaining as a separate thing? What relationship would you like between your code and wine's "explorer.exe," once it has one? Codeweavers has done a lot of work with shortcuts & menuitems, to make them work with different distros... so they might know what some of the nitty-gritty details are (Unfortunately, I do not). You may also want to look at LiteStep, ReactOS's explorer, and other windows shell-replacement software for clues. Good luck! -- gmt "The vice I am talking about is Pride or Self-Conceit: and the virtue opposite to it, in Christian morals, is called Humility. ... According to Christian teachers, the essential vice, the utmost evil, is Pride. Unchastity, greed, drunkenness, and all that, are mere flea-bites in comparison: it was through Pride that the devil became the devil: Pride leads to every other vice: it is the complete anti-God state of mind." --C. S. Lewis
Re: DameWare Mini Remote Control vs Wine
On Thursday 09 October 2003 08:54 pm, Tom Hibbert wrote: > Hi guys, > I'm running DameWare Mini Remote Control under Wine here. This is a > pretty cool setup as some of our clients > > have no windows servers (only linux), and the idea is that we can VNC to > a Linux firewall or file server and then use DameWare through Wine to > take control of PCs that we need to remotely administer. > > DameWare has a handy function to actually install the service on a > remote box using RPC. Just by looking at the debug logs, what it does is > create a temporary share on the machine its running from and then > connect to the remote box's admin$ share where it (presumably) executes > the installer. > > Unfortunately wine's RPC implementation doesn't seem to go far enough > for this to work. I've tried loading dlls natively > > (going all the way up to advapi32) and I get ever increasing errors. > Mainly its complaining about missing implementations for (presumably) > rarely used rpc functions. > > Maybe one of you RPC gurus would like to take a look at it. Unfortunately, I don't think that is going to work. RPC alone is not enough, wine cannot do SMB sharing; for example it has no admin$ share, and API's to add and remove shares don't work. It might be possible to fill in the gaps with samba, if file-sharing is all that's needed... But if it's really remote RPC's, wine also lacks support for RPC's across machines, even if they are both wine machines. -- gmt "The vice I am talking about is Pride or Self-Conceit: and the virtue opposite to it, in Christian morals, is called Humility. ... According to Christian teachers, the essential vice, the utmost evil, is Pride. Unchastity, greed, drunkenness, and all that, are mere flea-bites in comparison: it was through Pride that the devil became the devil: Pride leads to every other vice: it is the complete anti-God state of mind." --C. S. Lewis
Re: Oleaut32 7
On Monday 06 October 2003 10:32 am, Jon Griffiths wrote: > Hi, > > Part 7 of oleaut32 updates. > > Cheers, > Jon > > License: X11 > > Changelog: > > Jon Griffiths <[EMAIL PROTECTED]> > +dlls/oleaut32/bool.c dlls/oleaut32/oleaut32.spec >dlls/oleaut32/variant.c > Implement the boolean low-level calls Nice patch-set. I see there were some surprises, but good job nevertheless... extra kudos for doing laborious "boring" stuff and for providing in-source doc! Wish I was so prolific, as I am a no-patch bum lately -- gmt "The vice I am talking about is Pride or Self-Conceit: and the virtue opposite to it, in Christian morals, is called Humility. ... According to Christian teachers, the essential vice, the utmost evil, is Pride. Unchastity, greed, drunkenness, and all that, are mere flea-bites in comparison: it was through Pride that the devil became the devil: Pride leads to every other vice: it is the complete anti-God state of mind." --C. S. Lewis
Re: Compiling MFC
On Friday 03 October 2003 07:04 am, Adam Connell wrote: > I am yet another programmer trying to compile the MFC with winelib. > I believe that I have the project configured correctly. I am currently > working on getting it to compile. I am having trouble with Microsoft's > extensions to C++ specifically: > throw(...) > __try > __except > > Is there any kind of work around for these things? > > MFC v7.0 > g++ v3.2.2 > wine-cvs You have uncovered a very squirmy can of worms, I'm afraid. You have several options, all of them sub-optimal: 1) Use a patched gcc, see http://reactos.wox.org/index.php?page=gccseh 2) Convert the __try blocks into __TRY blocks as supported by wine, see include/wine/exception.h. This will require pretty extensive rewriting of the affected code blocks. 3) Just use dummy macros, along the lines of those in include/rpc.h. This approach will /not/ do any real exception handling, but will get you compiling quickly... no guarantees your compiled code will work, however. 4) See my old attempts to create macros that approximate this using gcc-specific nested functions capabilities, for example, see http://www.winehq.com/hypermail/wine-devel/2003/05/0394.html There are probably a dozen or more such attempts floating around, none of them quite do the right thing of course :( Sorry, this business is messy and so far no really satisfactory solution has been created for a number of reasons. Good luck! -- gmt "Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats." -- H. L. Mencken
Re: XEN: Another virtual machine
On Thursday 02 October 2003 05:42 am, Uwe Bonnes wrote: > Hallo, > > http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/README > sounds very promising for those interested in virtual machines. > > Bye Very impressive. I recommend the PDF at http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf referenced from the readme. Too bad it requires kernel changes, but considering that they seem to have something worked out with Microsoft to play with the XP sources, very cool. I betcha these guys are gonna make some money. -- gmt "Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats." -- H. L. Mencken
Re: uxtheme.dll
On Wednesday 01 October 2003 09:59 am, Steven Edwards wrote: > This is very kickass dude. I concur. I've been fantasizing about looking into this stuff myself, although so far I've always decided I had more pressing matters to look into. But some of this stuff is just so cool... and frankly, wine has a case of the uglies that could use fixing. A little razzle and dazzle can go a long way towards raising the profile of a project. Anyone who's ever subscribed to the goodies-pipeline from StarDock knows -- this stuff has the potential to be very, very pretty. In fact, in my opinion, it made my Windows even prettier than my Linux (although the performance can be pretty awful). And KDE/gnome themes obviously could do something that was never really possible for wine before. So... good luck, I am sure this will be quite difficult, but it's a great idea, in my opinion. -- gmt "Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats." -- H. L. Mencken
Re: Force native MSI and MSHTML
On Thursday 25 September 2003 12:21 pm, Alexandre Julliard wrote: > Mike Hearn <[EMAIL PROTECTED]> writes: > > Annoying isn't it? The config file is not the right place to do this > > anyway, better to have it hardcoded into loader/loadorder.c IMHO, > > otherwise users will always forget to update their config. > > No, that hardcoded list is only for dlls that we know will never work > as native. We don't want to have to change it every week depending on > the progress of some other dll. There are plenty of things that you > may have to add in the registry or config when upgrading Wine, that's > just one of them; we'll need a general mechanism to do that anyway. Perhaps we want to distinguish between "defaults" and "settings," which override the defaults. For example, we could just return default registry values (of the settings with defaults) when they aren't really there. That way new defaults could be hardcoded in source or winedefault.reg, and updating your wine would update any defaults you haven't overridden... such an approach could make things a little screwy from winecfg's perspective however. -- gmt "Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats." -- H. L. Mencken
Re: interactive dsound tests fail && winealsa problem
On Wednesday 24 September 2003 10:55 am, Alexandre Julliard wrote: > [EMAIL PROTECTED] writes: > > So, what I'm wondering now is: 1) Should I bother finishing it? OSS is > > working fine for me again, and if someone else is going to fix the > > existing ALSA driver, and 2) if the answer to question 1 is 'yes', > > then what is the proper protocol for submitting such a substantial code > > change. IMO a separate driver would be less destabilizing (don't run it > > if you don't want to!), but a little confusing (two ALSA drivers?). > > No I don't think we want two ALSA drivers, we want one that works > right in all cases. Nevertheless, I don't see how it could be a bad thing to post your code here on wine-devel; that way others could at least borrow from your code. Alternatively, finish the driver, and if it's better than the existing one, perhaps it should replace it... wine-devs including AJ cannot possibly know if your code is better or worse, or how to use it or not use it, without seeing it. I agree that two drivers is silly but that doesn't mean your code cannot be used in some other way... there may be some other problem for all I know, but the two-drivers thing is a red herring. Don't let that stop you from sharing the fruits of your labor, if that is what you want to do... -- gmt "Every normal man must be tempted, at times, to spit on his hands, hoist the black flag, and begin slitting throats." -- H. L. Mencken
Re: mine is better!
On Sunday 07 September 2003 06:16 pm, Ove Kaaven wrote: > On Sun, 2003-09-07 at 23:14, Gregory M. Turner wrote: > > whee! another glibc mystery... > > If so, why don't you say which glibc version you use and whether you > upgraded recently? good point. It's gentoo 2.3.2-r1, with the nptl USE flag set. I did rebuild it relatively recently, and again today just to see if it magically fixed itself (no dice)... but wine was OK sometime between those two builds, which would seem to indicate some external cause. > I assume a full rebuild (make clean) doesn't fix it? 'fraid not, I even tried a clean out-of-source build from nothing. > > I do not buy, in the final analysis, that this is anything to do with nss > > or nscd (which I don't even run, although running it doesn't fix > > anything)... > > Don't let the names fool you, these read local /etc/passwd and > /etc/resolv.conf files when there's no such server configured. And > getpwuid() sounds suspiciously like something that would read > /etc/passwd. Indeed, strace shows them being read > I've heard there's been some binary incompatibility in this > area of glibc lately (not with applications, but between glibc and the > nss modules (used to access /etc/passwd), so that services would have to > restarted after upgrading glibc, and programs statically linked with an > "old" glibc wouldn't work, with win4lin being a casualty of this). well since everything is from source on my box (except army ops :)) that shouldn't be my problem... the nss libs are part of the glibc ebuild, so it really all ought be in sync maybe it's time for me to rebuild glibc with debug symbols... I still suspect that the root cause is some incredibly trivial act of systems-administrative stupidity on my part :( thanks for your help, -- gmt "We have to get basically voters to say 'I'd like to vote for the politician who thinks of global equity'" -- Bill Gates, World Economic Forum 2002
mine is better!
whee! another glibc mystery...
[EMAIL PROTECTED] wine_bld_nat $ wine
Segmentation fault
[EMAIL PROTECTED] wine_bld_nat $ strace wine
[[ snip ]]
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4035e000
mprotect(0x4002e000, 729088, PROT_READ|PROT_WRITE) = 0
mprotect(0x4002e000, 729088, PROT_READ|PROT_EXEC) = 0
set_thread_area({entry_number:-1 -> 6, base_addr:0x4035e980, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
munmap(0x40017000, 93917) = 0
brk(0) = 0x3c002000
brk(0x3c003000) = 0x3c003000
set_thread_area({entry_number:-1 -> 7, base_addr:, limit:0, seg_32bit:0,
contents:0, read_exec_only:1, limit_in_pages:0, seg_not_present:1, useable:0}) = 0
set_thread_area({entry_number:7, base_addr:0x400fee60, limit:4095, seg_32bit:1,
contents:0, read_exec_only:0, limit_in_pages:0, seg_not_present:0, useable:0}) = 0
open("/opt/wine/lib/wine/ntdll.dll.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0\360\1"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=4166825, ...}) = 0
close(3)= 0
open("/opt/wine/lib/wine/kernel32.dll.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\\2"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=3495695, ...}) = 0
mmap2(NULL, 949024, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4035f000
mprotect(0x4042f000, 97056, PROT_NONE) = 0
mmap2(0x4042f000, 98304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xd0) =
0x4042f000
close(3)= 0
mprotect(0x4035f000, 851968, PROT_READ|PROT_WRITE) = 0
mprotect(0x4035f000, 851968, PROT_READ|PROT_EXEC) = 0
mprotect(0x40227000, 5, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x40227000, 5, PROT_READ|PROT_EXEC) = 0
mprotect(0x402f7000, 5, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x402f7000, 5, PROT_READ|PROT_EXEC) = 0
mprotect(0x402f4000, 5, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0x402f4000, 5, PROT_READ|PROT_EXEC) = 0
getcwd("/home/greg/src/wine/wine_bld_nat", 512) = 33
getuid32() = 1000
socket(PF_UNIX, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ENOENT (No
such file or directory)
close(3)= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
[EMAIL PROTECTED] wine_bld_nat $ gdb /opt/wine/bin/wine
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) run
Starting program: /opt/wine/bin/wine
Program received signal SIGSEGV, Segmentation fault.
0x4000bba7 in _dl_init_internal () from /lib/ld-linux.so.2
(gdb) bt
#0 0x4000bba7 in _dl_init_internal () from /lib/ld-linux.so.2
#1 0x4027fdd0 in _IO_link_in_internal () from /lib/libc.so.6
#2 0x4027d546 in _IO_new_file_init () from /lib/libc.so.6
#3 0x40272d94 in __fopen_internal () from /lib/libc.so.6
#4 0x40272e0e in fopen@@GLIBC_2.1 () from /lib/libc.so.6
#5 0x402f5786 in nss_parse_file () from /lib/libc.so.6
#6 0x402f52a3 in __nss_database_lookup () from /lib/libc.so.6
#7 0x402f6f95 in __nss_passwd_lookup () from /lib/libc.so.6
#8 0x402b91cf in getpwuid_r@@GLIBC_2.1.2 () from /lib/libc.so.6
#9 0x402b8ad8 in getpwuid () from /lib/libc.so.6
#10 0x40109a10 in init_paths () at ../../../wine/libs/wine/config.c:112
#11 0x40109e25 in wine_get_server_dir () at ../../../wine/libs/wine/config.c:193
#12 0x4009ce8a in CLIENT_InitServer () at ../../../wine/scheduler/client.c:641
#13 0x4009e3f6 in process_init (argv=0xb444) at
../../../wine/scheduler/process.c:306
#14 0x4009ea28 in __wine_process_init (argc=1, argv=0xb444) at
../../../wine/scheduler/process.c:480
#15 0x4010bb99 in wine_init (argc=1, argv=0xb444, error=0xbfffeff4 "",
error_size=1024)
at ../../../wine/libs/wine/loader.c:428
#16 0x3c000540 in main (argc=1, argv=0xb444) at ../../wine/miscemu/main.c:33
#17 0x4022748e in __libc_start_main () from /lib/libc.so.6
(gdb) up
#1 0x4027fdd0 in _IO_link_in_internal () from /lib/libc.so.6
(gdb)
#2 0x4027d546 in _IO_new_file_init () from /lib/libc.so.6
(gdb)
#3 0x40272d94 in __fopen_internal () from /lib/libc.so.6
(gdb)
#4 0x40272e0e in fopen@@GLIBC_2.1 () from /lib/libc.so.6
(gdb)
#5 0x402f5786 in nss_parse_file () from /lib/libc.so.6
(gdb)
#6 0x402f52a3 in __nss_database_lookup () from /lib/libc.so.6
(gdb)
#7 0x402f6f95 in __nss_passwd_lookup () from /lib/libc.so.6
(gdb)
#8 0x402b91cf in getpwuid_r@@GLIBC_2.1.2 () from /lib/libc.so.6
(gdb)
#9 0x402b8ad8 in getpwuid () from /lib/libc.so.6
(gdb)
#1
