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

Re: wine/dlls/winsock/socket.c: Force SO_REUSEADDR on before bind()/Ignore SO_DONTROUTE

by Christoph Frick

On 9 Dec 2002, Martin Wilck wrote: Hi Martin, All > Sorry, this is definitely wrong. Windows, just as Unix, returns > WSAEADDRINUSE if SO_REUSEADDR isn't set (just tried it on W2k). There > must be some special circumstances involved in those games the patch is > supposed to fix. Perhaps they assume a certain Winsock implementation or > Windows version. yeah i am sure there are. also the dontroute stuff is a 100% evil hack. At least i got this time some attention :) About the games: GPL is from 1998 and N2002 is from 2001/2002. They suffer both from the same problem - i guess they expect a behavior not a version. > I'd like to know what remote addresses exactly the apps call bind() for, > and in what order. Perhaps there are subtle differences in the way > EADDRINUSE and SO_REUSEADDR are handled. I can basically describe you what this games do network-wise and/or i can provide you with traces (with and without patch) - what do you prefer? What i can not do is testing in windows. > However the patch implements the first behavior (ignore) whereas > the Windows TCP/IP transport behaves as the second (later calls to > getsockopt() refelect the SO_DONTROUTE settings, which seems to have no > further effect). So closer to windows would be store and ignore. In general i wonder, if windows does this always or if this depends somehow on the "device" the socket is finally bound to - or in other words: is always the same code on windows in charge or could it be that this might be implemened e.g. by a NIC driver. Why i ask: please see my mail to wine-devel from 2002-10-25; the game also checks the .../NetTrans/... settings. Maybe here is something missing that tell the game to set SO_DONTROUTE. Wine does not set them automatically like other hardware/driver related stuff. I really can not imagine, why a game should set this option explicit when it connects to an server (the ip/name is entered manually in this case, so the game should expect the host not in the same network). > Please don't get me wrong: These issues need to be fixed, but please, > not by applying hackish patches for special applications such as this > one. I think 100% the same way here. > Christoph: sorry I missed out on your previous mails to wine-devel. > Next time, say something about sockets in the subject line and chances > are I won't miss them again. Yes you are right. At least the last mail had no single word about the network issues with this games in the subject. I will try to focus more on the real problem next time. Thanx for your reply CU!

Dec. 9, 2002

Re: wine/dlls/winsock socket.c

by Martin Wilck

Am Sam, 2002-12-07 um 00.19 schrieb Alexandre Julliard: > Christoph Frick <frick(a)SC-Networks.de> > Force (WS_)SO_REUSEADDR before binding to a socket; Sorry, this is definitely wrong. Windows, just as Unix, returns WSAEADDRINUSE if SO_REUSEADDR isn't set (just tried it on W2k). There must be some special circumstances involved in those games the patch is supposed to fix. Perhaps they assume a certain Winsock implementation or Windows version. I'd like to know what remote addresses exactly the apps call bind() for, and in what order. Perhaps there are subtle differences in the way EADDRINUSE and SO_REUSEADDR are handled. > ignore (WS_)SO_DONTROUTE; Network games in Grand Prix Legends and Nascar 2002 > are possible now. Footnote (i) in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/wi… says that this is - in principle - legal: "A service provider may silently ignore this option on WSPSetSockOpt and return a constant value for WSPGetSockOpt, or it may accept a value for WSPSetSockOpt and return the corresponding value in WSPGetSockOpt without using the value in any way." However the patch implements the first behavior (ignore) whereas the Windows TCP/IP transport behaves as the second (later calls to getsockopt() refelect the SO_DONTROUTE settings, which seems to have no further effect). > Patch: http://cvs.winehq.com/patch.py?id=6523 Alexandre, please back this patch out for now, at least the SO_REUSEADDR part which is plain wrong. Please don't get me wrong: These issues need to be fixed, but please, not by applying hackish patches for special applications such as this one. Christoph: sorry I missed out on your previous mails to wine-devel. Next time, say something about sockets in the subject line and chances are I won't miss them again. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Dec. 9, 2002

RE: wpp

by Patrik Stridvall

> On December 8, 2002 06:01 pm, Patrik Stridvall wrote: > > It would be very nice it something made a GNU C compiler > > library to support among other things only running > > the preprocessor. > > Um, you mean like "cpp"? The debian packagers have even split > it out from > the gcc package for convenience, the package description explains; > > --------- > [snip] > The GNU C preprocessor is a macro processor that is used > automatically by > the GNU C compiler to transform programs before actual compilation. > > This package has been separated from gcc for the benefit of those who > require the preprocessor but not the compiler. > [snip] > --------- > > so clearly it can be done, and this is presumably for the > reasons Dimitrie > mentioned - preprocessing can be a useful (and much faster) subset to > separate out from the compilation process. Note that I said LIBRARY. Still running cpp is presumably more lightweight that running "gcc -E". > But as for the GPL argument against using the GNU C > (pre)compiler from a > run-time (ie. "forking/exec of 'gcc -E' is like linking to a > GPL lib"), I > find that rather hard to believe - especially as invoking > "gcc -E" can be > framed in very user-supplied terms. Eg. if the user is able to (in > theory) configure the program to exec() any precompilation > programs (and > command-line options) they want, then who is going to sue > *who* when the > default value for that setting just happens to be "gcc -E" when the > program installs? Exactly, as I said, it would never fly in court. However that doesn't mean that the FSF doesn't claim it never the less: http://www.fsf.org/licenses/gpl-faq.html#GPLInProprietarySystem > Richard Stallman will sue Redhat? Or will > the FSF begin > a crackdown against adolescent nerds who illegally point > GPL-incompatible > configuration files to GPL-licensed precompilers ...? I really don't > think this should be a cause for concern. No, I don't think it would be a cause for concern either. Still, as I said, that is what they claim. Obviously they are not stupid so it would be very unlikely that they would press the issue. They seem to prefer to use FUD to accieve their goals instead.

Dec. 9, 2002

Re: Winedbg and gcc 3.2

by Alberto Massari

Thanks for your answer, Alberto At 19.00 06/12/2002 +0100, Eric Pouech wrote: >Alberto Massari a écrit : > > > > Hi everybody, > > a few weeks ago I changed my build machine from a RedHat 7.2 + gcc 2.9x to > > a Mandrake 9.0 + gcc 3.2, and I noticed that I was unable to debug the Wine > > libraries (I got messages like "No debug information in ELF > > '/usr/local/lib/wine/xxxx.dll.so'), while gdb worked just fine. >this has already been discussed a month ago (or so) > > > My questions at this point are: > > - is this behavior typical of every gcc 3.2? or it's only Mandrake that > > does it? >generic to 3.2 > > > - is somebody going to change the "configure" script to detect such a > > situation and specify "-gstabs" instead of "-g"? (I would volunteer myself, > > but I am not expert in this field... I just hacked my copy to make it work > > in my tree) >the "current fix" is to use CFLAGS=-gstabs configure > > > - or should winedbg be improved to understand more debug formats, so that > > it can handle whatever informations the "-g" option spits out? >no dwarfII support is planned for winedbg > >you can also use the dbg proxy in wine if you want to use dwarf debug >format > >A+

Dec. 9, 2002

Re: GDI RestoreDC()

by Mike Hearn

Thanks :) I wasn't aware of that. I haven't been able to get any more insight from staring at traces, so I was wondering if the next step would be disassembly of the plugin so I can try and figure out what decisions it's making that would lead to it not blitting the rendered image to the screen. My questions are: 1) Is this acceptable in Wine? I'm not based in the US btw. 2) If so, are there any guides on how to do it? 3) What disassembly programs are recommended? 4) Is this even what I should be considering next, or are there perhaps other ways of figuring out what's going wrong? thanks -mike On Thu, 2002-12-05 at 21:21, Francois Gouget wrote: > On 5 Dec 2002, Mike Hearn wrote: > [...] > > I can't figure out what ffffffff would be as an int though :( Would it > > be negative or positive? > > For a 32 bit signed int, 0xffffffff == -1. > See: > http://burks.brighton.ac.uk/burks/foldoc/42/120.htm -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Dec. 9, 2002

RE: wpp

by Patrik Stridvall

> In other words, preprocessing is like 10% of compilation, so > it can't be unbearably slow. Something else is wrong. Perhaps. It was quite a few years ago I did it. I just remember abandoning the idea of using "gcc -E" for preprocessing in winapi_check because of horrible a speed slowdown. > > The FSF claims that you forking and calling a GPL:ed executable > > is the same as linking with a GPL:ed library and calling > > functions in that library. > > Do you have a reference to this? Never heard of something like > this before. It was dicussed extensively during the great licensing war. http://www.fsf.org/licenses/gpl-faq.html#GPLInProprietarySystem The main part is this I think: < The difference between this and "incorporating" the GPL-covered software < is partly a matter of substance and partly form. The substantive part is < this: if the two programs are combined so that they become effectively < two parts of one program, then you can't treat them as two separate programs. < So the GPL has to cover the whole thing. In the case of wrc it is pretty clear that "gcc -E" will one of the parts of the whole program and thus wrc must be under the GPL (or compatible with it). While, as I said earlier, this is a not a direct problem for a LGPL application, we have as I said I policy not to "link" with GPL:ed applications.

Dec. 9, 2002

Re: Fw: Loading Autorun.inf on CD's

by Fabian Cenedese

> > If we tweak the registry of a .inf (winedefault.reg), we can ask it to > > launch a tiny program that will open the .inf and run the program > > specified. > >Sounds like it could work, but what about inf installer files (ie TweakUI's >inf, or driver inf files) how would they be handled? Generally, .inf files are all installer files, only the autorun.inf is something special. If the file on the CD is named differently it doesn't work anymore. So we would just have to check for this name. I don't know how it is done on Windows, what makes the auto-insert check. But whatever program gets the insert notification it should call 'wine wineautorun.exe autorun.inf'. Wineautorun.exe will parse the autorun.inf. And all other .inf go to the installer. bye Fabi

Dec. 9, 2002

Re: Janitorial Projects -- conformance tests --recruiting volunteers

by David Miller

I could probably run some tests under WinXP. I just need to compile the tests on windows, execute them, and post output to wine-devel? Is this correct?

Dec. 9, 2002

Re: Janitorial Projects -- conformance tests --recruiting volunteers

by David Miller

As someone only attempting to learn C I am looking for some other way to contribute something to wine. I have WinXP home on my laptop, so I could do WinXP tests if you can give me more information on what needs to be done. Dave

Dec. 8, 2002

Re: wpp

by Geoff Thorpe

On December 8, 2002 06:01 pm, Patrik Stridvall wrote: > It would be very nice it something made a GNU C compiler > library to support among other things only running > the preprocessor. Um, you mean like "cpp"? The debian packagers have even split it out from the gcc package for convenience, the package description explains; --------- [snip] The GNU C preprocessor is a macro processor that is used automatically by the GNU C compiler to transform programs before actual compilation. This package has been separated from gcc for the benefit of those who require the preprocessor but not the compiler. [snip] --------- so clearly it can be done, and this is presumably for the reasons Dimitrie mentioned - preprocessing can be a useful (and much faster) subset to separate out from the compilation process. But as for the GPL argument against using the GNU C (pre)compiler from a run-time (ie. "forking/exec of 'gcc -E' is like linking to a GPL lib"), I find that rather hard to believe - especially as invoking "gcc -E" can be framed in very user-supplied terms. Eg. if the user is able to (in theory) configure the program to exec() any precompilation programs (and command-line options) they want, then who is going to sue *who* when the default value for that setting just happens to be "gcc -E" when the program installs? Richard Stallman will sue Redhat? Or will the FSF begin a crackdown against adolescent nerds who illegally point GPL-incompatible configuration files to GPL-licensed precompilers ...? I really don't think this should be a cause for concern. Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/

Dec. 8, 2002

Re: wrc options

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > I know that wrc does more than windres. I was just asking if some of > these options are superfluous. In particular, do we need to support > win16 resources? Yes we do, some of our 16-bit dlls have resources. -- Alexandre Julliard julliard(a)winehq.com

Dec. 8, 2002

Re: wpp

by Dimitrie O. Paun

On December 8, 2002 05:56 pm, Alexandre Julliard wrote: > I believe it was mostly issues with getting rid of C code in header > files, though that is handled in the main parser now. Still, it's not > guaranteed that the C preprocessor would handle non C code correctly. Hmm, I don't know about that either -- windres certainly calls gcc -E, and it's working just fine. Anyway, I don't see a compelling reason to change the status quo, thanks for helping me clarify this issue. -- Dimi.

Dec. 8, 2002

Re: wpp

by Dimitrie O. Paun

On December 8, 2002 05:58 pm, Ove Kaaven wrote: > http://www.winehq.com/news/?view=36#Wine's%20resource%20compiler Thanks for the reference, nice summary! :) > Seems you argued against wrc having its own cpp implementation already > back then. Yeah, I remember arguing against it than, but I could not remember what were the pro/cons arguments, and if they still hold true. I do agree that Bertho had the right to do whatever he wanted, he was doing the work. In fact, I understand Bertho's motivation, it's just not sure to me that it makes sense in the Wine context. Anyway, thanks again for helping me refresh my memory. Much appreciated! :) -- Dimi.

Dec. 8, 2002

Re: wpp

by Dimitrie O. Paun

On December 8, 2002 06:01 pm, Patrik Stridvall wrote: [it seems that there are resons to keep wpp, but since it's a slow evening, I will respond... :)] > I personally have only tried piping every file parsed by > winapi_check through "gcc -E" and it is was unbearably slow, > so I removed the code. The parsing it itself can't possibly > taken that extra time. So how do you account for the fact that compiling a .c file is fast? It certanily does a hell of a lot more than preprocessing. Look: [dimi(a)dimi server]$ time gcc -c -I../../wine.src/server -I. -I../../wine.src/include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -o trace.o ../../wine.src/server/trace.c real 0m5.276s user 0m4.129s sys 0m0.102s [dimi(a)dimi server]$ time gcc -E -I../../wine.src/server -I. -I../../wine.src/include -I../include -g -O2 -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -o trace.o ../../wine.src/server/trace.c real 0m0.538s user 0m0.166s sys 0m0.012s In other words, preprocessing is like 10% of compilation, so it can't be unbearably slow. Something else is wrong. > The FSF claims that you forking and calling a GPL:ed executable > is the same as linking with a GPL:ed library and calling > functions in that library. Do you have a reference to this? Never heard of something like this before. -- Dimi.

Dec. 8, 2002

RE: wpp

by Patrik Stridvall

> On December 8, 2002 03:27 pm, Patrik Stridvall wrote: > > It is faster. Mucher faster. Using cpp/gcc -E needs to > > fork a new process for example. > > What?!? You got to be kiddin', right? If you can measure > any difference in build time between the forking gcc -E > and using wpp I'll give you a dollar in small change. I personally have only tried piping every file parsed by winapi_check through "gcc -E" and it is was unbearably slow, so I removed the code. The parsing it itself can't possibly taken that extra time. So I'm pretty sure that I can measure it, yes. However, the big question is not if it is measuarable but rather if it is worth the cost or not. So, yes, I agree that we need to discuss the question. > On Linux process creating is extremely fast, and we do > fork 1000s of processes while building wine, this sort > of argument is just silly. Well, it is not really the "fork" in it self that is the problem it is the overhead of loading and initializing gcc and that sort of things. > By the same rationale I suggest having a complete copy > of gcc, ld, nm, and whatever tools we use while building > wine. It is not primarily a question of having a complete copy of whatever. It is a question of having whatever accessable as functions in a library to avoid a lot of unnessary overhead. It would be very nice it something made a GNU C compiler library to support among other things only running the preprocessor. > So no, if speed is the only argument, I say we get rid > of it: it's not worth maintaining a fraction of all that > additional code. 1. Depending on "gcc -E" will make it harder to port wrc to Windows. 2. It might be less flexible (not sure though). > > And then of course using "gcc -E" would possibly cause > > a GPL violatation. Not that it would matter very much > > if wrc and friend were GPL:ed. > > WTF are you talking about?!? How did you figure this one > out? Really, this is simply false, you can fork GPL > programs all you want, and cause no GPL violation. The FSF claims that you forking and calling a GPL:ed executable is the same as linking with a GPL:ed library and calling functions in that library. This is of course absurd and would IMHO opinion nether fly in a court of law but still.... Sure wrc and friend are under a GPL compatible license (LGPL), so it wouldn't be a direct violation. However Wine has a policy that we do not link with GPL:ed libraries regardless in order to avoid possible problems for companies working with Wine so no we really can't make wrc depend of "gcc -E".

Dec. 8, 2002

Re: wrc options

by Dimitrie O. Paun

On December 8, 2002 05:57 pm, Alexandre Julliard wrote: > wrc does a lot more than windres. We don't use all the features in the > Wine building process but that's not a reason for removing them. I know that wrc does more than windres. I was just asking if some of these options are superfluous. In particular, do we need to support win16 resources? -- Dimi.

Dec. 8, 2002

Re: wpp

by Ove Kaaven

On Sun, 8 Dec 2002, Dimitrie O. Paun wrote: > Folks, > > Anyone remembers why we need our own cpp implementation, > instead of simply using cpp/gcc -E? http://www.winehq.com/news/?view=36#Wine's%20resource%20compiler Seems you argued against wrc having its own cpp implementation already back then. So the real reason why we now have wpp is probably because it was Bertho who implemented wrc and nobody else, and he wanted wrc to have an integrated preprocessor. No really compelling reasons were cited, but volunteers willing to do something themselves need no better reason. And I wouldn't mind keeping it, it's fast, easy to use, and guaranteed to work with Microsoft source code. wpp got factored out of wrc when I decided to use Bertho's preprocessor for widl too.

Dec. 8, 2002

Re: wrc options

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > I was looking at wrc a little bit, and I am curious to know if > we really need all these options. They just pollute the command line > namespace, and add confusion. windres has none of these options, > and it's doing just fine. wrc does a lot more than windres. We don't use all the features in the Wine building process but that's not a reason for removing them. -- Alexandre Julliard julliard(a)winehq.com

Dec. 8, 2002

Re: wpp

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Anyone remembers why we need our own cpp implementation, > instead of simply using cpp/gcc -E? I believe it was mostly issues with getting rid of C code in header files, though that is handled in the main parser now. Still, it's not guaranteed that the C preprocessor would handle non C code correctly. -- Alexandre Julliard julliard(a)winehq.com

Dec. 8, 2002

Re: Intel 8x0 and ALSA sound driver

by Michal Janusz Miroslaw

Well, I use something easier - change all hw:x to hw (default ALSA card). And select this default using ALSA_CARD environment variable. Patch against current CVS follows. Index: audio.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/winealsa/audio.c,v retrieving revision 1.8 diff -u -r1.8 audio.c --- audio.c 25 Oct 2002 19:09:02 -0000 1.8 +++ audio.c 8 Dec 2002 22:33:18 -0000 @@ -217,13 +217,13 @@ } \ } while(0) - EXIT_ON_ERROR( snd_ctl_open(&ctl,"hw:0",0) , "ctl open failed" ); + EXIT_ON_ERROR( snd_ctl_open(&ctl,"hw",0) , "ctl open failed" ); EXIT_ON_ERROR( snd_ctl_card_info(ctl, cardinfo), "card info failed"); EXIT_ON_ERROR( snd_ctl_elem_list(ctl, elemlist), "elem list failed"); nCtrls = snd_ctl_elem_list_get_count(elemlist); - EXIT_ON_ERROR( snd_hctl_open(&hctl,"hw:0",0), "hctl open failed"); + EXIT_ON_ERROR( snd_hctl_open(&hctl,"hw",0), "hctl open failed"); EXIT_ON_ERROR( snd_hctl_load(hctl), "hctl load failed" ); elem=snd_hctl_first_elem(hctl); @@ -405,7 +405,7 @@ wwo = &WOutDev[0]; /* FIXME: use better values */ - wwo->device = "hw:0,0"; + wwo->device = "hw"; wwo->caps.wMid = 0x0002; wwo->caps.wPid = 0x0104; strcpy(wwo->caps.szPname, "SB16 Wave Out");

Dec. 8, 2002

Re: wpp

by Eric Pouech

> Anyone remembers why we need our own cpp implementation, > instead of simply using cpp/gcc -E? IIRC it was a standalone program that Bertho maintained (and used in lots of other contexts than wine) (but I don't remember which ones) anyway, the tool has been incorporated into wine as it was some options must remain from those days :-) A+

Dec. 8, 2002

Re: Wine/FF7 midi help request

by Eric Pouech

> I tried this with the FF7config program, and it produced 26K of > output; I've put the complete dump at > > http://www.eyrie.org/~robotech/winemidi.txt please try with the little patch (post above) applied and let me know what gives A+

Dec. 8, 2002

Re: wpp

by Dimitrie O. Paun

On December 8, 2002 03:27 pm, Patrik Stridvall wrote: > It is faster. Mucher faster. Using cpp/gcc -E needs to > fork a new process for example. What?!? You got to be kiddin', right? If you can measure any difference in build time between the forking gcc -E and using wpp I'll give you a dollar in small change. On Linux process creating is extremely fast, and we do fork 1000s of processes while building wine, this sort of argument is just silly. By the same rationale I suggest having a complete copy of gcc, ld, nm, and whatever tools we use while building wine. So no, if speed is the only argument, I say we get rid of it: it's not worth maintaining a fraction of all that additional code. > And then of course using "gcc -E" would possibly cause > a GPL violatation. Not that it would matter very much > if wrc and friend were GPL:ed. WTF are you talking about?!? How did you figure this one out? Really, this is simply false, you can fork GPL programs all you want, and cause no GPL violation. -- Dimi.

Dec. 8, 2002

Re: wrc options

by Steven Edwards

> > " -B x Set output byte-order x={n[ative], l[ittle], b[ig]}\n" > " (win32 only; default is n[ative] which equals " > > Again, shouldn't this be hardcoded to some standard value, that we > expect in Wine when we read the resources? The CPU byte-order is needed although I dont know if it works or not. The little bit of work I have been doing on alpha is stalled atm as I dont know axp asm =). Anyway when I get compiling resources with wrc I get a error about the resource format which I assume could be fixed by using this switch if it really works. If it does I will resubmit my configure patch for alpha with a define for winebuild to do this on a alpha platform unless you want to grandfather this switch and do it some other way. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Dec. 8, 2002

RE: wpp

by Patrik Stridvall

> Anyone remembers why we need our own cpp implementation, > instead of simply using cpp/gcc -E? It is faster. Mucher faster. Using cpp/gcc -E needs to fork a new process for example. And then of course using "gcc -E" would possibly cause a GPL violatation. Not that it would matter very much if wrc and friend were GPL:ed. Obviously any GPL claim would be absurd as we discussed to death in the great licensing flamewar but still.

Dec. 8, 2002

Re: Intel 8x0 and ALSA sound driver

by Nikolay Stefanov

On Sunday 08 December 2002 5:39 pm, Eric Pouech wrote: > which I'm say is a bad idea. the Alsa driver should report all available > drivers, and you should not be forced to define the one you want. > To be more correct, the notion of "default device" exists under windows, > but has to be handled at the wave mapper level, not at the driver level. Aha, got it. I doubt that I will be able to implement this, so I might just file it as a bug report. > that's why I say we have to remove those assertions and do proper error > handling instead > btw, if ALSA fails with an assert it's either: > - a bug in the ALSA driver > - a bug in the ALSA library > => those should be fixed (as ALSA isn't 1.0 yet, there's no need to work > around it in wine code) I had a look at mplayer code and it is structured in a completely different way than winealsa for the mmap case. I'm looking at wodPlayer_WriteMaxFrags, btw. This leads me to believe that the way wine does it is off, and it's not a driver issue... I'll try to tinker a bit with it and see whether I have any success. Nikolay

Dec. 8, 2002

Re: Intel 8x0 and ALSA sound driver

by Nikolay Stefanov

On Sunday 08 December 2002, Eric Pouech wrote: > I assume you're using ALSA 0.9 (not 0.5) and that winamp uses the dsound > interface Correct, however the result is the same (doesn't work) with both waveout and dsound interface, because of said hw limitations. > I don't think this is the right think to do: > - from hard coding the driver name, winealsa should enumerate all > installed alsa drivers, and be prepared to open such a device Just to clarify - the device name *was* hardcoded to "hw,0", the patch makes it possible to specify it in the configuration file. > - from the mmap configuration, this should be identified at run time, > not by an obscure configuration option Well, it is identified at run time by the current code, and the driver tries to use it, but it doesn't work. So I added the option as a way to tell winealsa not to use the mmap interface. Here is the error that I get if mmap is enabled: trace:wave:wodPlayer_WriteMaxFrags Writing wavehdr 0x4122c260.0[32768] wine: pcm_plugin.c:491: snd_pcm_plugin_mmap_commit: Assertion `size == 0' failed. Those ALSA assertions are pretty annoying, no way to inspect the error or to bail out :-( Nikolay

Dec. 8, 2002

Re: Intel 8x0 and ALSA sound driver

by Eric Pouech

Nikolay Stefanov wrote: > Hi, > > I have a SIS SI7012 (Intel 810 chipset) built-in audio card, which turns out > to be capable of only 48000Hz sample rate in hardware. The ALSA winmm driver > in Wine is hardcoded to use the first hardware pcm device ("hw:0") directly, > and therefore fails for any wave format request with a sample rate different > than 48000Hz. I have lifted some code from dsound and put together a patch > which adds the option to read the device name from the Wine configuration > file. As a result I have now got Winamp working (hurray for me!). > > HOWEVER there are still issues - the "default" ALSA device doesn't like the > way Wine accesses it through mmap, and also it seems that it is not possible > to set the buffer size and period size the way it is done now. Other programs > that use ALSA, like aplay and mplayer, don't have this problem. My knowledge > of Wine and ALSA is pretty meagre, so can anyone can provide any insight as > to how to fix this issue? > > My config file now looks like this > [alsa] > ;"Device" = "hw:0" > "Device" = "default" > "UseMMAP" = "N" I assume you're using ALSA 0.9 (not 0.5) and that winamp uses the dsound interface I don't think this is the right think to do: - from hard coding the driver name, winealsa should enumerate all installed alsa drivers, and be prepared to open such a device - from the mmap configuration, this should be identified at run time, not by an obscure configuration option A+

Dec. 8, 2002

wrc options

by Dimitrie O. Paun

Hello people, I was looking at wrc a little bit, and I am curious to know if we really need all these options. They just pollute the command line namespace, and add confusion. windres has none of these options, and it's doing just fine. Let me be more explicit: " -a n Alignment of resource (win16 only, default is 4)\n" Do we really need this? Shouldn't this be hardcoded to some standard values? " -A Auto register resources (only with gcc 2.7 and better)\n" " -b Create an assembly array from a binary .res file\n" Do we still want to create the assembly output? Do we still use that? " -B x Set output byte-order x={n[ative], l[ittle], b[ig]}\n" " (win32 only; default is n[ative] which equals " Again, shouldn't this be hardcoded to some standard value, that we expect in Wine when we read the resources? " -c Add 'const' prefix to C constants\n" What's this good for? " -e Disable recognition of win32 keywords in 16bit compile\n" Shouldn't this be on be default? Should we even support 16bit compiles anymore? " -E Preprocess only\n" ??? What for? " -g Add symbols to the global c namespace\n" Is this choice useful? " -h Also generate a .h file\n" " -H file Same as -h but written to file\n" I would personally collapse this one into the type of output to be generated. " -L Leave case of embedded filenames as is\n" Shouldn't this one be on by default? Why do we need this option? " -m Do not remap numerical resource IDs\n" What is this one used for? " -n Do not generate .s file\n" Should we still generate .s files in the first place? " -p prefix Give a prefix for the generated names\n" Why? " -r Create binary .res file (compile only)\n" I would make this default behavior. " -s Add structure with win32/16 (PE/NE) resource directory\n" I'd guess if we need it, it should be generated, if not, just don't do it. Why do we have an option? " -t Generate indirect loadable resource tables\n" " -T Generate only indirect loadable resources tables\n" What are these used for? " -w 16|32 Select win16 or win32 output (default is win32)\n" Should we care about win16 in the first place? We clearly never going to support win16 in Winelib, so why have this option? -- Dimi.

Dec. 8, 2002

Fw: Loading Autorun.inf on CD's

by Dustin Navea

----- Original Message ----- From: "Sylvain Petreolle" <spetreolle(a)yahoo.fr> To: "Tony Lambregts" <tony_lambregts(a)telusplanet.net>; "Dustin Navea" <speeddymon(a)sbcglobal.net> Cc: "Sylvain Petreolle" <spetreolle(a)yahoo.fr>; "Wine Developers" <wine-devel(a)winehq.com> Sent: Sunday, December 08, 2002 5:11 AM Subject: Re: Loading Autorun.inf on CD's > If you want act in this way, I have something for you. > This could help Paul Jones, who is searching how to "launch" *.msi > installers. interesting > The better way we can handle this is a program who tries to open every > document we give to it. A freeware utility exists in cygwin world and > is called cygstart, using the existing registry. If we give it a .doc, > it looks in HKCR and starts Worpad/Winword. > That is a definite must.. > If we tweak the registry of a .inf (winedefault.reg), we can ask it to > launch a tiny program that will open the .inf and run the program > specified. Sounds like it could work, but what about inf installer files (ie TweakUI's inf, or driver inf files) how would they be handled? > > I have not seen this work either and definitely not with an .inf. Yes > > it > > would be cool and if you want to start a bug concerning it feel free. > > I > > am not that worried about it though. The way I see it is that most of > > > > this is not realy a wine problem but rather with setting up autorun > > so > > that it is able to understand what to do with an .inf file. I suppose > > > > another way to look at it might be that wcmd could/should be able to > > handle something like "wcmd autorun.inf". > > -Dustin

Dec. 8, 2002

wpp

by Dimitrie O. Paun

Folks, Anyone remembers why we need our own cpp implementation, instead of simply using cpp/gcc -E? -- Dimi.

Dec. 8, 2002

Intel 8x0 and ALSA sound driver

by Nikolay Stefanov

Hi, I have a SIS SI7012 (Intel 810 chipset) built-in audio card, which turns out to be capable of only 48000Hz sample rate in hardware. The ALSA winmm driver in Wine is hardcoded to use the first hardware pcm device ("hw:0") directly, and therefore fails for any wave format request with a sample rate different than 48000Hz. I have lifted some code from dsound and put together a patch which adds the option to read the device name from the Wine configuration file. As a result I have now got Winamp working (hurray for me!). HOWEVER there are still issues - the "default" ALSA device doesn't like the way Wine accesses it through mmap, and also it seems that it is not possible to set the buffer size and period size the way it is done now. Other programs that use ALSA, like aplay and mplayer, don't have this problem. My knowledge of Wine and ALSA is pretty meagre, so can anyone can provide any insight as to how to fix this issue? My config file now looks like this [alsa] ;"Device" = "hw:0" "Device" = "default" "UseMMAP" = "N" And this is the patch, not really useful for anyone else but me right now: ---- Patch start ----- diff -u -r wine-20021125-orig/dlls/winmm/winealsa/Makefile.in wine-20021125/dlls/winmm/winealsa/Makefile.in --- wine-20021125-orig/dlls/winmm/winealsa/Makefile.in 2002-06-28 19:31:01.000000000 +0100 +++ wine-20021125/dlls/winmm/winealsa/Makefile.in 2002-12-08 14:06:03.000000000 +0000 @@ -3,7 +3,7 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = winealsa.drv -IMPORTS = winmm user32 kernel32 ntdll +IMPORTS = winmm user32 kernel32 ntdll advapi32 EXTRALIBS = @ALSALIBS@ LDDLLFLAGS = @LDDLLFLAGS@ diff -u -r wine-20021125-orig/dlls/winmm/winealsa/alsa.c wine-20021125/dlls/winmm/winealsa/alsa.c --- wine-20021125-orig/dlls/winmm/winealsa/alsa.c 2002-07-19 01:30:16.000000000 +0100 +++ wine-20021125/dlls/winmm/winealsa/alsa.c 2002-12-08 14:52:38.000000000 +0000 @@ -25,12 +25,93 @@ #include "winbase.h" #include "wingdi.h" #include "winuser.h" +#include "winreg.h" #include "mmddk.h" #include "alsa.h" +#include "wine/debug.h" #ifdef HAVE_ALSA +WINE_DEFAULT_DEBUG_CHANNEL(wave); + static struct WINE_ALSA* alsa = NULL; + +/* configuration variables for the ALSA driver */ +#define ALSA_DEVICE_NAME_DEFAULT "hw:0" +#define ALSA_USE_MMAP_DEFAULT 1 +char alsa_device_name[MAX_PATH+1]; +int alsa_use_mmap = 1; + +/* + * Get a config key from either the app-specific or the default config + */ +inline static DWORD get_config_key( HKEY defkey, HKEY appkey, const char *name, + char *buffer, DWORD size ) +{ + if (appkey && !RegQueryValueExA( appkey, name, 0, NULL, buffer, &size )) return 0; + return RegQueryValueExA( defkey, name, 0, NULL, buffer, &size ); +} + + +/* + * Setup the alsa options. + */ +inline static void setup_alsa_options(void) +{ + char buffer[MAX_PATH+1]; + HKEY hkey, appkey = 0; + + buffer[MAX_PATH]='\0'; + + if (RegCreateKeyExA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\alsa", 0, NULL, + REG_OPTION_VOLATILE, KEY_ALL_ACCESS, NULL, &hkey, NULL )) + { + ERR("Cannot create config registry key\n" ); + ExitProcess(1); + } + + if (GetModuleFileNameA( 0, buffer, MAX_PATH )) + { + HKEY tmpkey; + + if (!RegOpenKeyA( HKEY_LOCAL_MACHINE, "Software\\Wine\\Wine\\Config\\AppDefaults", &tmpkey )) + { + char appname[MAX_PATH+16]; + char *p = strrchr( buffer, '\\' ); + if (p!=NULL) { + appname[MAX_PATH]='\0'; + strncpy(appname,p+1,MAX_PATH); + strcat(appname,"\\alsa"); + TRACE("appname = [%s] \n",appname); + if (RegOpenKeyA( tmpkey, appname, &appkey )) appkey = 0; + RegCloseKey( tmpkey ); + } + } + } + + /* get options */ + strncpy(alsa_device_name, ALSA_DEVICE_NAME_DEFAULT, MAX_PATH); + if (!get_config_key( hkey, appkey, "Device", buffer, MAX_PATH )) { + alsa_device_name[MAX_PATH] = '\0'; + strncpy(alsa_device_name, buffer, MAX_PATH); + if (strncmp(alsa_device_name, ALSA_DEVICE_NAME_DEFAULT, MAX_PATH)) { + WARN("alsa_device_name = %s (default=" ALSA_DEVICE_NAME_DEFAULT ")\n", + alsa_device_name); + } + } + + alsa_use_mmap = ALSA_USE_MMAP_DEFAULT; + if (!get_config_key( hkey, appkey, "UseMMAP", buffer, MAX_PATH )) { + alsa_use_mmap = strcmp(buffer, "N"); + if (alsa_use_mmap != ALSA_USE_MMAP_DEFAULT) { + WARN("alsa_use_mmap = %d (default=%d)\n", alsa_use_mmap, + ALSA_USE_MMAP_DEFAULT); + } + } + + if (appkey) RegCloseKey( appkey ); + RegCloseKey( hkey ); +} /************************************************************************** * ALSA_drvOpen [internal] @@ -39,7 +120,7 @@ { if (alsa) return 0; - + /* I know, this is ugly, but who cares... */ alsa = (struct WINE_ALSA*)1; return 1; @@ -71,7 +152,8 @@ switch(wMsg) { #ifdef HAVE_ALSA - case DRV_LOAD: ALSA_WaveInit(); + case DRV_LOAD: setup_alsa_options(); + ALSA_WaveInit(); return 1; case DRV_FREE: return 1; case DRV_OPEN: return ALSA_drvOpen((LPSTR)dwParam1); diff -u -r wine-20021125-orig/dlls/winmm/winealsa/alsa.h wine-20021125/dlls/winmm/winealsa/alsa.h --- wine-20021125-orig/dlls/winmm/winealsa/alsa.h 2002-08-29 02:51:32.000000000 +0100 +++ wine-20021125/dlls/winmm/winealsa/alsa.h 2002-12-08 14:19:06.000000000 +0000 @@ -29,3 +29,6 @@ #endif extern LONG ALSA_WaveInit(void); +/* config options */ +extern char alsa_device_name[]; +extern int alsa_use_mmap; Only in wine-20021125/dlls/winmm/winealsa: alsa.o diff -u -r wine-20021125-orig/dlls/winmm/winealsa/audio.c wine-20021125/dlls/winmm/winealsa/audio.c --- wine-20021125-orig/dlls/winmm/winealsa/audio.c 2002-10-25 20:09:02.000000000 +0100 +++ wine-20021125/dlls/winmm/winealsa/audio.c 2002-12-08 14:32:16.000000000 +0000 @@ -217,13 +217,13 @@ } \ } while(0) - EXIT_ON_ERROR( snd_ctl_open(&ctl,"hw:0",0) , "ctl open failed" ); + EXIT_ON_ERROR( snd_ctl_open(&ctl,alsa_device_name,0) , "ctl open failed" ); EXIT_ON_ERROR( snd_ctl_card_info(ctl, cardinfo), "card info failed"); EXIT_ON_ERROR( snd_ctl_elem_list(ctl, elemlist), "elem list failed"); nCtrls = snd_ctl_elem_list_get_count(elemlist); - EXIT_ON_ERROR( snd_hctl_open(&hctl,"hw:0",0), "hctl open failed"); + EXIT_ON_ERROR( snd_hctl_open(&hctl,alsa_device_name,0), "hctl open failed"); EXIT_ON_ERROR( snd_hctl_load(hctl), "hctl load failed" ); elem=snd_hctl_first_elem(hctl); @@ -404,8 +404,9 @@ wwo = &WOutDev[0]; + TRACE("ALSA_WaveInit device name = %s", alsa_device_name); /* FIXME: use better values */ - wwo->device = "hw:0,0"; + wwo->device = alsa_device_name; wwo->caps.wMid = 0x0002; wwo->caps.wPid = 0x0104; strcpy(wwo->caps.szPname, "SB16 Wave Out"); @@ -495,7 +496,7 @@ snd_pcm_hw_params_get_access_mask(hw_params, acmask); /* FIXME: NONITERLEAVED and COMPLEX are not supported right now */ - if ( snd_pcm_access_mask_test( acmask, SND_PCM_ACCESS_MMAP_INTERLEAVED ) ) + if ( alsa_use_mmap && snd_pcm_access_mask_test( acmask, SND_PCM_ACCESS_MMAP_INTERLEAVED ) ) wwo->caps.dwSupport |= WAVECAPS_DIRECTSOUND; } @@ -1114,7 +1115,7 @@ } while(0) access = SND_PCM_ACCESS_MMAP_INTERLEAVED; - if ( ( err = snd_pcm_hw_params_set_access(pcm, hw_params, access ) ) < 0) { + if (!alsa_use_mmap || ((err = snd_pcm_hw_params_set_access(pcm, hw_params, access)) < 0)) { WARN("mmap not available. switching to standard write.\n"); access = SND_PCM_ACCESS_RW_INTERLEAVED; EXIT_ON_ERROR( snd_pcm_hw_params_set_access(pcm, hw_params, access ), MMSYSERR_INVALPARAM, "unable to set access for playback"); @@ -1128,11 +1129,13 @@ format = (wwo->format.wBitsPerSample == 16) ? SND_PCM_FORMAT_S16_LE : SND_PCM_FORMAT_U8; EXIT_ON_ERROR( snd_pcm_hw_params_set_format(pcm, hw_params, format), MMSYSERR_INVALPARAM, "unable to set required format"); +#if 0 EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_size_near(pcm, hw_params, buffer_size), MMSYSERR_NOMEM, "unable to get required buffer"); buffer_size = snd_pcm_hw_params_get_buffer_size(hw_params); EXIT_ON_ERROR( snd_pcm_hw_params_set_period_size_near(pcm, hw_params, buffer_size/num_periods, 0), MMSYSERR_ERROR, "unable to set required period size"); period_size = snd_pcm_hw_params_get_period_size(hw_params, 0); +#endif rate = snd_pcm_hw_params_set_rate_near(pcm, hw_params, wwo->format.wf.nSamplesPerSec, 0); if (rate < 0) { @@ -1147,6 +1150,11 @@ } EXIT_ON_ERROR( snd_pcm_hw_params(pcm, hw_params), MMSYSERR_INVALPARAM, "unable to set hw params for playback"); + +#if 1 + buffer_size = snd_pcm_hw_params_get_buffer_size(hw_params); + period_size = snd_pcm_hw_params_get_period_size(hw_params, 0); +#endif snd_pcm_sw_params_current(pcm, sw_params); EXIT_ON_ERROR( snd_pcm_sw_params_set_start_threshold(pcm, sw_params, dwFlags & WAVE_DIRECTSOUND ? INT_MAX : 1 ), MMSYSERR_ERROR, "unable to set start threshold");

Dec. 8, 2002

Re: POSE (Palm OS Emulator) on WINE?

by Sylvain Petreolle

http://www.palmos.com/dev/tools/emulator/#source http://appdb.winehq.com/appview.php?appId=359&versionId=534 It runs on Linux, source is availble on their web site. (see the first link) --- Bodo Wenzel <palm.devel(a)gmx.de> a écrit : > Hi list. > > Because Sony doesn't provide a Unix source code branch, I tried to > run their > Windows based POSE on WINE. > > At first glance it runs, but only until a command of the context menu > is > chosen. WINE reports an "unhandled exception" and launches the > debugger. > > My question: does anyone heard about how to make POSE run on WINE? Is > anyone > interested in making them work together? Both are Open Source... > Unfortunately I can't because of my lack of time :-( > > TIA, Bodo > > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

Dec. 8, 2002

Re: Loading Autorun.inf on CD's

by Sylvain Petreolle

If you want act in this way, I have something for you. This could help Paul Jones, who is searching how to "launch" *.msi installers. The better way we can handle this is a program who tries to open every document we give to it. A freeware utility exists in cygwin world and is called cygstart, using the existing registry. If we give it a .doc, it looks in HKCR and starts Worpad/Winword. If we tweak the registry of a .inf (winedefault.reg), we can ask it to launch a tiny program that will open the .inf and run the program specified. > > > I have not seen this work either and definitely not with an .inf. Yes > it > would be cool and if you want to start a bug concerning it feel free. > I > am not that worried about it though. The way I see it is that most of > > this is not realy a wine problem but rather with setting up autorun > so > that it is able to understand what to do with an .inf file. I suppose > > another way to look at it might be that wcmd could/should be able to > handle something like "wcmd autorun.inf". > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

Dec. 8, 2002

Re: Loading Autorun.inf on CD's

by Sylvain Petreolle

If you want act in this way, I have something for you. This could help Paul Jones, who is searching how to "launch" *.msi installers. The better way we can handle this is a program who tries to open every document we give to it. A freeware utility exists in cygwin world and is called cygstart, using the existing registry. If we give it a .doc, it looks in HKCR and starts Worpad/Winword. If we tweak the registry of a .inf (winedefault.reg), we can ask it to launch a tiny program that will open the .inf and run the program specified. > > > I have not seen this work either and definitely not with an .inf. Yes > it > would be cool and if you want to start a bug concerning it feel free. > I > am not that worried about it though. The way I see it is that most of > > this is not realy a wine problem but rather with setting up autorun > so > that it is able to understand what to do with an .inf file. I suppose > > another way to look at it might be that wcmd could/should be able to > handle something like "wcmd autorun.inf". > ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Soyez solidaire soutenez laction du Téléthon avec Yahoo! France. http://www1.telethon.fr/030-Espace-Relais-Dons/webtirelire1.asp?hebergeur_i…

Dec. 8, 2002

Re: what to do with include/wine/obj_base.h?

by Ove Kaaven

On Sun, 8 Dec 2002, Jeff Smith wrote: > I don't really care whether the ICOM_ macros go or stay in the current form, > but if they stay, they should at least be corrected in the following sense. > > Presently, a typical macro in obj_base.h is > > #define ICOM_METHOD4(ret,xfn,ta,na,tb,nb,tc,nc,td,nd) \ > public: virtual ret CALLBACK (xfn)(ta a,tb b,tc c,td d) = 0; > > Note that we have na, nb, ... on the 'left' > matching with a, b, ... on the 'right'. > > Not that this causes problems, it's just that it isn't right. It's right enough for the purpose it was meant for, which was to let you use the macros without bothering to specify the argument names (the macros would just use the names "a", "b", etc, so you didn't have to). Even in the current CVS you can still find this usage in dplay.h and dplobby.h. It wouldn't have made sense to separate the type ("ta", "tb", ...) and name ("na", "nb", ...) arguments to the macros if that wasn't the intention. (But it would have been possible to specify array arguments...)

Dec. 8, 2002

Re: what to do with include/wine/obj_base.h?

by Jeff Smith

>From: Ove Kaaven <ovehk(a)ping.uio.no> >On 6 Dec 2002, Alexandre Julliard wrote: > > > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > > > 4) make widl not use macros at all, but emit full C and C++ >definitions > > > directly (this is what midl.exe does, it seems) > > > > I'd say this is the way to go if it's not too painful, it seems to be > > the most flexible. In any case obj_base.h has to go, so if we keep the > > macros they have to be put inside one of the standard headers, which > > wouldn't be very clean. > >We may have to keep the macros anyway, there are headers that use them >that can't be generated from IDL, like the DirectX headers. I suppose they >could be converted to using the MS-style objbase.h macros by perl scripts >or by rewriting them from api headers or something, but someone else would >have to take on that task, I think. > >But I'll try to add a widl header generation mode that don't use macros, >then. I don't really care whether the ICOM_ macros go or stay in the current form, but if they stay, they should at least be corrected in the following sense. Presently, a typical macro in obj_base.h is #define ICOM_METHOD4(ret,xfn,ta,na,tb,nb,tc,nc,td,nd) \ public: virtual ret CALLBACK (xfn)(ta a,tb b,tc c,td d) = 0; Note that we have na, nb, ... on the 'left' matching with a, b, ... on the 'right'. Not that this causes problems, it's just that it isn't right. And if the stuff gets stripped, it is a moot point anyway. If anyone thinks it is worth any effort, I can easily create a patch. -- Jeff S _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

Dec. 8, 2002

Re: wine/dlls Maketest.rules.in Makedll.rules.in

by Alexandre Julliard

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > this patch is broken when building from a clean tree: > - when building the tests for ntdll we need to link to kernel32 (for a > cui program) which isn't built at this time > - IMO, building the tests programs at the same time as the modules is a > bad idea. we don't impose that tests for DLL x only depends on DLL x and > DLLs built (in the wine dependency order) before x. > - so, either we back up to the previous mode, or we add dependencies on > test building as well Actually all of that should be fixed by the import libraries, I just forgot I haven't committed that stuff yet... -- Alexandre Julliard julliard(a)winehq.com

Dec. 7, 2002

Re: tools/wrc/wrc.c portability breakage

by Gerald Pfeifer

On Sat, 7 Dec 2002, Dimitrie O. Paun wrote: > Nevertheless, I will fix this for you. Thanks a lot! > But I would like to note that an actual patch to fix this problem from > the people that care about it would help a lot more than complaining > about it. Usually I'd do that (and I've done it a couple of dozen times in the past); just this week it's not feasible for me, so I took the second best route. ;-) Thanks again, Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

Dec. 7, 2002

Question about STRICT

by Vincent Béron

I was compiling the tests on MSVC (hence my patch), and the gdi32test wouldn't compile with the Wine headers (but would with MSVC's). The problem can be traced back to the absence of STRICT in windef.h. With the closure of bug #90 (compilation with -DSTRICT), I think it would make sense to define it in a header (windef.h seems logical), with an ifdef NO_STRICT provision (see the attached proposed patch). This would allow to remove all -DSTRICT on compilation command lines. I await your comments on it. Vincent --- wine-20021206-1700/include/windef.h 2002-10-23 20:47:38.000000000 -0400 +++ wine-20021206-1700/include/windef.h 2002-12-07 16:34:02.000000000 -0500 @@ -28,6 +28,12 @@ #ifndef WINVER #define WINVER 0x0500 #endif + +#ifndef NO_STRICT +#ifndef STRICT +#define STRICT +#endif /* STRICT */ +#endif /* NO_STRICT */ #include "winnt.h"

Dec. 7, 2002

Re: Failure running 1998-era online manual

by Eric Pouech

Eric Pouech a écrit : > > > It sounds like mmioOpen's documentation at > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/m… > > is incomplete; it doesn't describe what the function does when > > there's no filename, just a +init, in the string passed to mmioOpen. > > I tried patching the source for MMIO_ParseExtA to assume an extension of "" > > in this case, but it didn't help, the program still exits. > I'll try to look at it. (it may not even be mmio related) this ain't mmio related... the trace you posted is from running edoc32 without arguments if you pass TOSHIBA.M14 as an argument, all loading works fine and as you reported - a first splash screen is displayed - a second screen is then displayed, and then exits from the traces before the apps closes it windows, we have: - a failure to load a key: SOFTWARE\\Modern Age Books\\Books\\203-1 as the install process didn't to an end on my box, that's may be the cause (you can check if you have it on your windows install) - a dialog box (about the license) cannot be opened if you add this to system.reg [Software\\Modern Age Books\\Books\\203-1] 1039280652 "License Accepted"="1" the first issue is solved (and doesn't trigger the second one) I won't have time to look at the second issue (sounds like it doesn't find some dialog ressource, may be it's part of the aborted installation process) HTH A+

Dec. 7, 2002

Language search order

by Shachar Shemesh

From dlls/kernel/locale.c if (GetEnvironmentVariableA( "LC_ALL", buf, sizeof(buf) ) || GetEnvironmentVariableA( "*LC_CTYPE*", buf, sizeof(buf) ) || GetEnvironmentVariableA( "LANGUAGE", buf, sizeof(buf) ) || GetEnvironmentVariableA( "LC_MESSAGES", buf, sizeof(buf) ) || GetEnvironmentVariableA( "LANG", buf, sizeof(buf) )) Hi list, I'm trying to understand the above line of code. It would appear to me that default_lcid is used for "find resource". The manual for locale says: LC_CTYPE This changes the behaviour of the character handling and classi- fication functions, such as isupper() and toupper(), and the multi-byte character functions such as mblen() or wctomb(). Specifically, I'm looking into setting LC_CTYPE to "he_IL" so I can type Hebrew characters, while setting "LC_MESSAGE" to "C" so the messages programs issue are in English (or whatever their local setting says). It seems to me we may want to support independant settings of the two. I realize that there are places where we may want to use the information from LC_CTYPE (WideCharToMultiByte comes to mine), but I believe that we should use a different setting for that so we can allow Unix users independant control over both settings. Thoughts? Shachar

Dec. 7, 2002

Re: Loading Autorun.inf on CD's

by Tony Lambregts

Dustin Navea wrote: >From: "Sylvain Petreolle" <spetreolle(a)yahoo.fr> > > >>Doesnt exist that already ? >>http://freshmeat.net/projects/autorun/ >>http://parzelle.de/Linux/Applications/kautorun >> >> >Question is, does it work with wine? If so, how? I must be blind because I >dont see any documentation on how to set it up to load wine when it calls an >exe. Plus the method I was speaking about above includes loading up a .inf >file, not just autorun.exe... > > > I have not seen this work either and definitely not with an .inf. Yes it would be cool and if you want to start a bug concerning it feel free. I am not that worried about it though. The way I see it is that most of this is not realy a wine problem but rather with setting up autorun so that it is able to understand what to do with an .inf file. I suppose another way to look at it might be that wcmd could/should be able to handle something like "wcmd autorun.inf". -- Tony Lambregts

Dec. 7, 2002

Re: tools/wrc/wrc.c portability breakage

by Dimitrie O. Paun

On December 7, 2002 11:12 am, Gerald Pfeifer wrote: > It's the other way around: Not *BSD needs a special treatment, but > getopt_long() only exists on GNU systems (it depends on GNU, not the > Linux kernel), nowhere else. It's all a matter of perspective: if you count by the percentage of system types that have getopt_long, you are correct, but if you count by the number of installed systems the situation is reversed. Nevertheless, I will fix this for you. But I would like to note that an actual patch to fix this problem from the people that care about it would help a lot more than complaining about it. The fix is fairly simple (implement getopt_long in port.[hc], either by degrading to getopt, or by copying the getopt_long implementation from glibc, which now has a compatible license), and it's so much easier to test its correction on the actual problematic system. -- Dimi.

Dec. 7, 2002

Re: tools/wrc/wrc.c portability breakage

by Gerald Pfeifer

On Sat, 7 Dec 2002, Dimitrie O. Paun wrote: >> 2) getopt_long() is non-portable (and does not exist on FreeBSD, for >> example). > Sorry, but I don't have *BSD, and I have no idea how you parse long > options on BSD. If you tell me, I'd be happy to oblige. It's the other way around: Not *BSD needs a special treatment, but getopt_long() only exists on GNU systems (it depends on GNU, not the Linux kernel), nowhere else. A short time fix would be to 1) detect the presence of the getopt.h header using autoconf and only #include that header if it exists, and 2) use getopt_long() only in this case and just use getopt(), else. (Yes, this reduces functionality on non-GNU systems, but basically it they still will work.) Alternately, the getopt package needs to become a part of Wine, i.e., imported into Wine CVS. Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

Dec. 7, 2002

Re: tools/wrc/wrc.c portability breakage

by Dimitrie O. Paun

On December 7, 2002 05:48 am, Gerald Pfeifer wrote: > 2) getopt_long() is non-portable (and does not exist on FreeBSD, for > example). Sorry, but I don't have *BSD, and I have no idea how you parse long options on BSD. If you tell me, I'd be happy to oblige. -- Dimi.

Dec. 7, 2002

Re: wine/dlls Maketest.rules.in Makedll.rules.in

by Eric Pouech

Alexandre Julliard a écrit : > > ChangeSet ID: 6522 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2002/12/06 13:51:20 > > Modified files: > dlls : Maketest.rules.in Makedll.rules.in > > Log message: > Build test programs as part of the normal build. > > Patch: http://cvs.winehq.com/patch.py?id=6522 Alexandre, this patch is broken when building from a clean tree: - when building the tests for ntdll we need to link to kernel32 (for a cui program) which isn't built at this time - IMO, building the tests programs at the same time as the modules is a bad idea. we don't impose that tests for DLL x only depends on DLL x and DLLs built (in the wine dependency order) before x. - so, either we back up to the previous mode, or we add dependencies on test building as well A+

Dec. 7, 2002

Re: Unicode question

by Shachar Shemesh

Rolf Kalbermatter wrote: >Hello, > >In trying to get shell32 a little bit more Unicodified I came across this >function ParseFieldA which is taken from shellord.c. I'm quite unfamiliar >with Unicode so I still have to learn a lot. > >I have finally found most of the string manipulation functions which work >for Unicode but when it comes down to simple character comparison I'm a >little bit in the dark here. > >Some code snippets elsewhere in wine make me believe that for the english >charset WCHAR == char is actually mostly true. However I wonder if this >can be relied on in code. For instance the Unicode version of ParseField >would in that case look like this but I really want the opinion of someone >else on, if the code > >if (*src++ == ',') nField--; > >is actually working as expected on all systems independent of the actually >used charsets for the local languages. > It's ok to compare a WCHAR with a known char ('A'), but not two WCHARS together. Explanation - We (as well as Windows) use UTF-16 (UCS-2?) to represent characters. Most common Unicode characters in Europe, Africa, America, Australia and the middle east fit nicely into this area, and there are no problems. Eastern Asia, and some other characters, however, don't. The characters that don't fit in are represented using Surrogates - i.e. - each character takes two WCHARS to represent. The Unicode standard has been very wise in selecting the surrogates, however. Both first and second WCHARs of any given surrogate are taken from a range that is not allocated for any other character of Unicode. This means that if you are looking for a Hebrew "Aleph", scanning with a piece of code that looks something like: while (*str++ != 0x5d0) is guaranteed not to match anything except "Aleph". This means that if it's a specific character you are looking for, and you know it's not a surrogate, your code will work. However! If you are trying to look for an occurance of one character inside a string, and neither string nor character are known to you at the time of writing the code, this technique may fail miserably. The reason is that if the character you are looking for is a surrogate, both first and second WCHARs may appear, seperately, in other chars (all surrogates themselves, but still). Bear that in mind, and everything will be ok. Shachar

Dec. 7, 2002

tools/wrc/wrc.c portability breakage

by Gerald Pfeifer

The following patch broke portability of tools/wrc/wrc.c: revision 1.18 date: 2002/12/06 19:49:36; author: julliard; state: Exp; lines: +78 -10 Dimitrie O. Paun <dpaun(a)rogers.com> Make wrc command line compatible with windres. 1) getopt() is supposed to to come from <unistd.h>, and <getopt.h> is a non-standard header. 2) getopt_long() is non-portable (and does not exist on FreeBSD, for example). The man page for getopt() clearly shows that, BTW: #define _GNU_SOURCE #include <getopt.h> Would you mind fixing this problem? Thanks, Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

Dec. 7, 2002

Re: Let --disable-debug actually do something

by Eric Pouech

> > A possible fix is to hack configure to pass the flags on the compiler > > command-line; another is to remove the configure option completely > > and just tell people who really want it to do something like: > > > > make clean > > make all EXTRADEFS=-DNO_DEBUG_MSGS > > Unfortunately, I've seen packagers use it. Gentoo, for example, uses > it. And I could see the logic: why would joe user want all these > gibberish messages dumping onto the console while he's trying to work? > > So, eliminating this from configure might be a good call IMHO, at least > until we get it working. > > Perhaps the wrapper scripts should control where the debugging output > goes. I.E.: we could support (1) the usual stuff (2) appending debug > output to a log file or (3) appending debug output to /dev/null, > without messing with DNO_DEBUG_MSGS.... at some point, I was also thinking of: - implementing the wine debug messages with the OpenEventLog/ReportEvent/EVENTLOGRECORD... API (using some specific wine channels) - implement those APIs with various log files capabilities (either redirecting to stderr as we do now, or to some files in /var/log/wine/, or /dev/null...) but this would impact the performance of our logging, especially relay logging :-(, no I never actually tried to do it A+

Dec. 7, 2002

Re: Where to use dosdev

by Eric Pouech

György 'Nog' Jeney a écrit : > > >>Should we also use the functions in the devices.c to > >> implement all functions on devices like ioctls etc.? > > for the other int21 (disk read/write for instance), yes ioctl are the > > way to go > > I don't quite understand your english here, please excuse my French ;-) > are you saying that ioctls in > int21 _should_ be implemented using functions from devices.c (like > DOSDEV_IoctlRead/DOSDEV_IoctlWrite)? I was referring to DeviceIoControl calls (if you really want to only use exported functions from kernel in order to implement int 21h and device related traps) A+

Dec. 7, 2002

Re: small updates to debugger.sgml

by Eric Pouech

> How is this instead then? fine with me A+

Dec. 7, 2002

Re: Some fixes in capabilities

by Eric Pouech

> My appologies. (I am a VERY thick at times) I think most of my problems > with this is that I am/was doing it (The Wrong Way) (C) OK. I think I > should clarify since I brought it up There are two ways of getting > extraneous messages from winedbg in the log. > > 1). Starting winedbg with --debugmsg +(any channel you want a trace of) > ie: +loaddll > > 2). Any fixme message will get into the log regardless of whether it is > generated trough the app or winedbg. I would assume this also applies to > err and warn as well but I have not tested them this would apply to fixme and err which are turned on by default warn and trace are off by default > I think that now that I know about these two conditions (and avoid them) > I should be able to get a good clean log. the point 2/ is complely intented and should be kept as such regarding point 1/, what you can do is: - start your proces with wine foo --debugmsg +blabla - start winedbg - in winedbg, attach to the running process (using 'walk proc' to get the process id and 'attach pid') A+

Dec. 7, 2002

Re: Regression in wineconsole

by Eric Pouech

> So I don't really know for sure what fixed it. I could find > out for sure if you want <shrug> that's ok if it's fixed A+

Dec. 7, 2002

Re: [RFC] winewrap (2nd try)

by Dimitrie O. Paun

On December 6, 2002 03:12 pm, Alexandre Julliard wrote: > That would be a possibility, but you'd need some restructuring of > winebuild to do that (or have it exec itself which doesn't seem very > clean). I don't know, it feels cleaner to have a separate wrapper; Unfortunately, this doesn't work as nicely as a separate script, as I have to segragate the object files from resource files again, to pass only proper object files to gcc for linking. In the current script I have added a hack (assume files with .res in the name are resource files) to get around this problem, and be able to test the script out. I have tested this script with putty, and it works beautifully. At this point I still think it's better we integrate it into winebuild. Appart from the .res/.o detection, it avoids having to duplicate -m gui|cui handling, among other things. Comments welcomed, as usual. /* * Wine wrapper: takes care of internal details for linking. * * Copyright 2002 Dimitrie O. Paun * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include "config.h" #include "wine/port.h" #include <stdio.h> #include <string.h> #include <stdarg.h> #include <stdlib.h> #include <sys/wait.h> #include <sys/stat.h> #ifdef HAVE_UNISTD_H # include <unistd.h> #endif #ifndef WINEDLLS #define WINEDLLS "/usr/local/lib/wine" #endif static const char *app_loader_script = "#!/bin/sh\n" "\n" "appname=\"%s\"\n" "# determine the application directory\n" "appdir=''\n" "case \"$0\" in\n" " */*)\n" " # $0 contains a path, use it\n" " appdir=`dirname \"$0\"`\n" " ;;\n" " *)\n" " # no directory in $0, search in PATH\n" " saved_ifs=$IFS\n" " IFS=:\n" " for d in $PATH\n" " do\n" " IFS=$saved_ifs\n" " if [ -x \"$d/$appname\" ]; then appdir=\"$d\"; break; fi\n" " done\n" " ;;\n" "esac\n" "\n" "# figure out the full app path\n" "if [ -n \"$appdir\" ]; then\n" " apppath=\"$appdir/$appname.exe.so\"\n" "else\n" " apppath=\"$appname.exe.so\"\n" "fi\n" "\n" "# determine the WINELOADER\n" "if ! [ -x \"$WINELOADER\" ]; then WINELOADER=\"wine\"; fi\n" "\n" "# and try to start the app\n" "exec \"$WINELOADER\" \"$apppath\" \"$@\"\n" ; static char *output_name; static char **lib_files, **obj_files; static int nb_lib_files, nb_obj_files; static int debug = 1; void error(const char *s, ...) { va_list ap; va_start(ap, s); fprintf(stderr, "Error: "); vfprintf(stderr, s, ap); fprintf(stderr, "\n"); va_end(ap); exit(2); } char *strmake(const char *fmt, ...) { int n, size = 100; char *p; va_list ap; if ((p = malloc (size)) == NULL) return NULL; while (1) { va_start(ap, fmt); n = vsnprintf (p, size, fmt, ap); va_end(ap); if (n > -1 && n < size) return p; if (n > -1) size *= 2; if ((p = realloc (p, size)) == NULL) return NULL; } } void spawn(char *const argv[]) { int pid, status, i; if (debug) { for(i = 0; argv[i]; i++) printf("%s ", argv[i]); printf("\n"); } if ((pid = fork()) == 0) execvp(argv[0], argv); else if (wait(&status) > 0) { if (WEXITSTATUS(status) == 0) return; else error("%s failed.", argv[0]); } perror(0); exit(1); } int main(int argc, char **argv) { char *library = 0, *p; int i, j, no_opt = 0; char *spec_name, *spec_c_name, *spec_o_name; char **spec_args, **comp_args, **link_args; FILE *file; for (i = 1; i < argc; i++) { if (!no_opt && argv[i][0] == '-') { switch (argv[i][1]) { case 'o': if (argv[i][2]) output_name = strdup(argv[i]+ 2); else if (i + 1 < argc) output_name = strdup(argv[++i]); else error("The -o switch takes an argument."); if ( !(p = strstr(output_name, ".exe")) || *(p+4) ) output_name = strmake("%s.exe", output_name); break; case 'l': if (argv[i][2]) library = argv[i]+ 2; else if (i + 1 < argc) library = argv[++i]; else error("The -l switch takes an argument\n."); if (strcmp(library, "winspool") == 0) library = "winspool.drv"; lib_files = realloc( lib_files, (nb_lib_files+1) * sizeof(*lib_files) ); lib_files[nb_lib_files++] = strdup(library); break; case '-': if (argv[i][2]) error("No long option supported."); no_opt = 1; break; default: error("Unknown option -%c\n", argv[i][1]); } continue; } /* it's a filename, add it to its list */ obj_files = realloc( obj_files, (nb_obj_files+1) * sizeof(*obj_files) ); obj_files[nb_obj_files++] = strdup(argv[i]); } spec_name = tempnam(0, 0); spec_c_name = strmake("%s.c", spec_name); spec_o_name = strmake("%s.o", spec_name); /* build winebuild's argument list */ spec_args = malloc( (nb_lib_files + nb_obj_files + 20) * sizeof (char *) ); j = 0; spec_args[j++] = "winebuild"; spec_args[j++] = "-fPIC"; spec_args[j++] = "-o"; spec_args[j++] = strmake("%s.c", spec_name); spec_args[j++] = "--exe"; spec_args[j++] = output_name; spec_args[j++] = "-m"; spec_args[j++] = "gui"; for (i = 0; i < nb_obj_files; i++) spec_args[j++] = obj_files[i]; spec_args[j++] = "-L" WINEDLLS; for (i = 0; i < nb_lib_files; i++) spec_args[j++] = strmake("-l%s", lib_files[i]); spec_args[j++] = "-lmsvcrt"; spec_args[j] = 0; /* build gcc's argument list */ comp_args = malloc (20 * sizeof (char *) ); j = 0; comp_args[j++] = "gcc"; comp_args[j++] = "-fPIC"; comp_args[j++] = "-o"; comp_args[j++] = spec_o_name; comp_args[j++] = "-c"; comp_args[j++] = spec_c_name; /* build ld's argument list */ link_args = malloc( (nb_obj_files + 20) * sizeof (char *) ); j = 0; link_args[j++] = "gcc"; link_args[j++] = "-shared"; link_args[j++] = "-Wl,-Bsymbolic"; link_args[j++] = "-lwine"; link_args[j++] = "-lm"; link_args[j++] = "-o"; link_args[j++] = strmake("%s.so", output_name); link_args[j++] = spec_o_name; for (i = 0; i < nb_obj_files; i++) if (!strstr(obj_files[i], ".res")) link_args[j++] = obj_files[i]; link_args[j] = 0; /* run winebuild to get the .spec.c file */ spawn(spec_args); /* compile the .spec.c file */ spawn(comp_args); unlink(spec_c_name); /* run gcc to link */ spawn(link_args); unlink(spec_o_name); /* create the loader script */ output_name[strlen(output_name) - 4] = 0; /* remove the .exe extension */ if ( !(file = fopen(output_name, "w")) ) error ("Can not create %s.", output_name); fprintf(file, app_loader_script, output_name); fclose(file); chmod(output_name, S_IXUSR | S_IXGRP | S_IXOTH); return 0; } -- Dimi.

Dec. 7, 2002

Janitorial Projects -- conformance tests --recruiting volunteers

by Tom Wickline

We still need Win-95, Win-98SE, WinME, WinXP testers if anyone would like to Volinteer :)) If your new here and would like to help out this is a great way to get started.. You dont have to be a *programmer* And in the end your contribution will help out. I also think *someone* should make a list of all NON-PROGRAMING task that could be done by non programmers!!! And ask for Volunteers / Helpers There are many points of entry in any project.. We need to recruit Graphics Pro's to help this project as well !! Why ?? This would save the programmers alot of time... If others were doing these task. And they could do more important tasks. Just you $.02 Tom

Dec. 7, 2002

Re: Registering DLL's

by Jaco Greeff

On Sat, 7 Dec 2002 01:13:53 -0500, "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote : > Cool. Any other details other than "a bit further"? :))) > Like a ETA for a preview version, or something to be > integrated into the tree? *grin* I don't mind ETA's, it helps me focus. Second week in Jan 2003 for a preview and some serious feedback. I've only got about 4 days left before taking a bit of a break hence the longinsh delay. I've wanted to be quite a bit further along and have something out there by now, but this is problably better - it allows me to give serious attention to the feedback in Jan. Greetings, Jaco

Dec. 7, 2002

Re: small updates to debugger.sgml

by Tony Lambregts

Eric Pouech wrote: >>>Switch to UNIX shell, get the process-ID using ps -a | grep wine, and >>>do a kill -HUP <pid> (without the < and >). Wine will then enter its >>>internal debugger and you can proceed as explained above. Also, you >>>can use --debug switch and then you can get into internal debugger by >>>pressing Ctrl-C in the terminal where you run Wine. >>> >>> >the Ctrl-C should be working (if you did start the program under >winedbg) >A+ > > > > How is this instead then? Change Log: Update debugger documentation for when programs hangs. Files: debugger.sgml -- Tony Lambregts Index: debugger.sgml =================================================================== RCS file: /home/wine/wine/documentation/debugger.sgml,v retrieving revision 1.14 diff -u -r1.14 debugger.sgml --- debugger.sgml 30 Nov 2002 01:57:19 -0000 1.14 +++ debugger.sgml 7 Dec 2002 06:26:58 -0000 @@ -430,16 +430,12 @@ <title>Program hangs, nothing happens</title> <para> - <emphasis>Fix me - this is out of date </emphasis> - Switch to UNIX shell, get the process-ID using <command>ps -a | - grep wine</command>, and do a <command>kill -HUP - <pid></command> (without the < and >). Wine will - then enter its internal debugger and you can proceed as - explained above. Also, you can use - <parameter>--debug</parameter> switch and then you can get into - internal debugger by pressing - <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo> in - the terminal where you run Wine. + Start the program with <command>winedbg</command> instead of + <command>wine</command>. When the program locks up switch to the + winedbg terminal and press + <keycombo><keycap>Ctrl</keycap><keycap>C</keycap></keycombo>. this + will stop the program and let you debug the program as you would for + a crash. </para> </sect2> @@ -664,11 +660,11 @@ to get a listing of the functions the program calls in its start function. Now you do a <programlisting> -wine --debug winfile.exe +winedbg winfile.exe </programlisting> </para> <para> - This way, you get into <command>Wine-dbg</command>. Now you + This way, you get into <command>winedbg</command>. Now you can set a breakpoint on any function the program calls in the start function and just type <userinput>c</userinput> to bypass the eventual calls of Winfile to this function

Dec. 7, 2002

Re: [RFC] winewrap

by Dimitrie O. Paun

On December 6, 2002 03:12 pm, Alexandre Julliard wrote: > I don't know, it feels cleaner to have a separate wrapper; I'd > suggest doing at least the first version that way, and once things are > cleared up maybe we can find a way to merge everything into winebuild > cleanly. Yes, I agree it feels cleaner to keep it as a wrapper, but current practice points in the other direction. Nevertheless, I fully agree that it makes sense to have the first cut done separately, so we better understand what the problem is before we do anything else. That being said, if we do plan to to integrate it into winebuild, I think we should do it sooner, rather than later, even at the expense of small temporary ugliness (e.g. fork winebuild from itself) in winebuild. We are in Wine 0.9 mode right now, and we should try hard to stabilize the utilities, and the *process*. The importance of said stabilization can not be overstated, as a bunch of other things depend on it, such as documentation, and other scripts (such as winemaker). And these dependents have been historically a _lot_ slower to change than C code. But most importantly, if people start using Winelib, it's going to be very hard to change established process as everyone's build system depends on it. Anyway, I will try to finish winewrap in it's current form, and we can evaluate merging it into winebuild when I'm done. -- Dimi.

Dec. 7, 2002

Re: Registering DLL's

by Dimitrie O. Paun

On December 7, 2002 12:37 am, Jaco Greeff wrote: > It is a bit further that the last staus update, we will need to see how it > evolves as the configuration moves into the registry. Cool. Any other details other than "a bit further"? :))) Like a ETA for a preview version, or something to be integrated into the tree? Sorry for asking these things (I know people don't like ETAs in the free software world), but I think this is a cool development, and I'm quite excited by it. :) -- Dimi.

Dec. 7, 2002

Re: Registering DLL's

by Jaco Greeff

On Fri, 6 Dec 2002 10:32:45 -0500, "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote : > On December 6, 2002 10:18 am, you wrote: > > You guys have got the ReactOS regedit based on Wine Regedit although it is > > read only atm. If someone is still planning on adopting it, then that will > > solve this part of the problem. > > Jaco was working on a cool too, I don't know what the status of that is: It is a bit further that the last staus update, we will need to see how it evolves as the configuration moves into the registry. Greetings, Jaco

Dec. 6, 2002

Re: Where to use dosdev

by György 'Nog' Jeney

>>Should we also use the functions in the devices.c to >> implement all functions on devices like ioctls etc.? > for the other int21 (disk read/write for instance), yes ioctl are the > way to go I don't quite understand your english here, are you saying that ioctls in int21 _should_ be implemented using functions from devices.c (like DOSDEV_IoctlRead/DOSDEV_IoctlWrite)? nog.

Dec. 6, 2002

Latest wine cvs error

by Boris

I tried compiling the latest cvs and heres the error I get. make[2]: Leaving directory `/root/wine/tools/wrc' make[1]: Leaving directory `/root/wine/tools' make[1]: Entering directory `/root/wine/dlls' make[2]: Entering directory `/root/wine/dlls/ntdll' make[3]: Entering directory `/root/wine/dlls/ntdll/tests' LD_LIBRARY_PATH="../../../library:../../../unicode:$LD_LIBRARY_PATH" ../../../tools/winebuild/winebuild -fPIC -DSTRICT -DNONAMELESSUNION -DNONAMELESSSTRUCT -o ntdll_test.exe.spec.c -exe ntdll_test.exe -mcui error.o generated.o rtlbitmap.o rtlstr.o testlist.o -L../../../dlls -L.. -lntdll could not open .so file for kernel32.dll make[3]: *** [ntdll_test.exe.spec.c] Error 1 make[3]: Leaving directory `/root/wine/dlls/ntdll/tests' make[2]: *** [tests] Error 2 make[2]: Leaving directory `/root/wine/dlls/ntdll' make[1]: *** [ntdll] Error 2 make[1]: Leaving directory `/root/wine/dlls' make: *** [dlls] Error 2

Dec. 6, 2002

Re: Some fixes in capabilities

by Tony Lambregts

Eric Pouech wrote: >>While I am on the subject: as I mentioned in my other mail on this >>subject. Turning on gdi in winedbg (or any other channel/api that the >>debugger uses) will include calls from winedebug as well as the program >>I am debugging. This is an unhelpfull situation. >> >> >are you sure of this ? debug channels are only changed in the debugged >app, not in the debugger >aren't you looking at different threads ? > > > > My appologies. (I am a VERY thick at times) I think most of my problems with this is that I am/was doing it (The Wrong Way) (C) OK. I think I should clarify since I brought it up There are two ways of getting extraneous messages from winedbg in the log. 1). Starting winedbg with --debugmsg +(any channel you want a trace of) ie: +loaddll 2). Any fixme message will get into the log regardless of whether it is generated trough the app or winedbg. I would assume this also applies to err and warn as well but I have not tested them I think that now that I know about these two conditions (and avoid them) I should be able to get a good clean log. -- Tony Lambregts

Dec. 6, 2002

Re: Regression in wineconsole

by Tony Lambregts

Eric Pouech wrote: >>In the past (upto the middle of November) wineconsole was quite happy >>with "clean 10". Does anyone have a suggestion on what should I do. >> >> >does the font server use the old fonts ? or only the newest ones ? >the issue we have here is with freetype (or the wine interface) which >doesn't see fixed size fonts as fixed size fonts > >A+ > > > To start off this is not an issue for me any more. The patch that broke it for me was this one. http://www.winehq.com/hypermail/wine-cvs/2002/11/0136.html In the mean time it was either fixed by a later patch or something that I did. I.E., I did a "make clean" and reinstalled last night. Also there was a patch to xfont.c in the last couple of days if I recall corectlly. So I don't really know for sure what fixed it. I could find out for sure if you want <shrug> -- Tony Lambregts

Dec. 6, 2002

Re: Let --disable-debug actually do something

by Greg Turner

On Friday 06 December 2002 03:27 pm, Alexandre Julliard wrote: > "Medland, Bill" <Bill.Medland(a)accpac.com> writes: > > Oh. So how is setting --disable-debug supposed to result in the > > FIXMES being compiled out? I just don't understand what is > > supposed to be happening here; all I know is that it isn't working. > > (Or is that not what it is supposed to do?) > > It's what it's supposed to do, but it's clearly broken, and has been > for a very long time, basically because no one uses it. > > A possible fix is to hack configure to pass the flags on the compiler > command-line; another is to remove the configure option completely > and just tell people who really want it to do something like: > > make clean > make all EXTRADEFS=-DNO_DEBUG_MSGS Unfortunately, I've seen packagers use it. Gentoo, for example, uses it. And I could see the logic: why would joe user want all these gibberish messages dumping onto the console while he's trying to work? So, eliminating this from configure might be a good call IMHO, at least until we get it working. Perhaps the wrapper scripts should control where the debugging output goes. I.E.: we could support (1) the usual stuff (2) appending debug output to a log file or (3) appending debug output to /dev/null, without messing with DNO_DEBUG_MSGS.... just a thought, -- gmt

Dec. 6, 2002

Re: Fix the winmm/wave tests

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > * dlls/winmm/tests/wave.c > > Error handling in waveOutOpen works now (patch has been in CVs for a > couple of weeks) -> removing the todo_wine This doesn't work for me: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so wave.c && touch wave.ok err:wave:wodOpen Rate doesn't match (requested 2000000 Hz, got 48000 Hz) err:wave:wodOpen Rate doesn't match (requested 2000000 Hz, got 48000 Hz) wave.c:145: Test failed: opening the device at 2MHz should fail 0: rc=4 -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: Let --disable-debug actually do something

by Alexandre Julliard

"Medland, Bill" <Bill.Medland(a)accpac.com> writes: > Oh. So how is setting --disable-debug supposed to result in the FIXMES > being compiled out? I just don't understand what is supposed to be > happening here; all I know is that it isn't working. (Or is that not what > it is supposed to do?) It's what it's supposed to do, but it's clearly broken, and has been for a very long time, basically because no one uses it. A possible fix is to hack configure to pass the flags on the compiler command-line; another is to remove the configure option completely and just tell people who really want it to do something like: make clean make all EXTRADEFS=-DNO_DEBUG_MSGS -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: Cabinet FDICreate()

by Greg Turner

On Friday 06 December 2002 06:36 am, Patrik Stridvall wrote: > > The MSXML4 .msi package dies with : > > > > fixme:cabinet:FDICreate (0x525bee, 0x525bf3, 0x52668d, 0x525e99, > > 0x525bf8, 0x525fb9, 0x526042, -1, 0x54a2a8): stub > > > > Is this scheduled to be implemented as part of the cabinet merge in > > work? yes. > IIRC Greg Turner volunteer to do it however, also said I might take a > while before getting around to do it. indeed! > If not, install and use the native cabinet.dll instead. yes, this works like a charm. I'm looking into cabinet now. You are correct that, the fci.h and fdi.h functions ought to be relatively easy since we have the cabextract code gifted to us. The sticking point for me has been "Extract" which is undocumented, and used by the IE installers. I'm going to look at the .pdb symbols from XP in the hopes that they will give me a clue what the argument structure is... otherwise, I guess it's going to be trial and error or deducing the meaning from disassembly. Also, I will probably do the FDI and FCI functions last, and the "Extract" and "DeleteExtractedFiles" (or whatever it's called) first. The reason: this way I can be more confident that I have successfully ported the cabextract code to wine before I start changing the overall flow of the program and potentially create new, non-porting-related bugs. cabinet.dll may take some time, and I may multitask while I work on it by doing some RPCRT4 stuff, but it's basically at the top of my queue right now. Of course, that doesn't mean it still won't take forever :) -- gmt

Dec. 6, 2002

RE: Let --disable-debug actually do something

by Medland, Bill

-----Original Message----- > From: wine-devel-admin(a)winehq.com > [mailto:wine-devel-admin(a)winehq.com]On > Behalf Of Alexandre Julliard > Sent: Friday, December 06, 2002 12:53 PM > To: Medland, Bill > Cc: wine-devel(a)winehq.com > Subject: Re: Let --disable-debug actually do something > > > "Medland, Bill" <Bill.Medland(a)accpac.com> writes: > > > --- wine/include/wine/debug.h 5 Jul 2002 21:22:09 > -0000 1.5 > > +++ wine/include/wine/debug.h 4 Dec 2002 04:52:22 -0000 > > @@ -23,6 +23,7 @@ > > > > #include <stdarg.h> > > #include "windef.h" > > +#include "config.h" > > You can't do that, installed includes shouldn't depend on config.h. And why is the header that defines FIXME an installed include anyway? > > -- > Alexandre Julliard > julliard(a)winehq.com > >

Dec. 6, 2002

re: Dll separation question

by Steven Edwards

--- Dan Kegel <dank(a)kegel.com> wrote: > Martin.Wilck(a)fujitsu-siemens.com wrote: > > when writing code for DLL X, which functions from other DLLs may I call? > > As a Wine outsider, let me make a wild guess: > > To a first approximation, a nice way of thinking about it might be > Write new DLLs using only published Microsoft APIs > already implemented in other Wine DLLs. > Ideally, new DLLs would work as replacements > if compiled and run on a real Windows box. > (although of course a whole lot of DLLs probably > can't meet that strict definition.) > > - Dan This is kind of what I work on when I have time for the ReactOS project. If a WINE dll works under Windows then as ReactOS is developed the same dll and API will be there for ReactOS. This doesnt always work for the lower level stuff like advapi, ntdll, kernel32 and others but the more higher level stuff is getting there. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Dec. 6, 2002

RE: Let --disable-debug actually do something

by Medland, Bill

> -----Original Message----- > From: Alexandre Julliard [mailto:julliard(a)winehq.com] > Sent: Friday, December 06, 2002 12:53 PM > To: Medland, Bill > Cc: wine-devel(a)winehq.com > Subject: Re: Let --disable-debug actually do something > > > "Medland, Bill" <Bill.Medland(a)accpac.com> writes: > > > --- wine/include/wine/debug.h 5 Jul 2002 21:22:09 > -0000 1.5 > > +++ wine/include/wine/debug.h 4 Dec 2002 04:52:22 -0000 > > @@ -23,6 +23,7 @@ > > > > #include <stdarg.h> > > #include "windef.h" > > +#include "config.h" > > You can't do that, installed includes shouldn't depend on config.h. Oh. So how is setting --disable-debug supposed to result in the FIXMES being compiled out? I just don't understand what is supposed to be happening here; all I know is that it isn't working. (Or is that not what it is supposed to do?) a) --disable-debug results in the settings in config.h changing. b) wine/debug.h tests that setting that becomes defined in config.h, in order to reduce FIXME to a basically null statement. c) dlls/user/hook.c, for example, includes a FIXME statement. neither hook.c nor debug.h include config.h so if I insert #ifndef NO_DEBUG_MSGS #error I was right #endif just before the fixme of NotifyWinEvent then it tells me I am right. I can only think of two ways that setting --disable-debug could be expected to result in the FIXMES being compiled out (which I presume is what is supposed to happen). Either it is supposed to result in a change to the makefiles so the -D NO_DEBUG_MSGS gets specified (and I see no indication of that) or else it results in a #define NO_DEBUG_MSGS at a suitable point that comes before it is actually needed (which appears to be the intention). So I presume that the problem is that config.h is not being included before its contents are needed. So the question is where should it be included. One solution would be to include it explicitly in every file that includes a WARN, FIXME or TRACE. Do you really want that? The other is to include it in the file that uses it (viz. debug.h). So tell me why I am an idiot and what solution you want me implement. I guess the simplest would be to drop --disable-debug from the configure. > > -- > Alexandre Julliard > julliard(a)winehq.com > Bill Medland

Dec. 6, 2002

RE: FW: shell32.SHDefExtractIcon implementation take

by Rolf Kalbermatter

Mmmh, at first sight I thought damn how could this happen but then looking at it I don't think there is a problem. I do not return the memory which was allocated on the stack, but the HICONS allocated and returned by PrivateExtractIconsW in the hIcons array! So this shouldn't be a problem at all or are my brain cells garbled that much already? Rolf Kalbermatter > -----Original Message----- > From: Uwe Bonnes [mailto:bon(a)elektron.ikp.physik.tu-darmstadt.de] > Sent: Friday, December 06, 2002 9:53 PM > To: wine-devel(a)winehq.com > Cc: rolf.kalbermatter(a)citeng.com > Subject: Re: FW: shell32.SHDefExtractIcon implementation take > > > > > >>>>> "Rolf" == Rolf Kalbermatter <rolf.kalbermatter(a)citeng.com> writes: > +/**************************************************************************** > + * SHDefExtractIconW [SHELL32.@] > + */ > +HRESULT SHDefExtractIconW(LPCWSTR pszIconFile, int iIndex, UINT uFlags, > + HICON* phiconLarge, HICON* phiconSmall, UINT nIconSize) > +{ > + UINT ret; > + HICON hIcons[2]; > ^^^^^^^^ > > + WARN("%s %d 0x%08x %p %p %d, semi-stub\n", debugstr_w(pszIconFile),\ > iIndex, uFlags, phiconLarge, phiconSmall, nIconSize); > + > + ret = PrivateExtractIconsW(pszIconFile, iIndex, nIconSize, > nIconSize, hIcons, NULL, 2, LR_DEFAULTCOLOR); > + /* FIXME: deal with uFlags parameter which contains GIL_ flags */ > + if (ret == 0xFFFFFFFF) > + return E_FAIL; > + if (ret > 0) { > + *phiconLarge = hIcons[0]; > ^^^^^^^^^^^^ > Rolf, > > this doesn't look right to me: > > You allocate space on the function local stack, then hand out a pointer to > that memory and return from the function. No the function local stack is > undefined and the pointers are dangling. I think the heap should be used for > allocating the needed storage. > > Bye > > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 6, 2002

Re: Let --disable-debug actually do something

by Alexandre Julliard

"Medland, Bill" <Bill.Medland(a)accpac.com> writes: > --- wine/include/wine/debug.h 5 Jul 2002 21:22:09 -0000 1.5 > +++ wine/include/wine/debug.h 4 Dec 2002 04:52:22 -0000 > @@ -23,6 +23,7 @@ > > #include <stdarg.h> > #include "windef.h" > +#include "config.h" You can't do that, installed includes shouldn't depend on config.h. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: FW: shell32.SHDefExtractIcon implementation take

by Uwe Bonnes

>>>>> "Rolf" == Rolf Kalbermatter <rolf.kalbermatter(a)citeng.com> writes: +/**************************************************************************** + * SHDefExtractIconW [SHELL32.@] + */ +HRESULT SHDefExtractIconW(LPCWSTR pszIconFile, int iIndex, UINT uFlags, + HICON* phiconLarge, HICON* phiconSmall, UINT nIconSize) +{ + UINT ret; + HICON hIcons[2]; ^^^^^^^^ + WARN("%s %d 0x%08x %p %p %d, semi-stub\n", debugstr_w(pszIconFile),\ iIndex, uFlags, phiconLarge, phiconSmall, nIconSize); + + ret = PrivateExtractIconsW(pszIconFile, iIndex, nIconSize, nIconSize, h\ Icons, NULL, 2, LR_DEFAULTCOLOR); + /* FIXME: deal with uFlags parameter which contains GIL_ flags */ + if (ret == 0xFFFFFFFF) + return E_FAIL; + if (ret > 0) { + *phiconLarge = hIcons[0]; ^^^^^^^^^^^^ Rolf, this doesn't look right to me: You allocate space on the function local stack, then hand out a pointer to that memory and return from the function. No the function local stack is undefined and the pointers are dangling. I think the heap should be used for allocating the needed storage. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Dec. 6, 2002

Re: [RESENT] Batch support for CreateProcess (2 of 3)

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > --- wine/programs/wcmd/builtins.c 24 Jul 2002 19:00:25 -0000 1.15 > +++ wine/programs/wcmd/builtins.c 6 Dec 2002 14:04:02 -0000 > @@ -406,7 +406,7 @@ > return; > } > if (test != negate) { > - WCMD_parameter (p, 2+negate, &s); > + WCMD_parameter (p, 2+negate+test, &s); This doesn't look right. The number of parameters doesn't depend on the result of the test. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: [RFC] winewrap

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Well, in this case, why not merge winewrap into winebuild, and > maybe provide flags to do only certain steps, sort of like gcc? > > In fact, winebuild already follows this philosophy, so it seems > only natural. And we can avoid yet another small wrapper. That would be a possibility, but you'd need some restructuring of winebuild to do that (or have it exec itself which doesn't seem very clean). I don't know, it feels cleaner to have a separate wrapper; I'd suggest doing at least the first version that way, and once things are cleared up maybe we can find a way to merge everything into winebuild cleanly. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: [RFC] winewrap

by Dimitrie O. Paun

On December 6, 2002 01:19 pm, Alexandre Julliard wrote: > The 32-bit ones do, so it would be possible to identify them. But > actually I could hack winebuild to do that itself, and then simply get > rid of the -r option. Well, in this case, why not merge winewrap into winebuild, and maybe provide flags to do only certain steps, sort of like gcc? In fact, winebuild already follows this philosophy, so it seems only natural. And we can avoid yet another small wrapper. -- Dimi.

Dec. 6, 2002

Re: what to do with include/wine/obj_base.h?

by Ove Kaaven

On 6 Dec 2002, Alexandre Julliard wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > 4) make widl not use macros at all, but emit full C and C++ definitions > > directly (this is what midl.exe does, it seems) > > I'd say this is the way to go if it's not too painful, it seems to be > the most flexible. In any case obj_base.h has to go, so if we keep the > macros they have to be put inside one of the standard headers, which > wouldn't be very clean. We may have to keep the macros anyway, there are headers that use them that can't be generated from IDL, like the DirectX headers. I suppose they could be converted to using the MS-style objbase.h macros by perl scripts or by rewriting them from api headers or something, but someone else would have to take on that task, I think. But I'll try to add a widl header generation mode that don't use macros, then.

Dec. 6, 2002

Re: [RFC] winewrap

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Nevermind that, now the question is: should I include the > script in winewrap? Otherwise, we have to install wineapploader, > and I don't quite see the point in that. We can have a --loader > option that allows you to use an external script if need be, > in which case we can maybe even simplify the generated script a bit. I think winewrap should be self-contained and not depend on an external script. The fact that we generate a script is just an implementation detail, at some point it may become an ELF binary so we don't want anybody to depend on that. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: Janitorial Projects

by Dimitrie O. Paun

On December 6, 2002 01:40 pm, Alexandre Julliard wrote: > Yes, the DDK ones should be installed I think. toolhelp.h probably > not, it's a 16-bit thing that Winelib apps are not supposed to use. OK, here it is: ChangeLog Install DDK headers as well. Index: include/Makefile.in =================================================================== RCS file: /var/cvs/wine/include/Makefile.in,v retrieving revision 1.68 diff -u -r1.68 Makefile.in --- include/Makefile.in 3 Dec 2002 23:36:05 -0000 1.68 +++ include/Makefile.in 6 Dec 2002 18:38:37 -0000 @@ -23,11 +23,13 @@ d3d8caps.h \ d3d8types.h \ d3dcaps.h \ + d3dhal.h \ d3dtypes.h \ d3dvec.inl \ dde.h \ ddeml.h \ ddraw.h \ + ddrawi.h \ digitalv.h \ dinput.h \ dispdib.h \ @@ -38,6 +40,7 @@ docobj.h \ dplay.h \ dplobby.h \ + dsdriver.h \ dshow.h \ dsound.h \ fci.h \ @@ -65,6 +68,7 @@ mediaerr.h \ mediaobj.h \ minmax.h \ + mmddk.h \ mmreg.h \ mmsystem.h \ msacm.h \ @@ -72,7 +76,11 @@ mssip.h \ mswsock.h \ nb30.h \ + netspi.h \ nspapi.h \ + ntddcdrm.h \ + ntddscsi.h \ + ntddstor.h \ ntsecapi.h \ ntstatus.h \ oaidl.h \ -- Dimi.

Dec. 6, 2002

Re: Janitorial Projects

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Thanks! Alexandre, shouldn't we install these as well? Yes, the DDK ones should be installed I think. toolhelp.h probably not, it's a 16-bit thing that Winelib apps are not supposed to use. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: Wine/FF7 midi help request

by Eric Pouech

> >fixme:winmm:MIDI_StreamOpen *lpuDeviceID=1 > >fixme:dsound:IDirectSoundImpl_SetCooperativeLevel > >(0x403ab930,0001003c,3):stub try changing in dlls/winmm/winmm.c lpwm->mld.uDeviceID = *lpuDeviceID = 0; into lpwm->mld.uDeviceID = *lpuDeviceID; and see what gives (the second fixme is harmless) A+

Dec. 6, 2002

Re: [RFC] winewrap

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Fair enough. But I would suggest we modify the script (as in the one > I sent) to allow the execution of the app out of _its_ build tree. > There isn't much point in requiring the app to be in the path, no? Sure, it should run from the build directory (though we should fall back to using the path if we don't find it there). Isn't that what the script already does? > Fine. What about the readelf hack? Should I open the file myself, > and check for the ELF signature. As far as I can say, the .res > files have no signature, right? The 32-bit ones do, so it would be possible to identify them. But actually I could hack winebuild to do that itself, and then simply get rid of the -r option. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: [RFC] winewrap

by Dimitrie O. Paun

On December 6, 2002 01:19 pm, Alexandre Julliard wrote: > Sure, it should run from the build directory (though we should fall > back to using the path if we don't find it there). Isn't that what the > script already does? I don't remember now, there was something I didn't like. :) Nevermind that, now the question is: should I include the script in winewrap? Otherwise, we have to install wineapploader, and I don't quite see the point in that. We can have a --loader option that allows you to use an external script if need be, in which case we can maybe even simplify the generated script a bit. > The 32-bit ones do, so it would be possible to identify them. But > actually I could hack winebuild to do that itself, and then simply get > rid of the -r option. I think this is a better option, and the reason is that it would allow people to more easily use winebuild directly, which is preferable because the generated files will be in sync with the Makefile targets (whereas with winewrap, we're generating files the Makefile doesn't know about). -- Dimi.

Dec. 6, 2002

Re: Janitorial Projects

by Eric Pouech

"Dimitrie O. Paun" a écrit : > > On December 6, 2002 12:33 pm, Eric Pouech wrote: > > on the wine only header side, some headers listed as wine only are in > > fact part of the DDK > > IMO, we should list them as such > > I don't have a SDK/DDK to check against, I've just generated the list > as the headers we do _not_ install. Help with this would be greatly > appreciated. those are (at least) the one I know d3dhal.h 3D direct draw driver interface ddrawi.h direct draw driver interface dsdriver.h direct sound driver interface mmddk.h winmm driver interface netspi.h network provider interface ntddcdrm.h kernel cd rom ioctls ntddscsi.h kernel scsi ioctls ntddstor.h kernel mass storage ioctls this one has been deprecated on NT (but is still valid on 9x) toolhelp.h

Dec. 6, 2002

Re: Janitorial Projects

by Dimitrie O. Paun

On December 6, 2002 01:11 pm, Eric Pouech wrote: > those are (at least) the one I know > d3dhal.h 3D direct draw driver interface > ddrawi.h direct draw driver interface > dsdriver.h direct sound driver interface > mmddk.h winmm driver interface > netspi.h network provider interface > ntddcdrm.h kernel cd rom ioctls > ntddscsi.h kernel scsi ioctls > ntddstor.h kernel mass storage ioctls > > this one has been deprecated on NT (but is still valid on 9x) > toolhelp.h Thanks! Alexandre, shouldn't we install these as well? If so, I can submit a patch, and take them off the list. -- Dimi.

Dec. 6, 2002

Re: Winedbg and gcc 3.2

by Eric Pouech

Alberto Massari a écrit : > > Hi everybody, > a few weeks ago I changed my build machine from a RedHat 7.2 + gcc 2.9x to > a Mandrake 9.0 + gcc 3.2, and I noticed that I was unable to debug the Wine > libraries (I got messages like "No debug information in ELF > '/usr/local/lib/wine/xxxx.dll.so'), while gdb worked just fine. this has already been discussed a month ago (or so) > My questions at this point are: > - is this behavior typical of every gcc 3.2? or it's only Mandrake that > does it? generic to 3.2 > - is somebody going to change the "configure" script to detect such a > situation and specify "-gstabs" instead of "-g"? (I would volunteer myself, > but I am not expert in this field... I just hacked my copy to make it work > in my tree) the "current fix" is to use CFLAGS=-gstabs configure > - or should winedbg be improved to understand more debug formats, so that > it can handle whatever informations the "-g" option spits out? no dwarfII support is planned for winedbg you can also use the dbg proxy in wine if you want to use dwarf debug format A+

Dec. 6, 2002

Re: [RFC] winewrap

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > Well, depends on what you call "work" :))) I've attached what I had > in mind for a generic wineapploader script. The problem I see with the symlink is that it's too fragile. As soon as you move/rename anything it breaks. Copying the script is already better, but I also think we should hardcode the app name instead of relying on $0, so that you can rename the script and it still works. > Also, should I delete the intermediate files? I think I should, > one can get to them by manually running winebuild. Yes, and you should use temp file names I think. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: [RFC] winewrap

by Dimitrie O. Paun

On December 6, 2002 12:51 pm, Alexandre Julliard wrote: > The problem I see with the symlink is that it's too fragile. As soon > as you move/rename anything it breaks. Copying the script is already > better, but I also think we should hardcode the app name instead of > relying on $0, so that you can rename the script and it still works. Fair enough. But I would suggest we modify the script (as in the one I sent) to allow the execution of the app out of _its_ build tree. There isn't much point in requiring the app to be in the path, no? Moreover, many Win32 apps don't even have an install target to their Makefiles, so running out of the build tree is the only option. > > Also, should I delete the intermediate files? I think I should, > > one can get to them by manually running winebuild. > > Yes, and you should use temp file names I think. Fine. What about the readelf hack? Should I open the file myself, and check for the ELF signature. As far as I can say, the .res files have no signature, right? -- Dimi.

Dec. 6, 2002

Re: Where to use dosdev

by Eric Pouech

György 'Nog' Jeney a écrit : > > In some of the int21 routines it says that we should use > DOSDEV_Peek/Read/Write. it seems to be related to console only functions in that case, you could use directly the console functions >Should we also use the functions in the devices.c to > implement all functions on devices like ioctls etc.? for the other int21 (disk read/write for instance), yes ioctl are the way to go A+

Dec. 6, 2002

Re: Failure running 1998-era online manual

by Eric Pouech

> It sounds like mmioOpen's documentation at > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/m… > is incomplete; it doesn't describe what the function does when > there's no filename, just a +init, in the string passed to mmioOpen. > I tried patching the source for MMIO_ParseExtA to assume an extension of "" > in this case, but it didn't help, the program still exits. I'll try to look at it. (it may not even be mmio related) A+

Dec. 6, 2002

Re: Janitorial Projects

by Dimitrie O. Paun

On December 6, 2002 12:33 pm, Eric Pouech wrote: > on the wine only header side, some headers listed as wine only are in > fact part of the DDK > IMO, we should list them as such I don't have a SDK/DDK to check against, I've just generated the list as the headers we do _not_ install. Help with this would be greatly appreciated. -- Dimi.

Dec. 6, 2002

Re: Janitorial Projects

by Eric Pouech

"Dimitrie O. Paun" a écrit : > > Folks, > > I have updated the Janitorial section: > http://www.dssd.ca/wine/Wine-Fun.html#janitorial on the wine only header side, some headers listed as wine only are in fact part of the DDK IMO, we should list them as such A+

Dec. 6, 2002

Re: small updates to debugger.sgml

by Eric Pouech

> > Switch to UNIX shell, get the process-ID using ps -a | grep wine, and > > do a kill -HUP <pid> (without the < and >). Wine will then enter its > > internal debugger and you can proceed as explained above. Also, you > > can use --debug switch and then you can get into internal debugger by > > pressing Ctrl-C in the terminal where you run Wine. the Ctrl-C should be working (if you did start the program under winedbg) A+

Dec. 6, 2002

Re: what to do with include/wine/obj_base.h?

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > 4) make widl not use macros at all, but emit full C and C++ definitions > directly (this is what midl.exe does, it seems) I'd say this is the way to go if it's not too painful, it seems to be the most flexible. In any case obj_base.h has to go, so if we keep the macros they have to be put inside one of the standard headers, which wouldn't be very clean. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: [RFC] winewrap

by Dimitrie O. Paun

On December 6, 2002 12:16 pm, Alexandre Julliard wrote: > I don't think a symlink would work. IMO it should be a self-contained > thing that you can move around, copy to other machines, etc. Well, depends on what you call "work" :))) I've attached what I had in mind for a generic wineapploader script. But regardless, you want to simply output the script, or generate an ELF executable? Also, should I delete the intermediate files? I think I should, one can get to them by manually running winebuild. -- Dimi. #!/bin/sh # # Wrapper script to start a Winelib application once it is installed # # Copyright (C) 2002 Alexandre Julliard # # This library is free software; you can redistribute it and/or # modify it under the terms of the GNU Lesser General Public # License as published by the Free Software Foundation; either # version 2.1 of the License, or (at your option) any later version. # # This library is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # Lesser General Public License for more details. # # You should have received a copy of the GNU Lesser General Public # License along with this library; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # # determine the app Winelib library name appname=`basename "$0" .exe`.exe # determine the application directory appdir="" case "$0" in */*) # $0 contains a path, use it appdir=`dirname "$0"` ;; *) # no directory in $0, search in PATH saved_ifs=$IFS IFS=: for d in $PATH do IFS=$saved_ifs if [ -x "$d/$0" ]; then appdir="$d"; break; fi done ;; esac # figure out the full app path if [ -n "$appdir" ]; then apppath="$appdir/$appname.so" else apppath="$appname" fi # first try explicit WINELOADER if [ -x "$WINELOADER" ]; then exec "$WINELOADER" "$apppath" "$@"; fi # then default bin directory if [ -x "/usr/local/bin/wine" ]; then exec "/usr/local/bin/wine" "$apppath" "$@"; fi # now try the directory containing $0 if [ -x "$appdir/wine" ]; then exec "$appdir/wine" "$apppath" "$@"; fi # finally look in PATH exec wine "$appname" "$@"

Dec. 6, 2002

Re: how to switch between threads

by Eric Pouech

> How dose debuggers handle MultiThreaded Applications? > Can i Shit to different Thread to exmine where is it > when the program Halted? when you've hit a bp, you can use bt 1234 to see the backtrace of thread 1234 (where 1234 is the thread id) a good way to know thread ids is to call walk proc and walk thread once the debugger is handling an exception (single step, breakpoint...), all threads of the process are stopped, so you can look at whatever you want however, there's no way (currently) to restart a specific thread (only). we're always in a all or nothing fashion A+

Dec. 6, 2002

Re: [RFC] winewrap

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > One possible option is to modify wineapploader so we > simply symlink to it. I have a version of this around. > Is this acceptable? I don't think a symlink would work. IMO it should be a self-contained thing that you can move around, copy to other machines, etc. -- Alexandre Julliard julliard(a)winehq.com

Dec. 6, 2002

Re: Some fixes in capabilities

by Eric Pouech

> While I am on the subject: as I mentioned in my other mail on this > subject. Turning on gdi in winedbg (or any other channel/api that the > debugger uses) will include calls from winedebug as well as the program > I am debugging. This is an unhelpfull situation. are you sure of this ? debug channels are only changed in the debugged app, not in the debugger aren't you looking at different threads ? A+

Dec. 6, 2002