wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Fw: Loading Autorun.inf on CD's
by Dustin Navea 09 Dec '02

09 Dec '02

----- 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

2 2

regression: msvc4.0 install dies sooner now
by Dan Kegel 09 Dec '02

09 Dec '02

I found an unopened copy of msvc++ 4.0 at a garage sale last year for $5, couldn't resist. Today I finally tried to install it under Wine. wine-20020605-2 (rh8): installer started; when I clicked on 'Install Visual C++', it put up a 'Installing... please wait' dialog, then failed with a 'Can't read version info from C:\windows\kernel386.drv' message (more or less), then hung. wine-20021125 (from source): installer started; when I clicked on 'Install Visual C++', it hung. Looks like a regression to me. Logs of --debugmsg +relay are up at http://www.kegel.com/msvc4setup-wine20020605.log.bz2 http://www.kegel.com/msvc4setup-wine20021125.log.bz2 The latter file is 28MB uncompressed, 512KB compressed. I'm now building the intermediate releases of wine to see if I can narrow down when the regression occurred. - Dan

4 6

Re: Fix my broken WM_MOUSEHOVER patch
by Dimitrie O. Paun 09 Dec '02

09 Dec '02

On December 9, 2002 11:26 am, Mike Hearn wrote: > Patch is relative to wine root, made with cvs diff, is this right? Yes, and no (it's not in the right format). Please read: http://www.winehq.org/development/#patches http://www.winehq.com/hypermail/wine-devel/2002/09/0127.html -- Dimi.

3 2

Problem with DOSFS_OpenDevice
by Gustavo Junior Alves 09 Dec '02

09 Dec '02

Hi All, I having problems with raw printing. I receive this message from trace: device open lpt1 not supported (yet) Looking the code, I do not found any support for parallel ports neither on server or dos_fs. I missed something or DOSFS_OpenDevice does not support parallel printers? Thanks for the help. Gustavo Junior Alves alves(a)coslinux.com.br

2 1

Re: wine/dlls/winsock socket.c
by Martin Wilck 09 Dec '02

09 Dec '02

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@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 2

RE: wpp
by Patrik Stridvall 09 Dec '02

09 Dec '02

> 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.

2 1

Winedbg and gcc 3.2
by Alberto Massari 09 Dec '02

09 Dec '02

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. So today I digged a little bit and I found that winedbg supports the "stabs" debug format, and looks for the ".stabs" segment in the binary. The copy of gcc 3.2 I have (gcc-3.2-1mdk) doesn't produce this segment unless I replace the -g option with -gstabs. My questions at this point are: - is this behavior typical of every gcc 3.2? or it's only Mandrake that does it? - 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) - or should winedbg be improved to understand more debug formats, so that it can handle whatever informations the "-g" option spits out? Thanks, Alberto P.S. Please don't flame me if I said something naive....

2 2

GDI RestoreDC()
by Mike Hearn 09 Dec '02

09 Dec '02

Hi all, I think I've traced the problem with the Adobe SVG plugin not reliably rendering: This is from a good run (when I use an svg file I know will render OK): 080746b8:Call kernel32.LOCAL_Free(0000019f,00001aca) ret=40948f6b 080746b8:Ret kernel32.LOCAL_Free() retval=00000000 ret=40948f6b trace:gdi:GDI_FreeObject (0x1aca): leave 1 080746b8:Ret gdi32.DeleteObject() retval=00000001 ret=5300a17c 080746b8:Call gdi32.BitBlt(000008a8,00000000,00000000,0000008c,0000008c,00000ba0,00000000,00000000,00cc0020) ret=5300a1ae As you can see, it appears to perform the BitBlt call correctly, those parameters look correct. Here is the same section from a bad run: 080746b8:Call kernel32.LOCAL_Free(0000019f,00001ac2) ret=40948f6b 080746b8:Ret kernel32.LOCAL_Free() retval=00000000 ret=40948f6b trace:gdi:GDI_FreeObject (0x1ac2): leave 1 080746b8:Ret gdi32.DeleteObject() retval=00000001 ret=5301b3df 080746b8:Call gdi32.RestoreDC(000008a8,ffffffff) ret=53018c68 It doesn't call BitBlt at all, not now, not later, not at all. Instead, it calls RestoreDC for no apparently good reason. That last argument looks highly suspicious, in that MSDN says it's an int which when positive identifies a state and when negative identifies a "step", ie -1 would restore the last state from the stack. I can't figure out what ffffffff would be as an int though :( Would it be negative or positive? Either way, is this an intelligent sort of value for the parameter to have? The MSDN docs are here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/devcon… I can't figure out why it would suddenly call RestoreDC and then seemingly go off on a tangent (the traces match up until that point), rather than do a BitBlt like it's supposed to. The SVG files vary only in that the "good" one has some interactivity (but it's not triggered at startup). Does anybody have any ideas? I'm fresh out for today. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 2

RE: wpp
by Patrik Stridvall 09 Dec '02

09 Dec '02

> 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.

1 0

Re: Janitorial Projects -- conformance tests --recruiting volunteers
by David Miller 09 Dec '02

09 Dec '02

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

1 0

RE: wpp
by Patrik Stridvall 09 Dec '02

09 Dec '02

> 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".

3 2

Re: Wine/FF7 midi help request
by Jeff Smith 08 Dec '02

08 Dec '02

>From: Robotech_Master <robotech(a)eyrie.org> > >On Tue Jun 11 2002 - 13:50:43 CDT Johan Gill wrote (as part of a >discussion about midi in WINE in which FF7 was mentioned): > > > Done. TiMidity++-2.12.0beta as alsa sequencer client requires no > > modification to wine at all, and the OSS emulation of ALSA makes the > > thing transparent to WINE. > >Can you, or someone, please let me know how to set up wine to use >this? I'm running Debian Linux; these are the versions of timidity >and wine that I have: > >ii timidity 2.11.2-1.3 Software-only MIDI sequencer. >ii wine 0.0.20021125-1 Windows Emulator (Binary Emulator) This is something I would not mind knowing myself. It's not too high a priority for me though as I have SoundFonts working on my SBLive now. >For sound, I'm using artsdsp 0.6.1 to emulate esd. I have a >Soundblaster live card. > >On the FF7 config program, it gives me the choices > > Wine OSS midi out (#0) - disabled > EMU10K1 midi This looks like what I would get from the OSS driver - emu10k1. The module name for the ALSA driver is snd-emu10k1. The choices I would expect from ALSA's OSS emulation would be something like: Emu10k1 MIDI 0-0 Emu10k1 Port 0 Emu10k1 Port 1 Emu10k1 Port 2 Emu10k1 Port 3 >Under "midi data" it gives me the choises > > General midi > Soundfont midi (Creative AWE32/AWE64) > Yamaha XG midi I would imagine this should stay on General midi unless you are *sure* it needs to be on another selection. >No matter what I try, in whatever combination, I get "Error opening >device" and the wine console says > >fixme:winmm:MIDI_StreamOpen *lpuDeviceID=1 >fixme:dsound:IDirectSoundImpl_SetCooperativeLevel >(0x403ab930,0001003c,3):stub > >Can someone help me out--or point me at somewhere else I can find >help? Try running it like this ... wine -debugmsg +winmm,+midi,+msacm program_name.exe ... and send the output. -- Jeff S _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

3 3

RE: wpp
by Patrik Stridvall 08 Dec '02

08 Dec '02

> 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.

2 1

Re: Intel 8x0 and ALSA sound driver
by Nikolay Stefanov 08 Dec '02

08 Dec '02

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

1 0

Loading Autorun.inf on CD's
by Dustin Navea 08 Dec '02

08 Dec '02

Hey guys, I was browsing through the forums on franksworld.net and noticed this post: http://www.frankscorner.org/wineforum/viewthread.php?tid=158 Now that got me thinking, wine doesnt have any method to check .inf files right now and load an installer if it finds one on a CD. I was wondering, what do you guys think it would take to get that supported? I know that we would probably have to associate .inf files with wine and/or have some sort of a wine cd detector that actively monitors cd's for autorun files, but what would need to be added to wine itself to parse an autorun file, so that we could create the loader later? -Dustin

3 5

Re: what to do with include/wine/obj_base.h?
by Jeff Smith 08 Dec '02

08 Dec '02

>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

2 1

Re: wine/dlls Maketest.rules.in Makedll.rules.in
by Eric Pouech 07 Dec '02

07 Dec '02

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+

2 1

tools/wrc/wrc.c portability breakage
by Gerald Pfeifer 07 Dec '02

07 Dec '02

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/

2 4

Failure running 1998-era online manual
by Dan Kegel 07 Dec '02

07 Dec '02

I grabbed Wine-20021125 and built it on my Red Hat 7.3 box. Its behavior installing http://enduser:enduser@bbs.toshiba.co.uk/file/area128/S22D95UM.ZIP (the Windows 95 version of the user manual for my 1998-era Toshiba laptop) seems much improved over May/June 2002 wine, cool! However, running the app does no better. To run the app, you do cd 'c/Program Files/DOC' wine edoc32.exe TOSHIBA.M14 On Windows, it works fine. On Wine, it displays a splash screen, then exits. Here's a partial log: 08074e50:Ret kernel32.lstrcpyA() retval=406d2dc0 ret=01643c25 08074e50:Call winmm.mmioInstallIOProcA(2034314d,01643b30,10010000) ret=01643c54 trace:mmio:MMIO_InstallIOProc (540291405, 0x1643b30, 10010000, 1) fixme:mmio:MMIO_InstallIOProc Global procedures not implemented ... 08074e50:Ret winmm.mmioInstallIOProcA() retval=01643b30 ret=01643c54 08074e50:Ret PE DLL (proc=0x1641030,module=0x1640000,type=1,res=0x1) retval=1 ... 08074e50:Starting process C:\Program Files\DOC\edoc32.exe (entryproc=0x41c9b0) ... 08074e50:Call winmm.mmioOpenA(406d2cfc "+init",00000000,00000000) ret=00405fd6 trace:mmio:MMIO_Open ('+init', (nil), 00000000, 1); 08074e50:Call ntdll.RtlAllocateHeap(40380000,00000008,0000005c) ret=40c3e59b 08074e50:Ret ntdll.RtlAllocateHeap() retval=403c42b8 ret=40c3e59b trace:mmio:MMIO_ParseExtA ("+init") err:mmio:MMIO_ParseExtA + but no . in szFileName: "+init" 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. Any suggestions? - Dan

2 2

Language search order
by Shachar Shemesh 07 Dec '02

07 Dec '02

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

1 0

Unicode question
by Rolf Kalbermatter 07 Dec '02

07 Dec '02

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. And has anyone a good idea what the semi-stub would mean for this function? Maybe that it should ignore commas in quoted strings? /************************************************************************* * ParseFieldW [internal] * * copies a field from a ',' delimited string * * first field is nField = 1 */ DWORD WINAPI ParseFieldW(LPCWSTR src, DWORD nField, LPWSTR dst, DWORD len) { WARN("(%s,0x%08lx,%p,%ld) semi-stub.\n", debugstr_w(src), nField, dst, len); if (!src || !src[0] || !dst || !len) return 0; /* skip n fields delimited by ',' */ while (nField > 1) { if (*src == 0x0) return FALSE; if (*src++ == ',') nField--; } /* copy part till the next ',' to dst */ while ( *src != 0x0 && *src != ',' && (len--)>0 ) *(dst++) = *(src++); /* finalize the string */ *dst = 0x0; return TRUE; } Rolf Kalbermatter

4 3

RE: Let --disable-debug actually do something
by Medland, Bill 07 Dec '02

07 Dec '02

> -----Original Message----- > From: Alexandre Julliard [mailto:julliard@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

4 3

Where to use dosdev
by György 'Nog' Jeney 07 Dec '02

07 Dec '02

In some of the int21 routines it says that we should use DOSDEV_Peek/Read/Write. Should we also use the functions in the devices.c to implement all functions on devices like ioctls etc.? nog.

2 3

small updates to debugger.sgml
by Tony Lambregts 07 Dec '02

07 Dec '02

Before I could feel right about adding "Advanced Debugging Techniques" to the documnetation I needed to update the documentation on the debugger. There is still one section that is out of date (that I am aware of). The section that I am refering to is as follows > Program hangs, nothing happens > > 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. > This is _wrong_ since neither work. I have added a fix me message in front of this since I am unable to come up with anything usefull to replace it. If anyone has a usefull suggestion I would appreciate it. Change log: Update the debugger documentation for current usage. Files: /documnetation/debugger.sgml -- Tony Lambregts Index: debugger.sgml =================================================================== RCS file: /home/wine/wine/documentation/debugger.sgml,v retrieving revision 1.13 diff -u -r1.13 debugger.sgml --- debugger.sgml 1 Oct 2002 18:13:09 -0000 1.13 +++ debugger.sgml 29 Nov 2002 06:08:53 -0000 @@ -271,8 +271,9 @@ <para> This file describes where to start debugging Wine. If at any point you get stuck and want to ask for help, please read the - file <filename>documentation/bugreports</filename> for - information on how to write useful bug reports. + <emphasis>How to Report A Bug</emphasis> section of the + <emphasis>Wine Users Guide</emphasis> for information on how to write + useful bug reports. </para> <sect2> @@ -311,8 +312,7 @@ <para> Steps to debug a crash. You may stop at any step, but please report the bug and provide as much of the information - gathered to the newsgroup or the relevant developer as - feasible. + gathered to the bug report as feasible. </para> <orderedlist> @@ -362,17 +362,26 @@ If you have found a misbehaving function, try to find out why it misbehaves. Find the function in the source code. Try to make sense of the arguments passed. Usually there is - a <function>TRACE(<channel>,"(...)\n");</function> at - the beginning of the function. Rerun wine with + a <function>WINE_DEFAULT_DEBUG_CHANNEL(<channel>);</function> + at the beginning of the file. Rerun wine with <parameter>-debugmsg +xyz,+relay</parameter> added to the commandline. </para> + <para> + Occasionally there are additional debug channels defined at the + begining of the file in the form. + <function>WINE_DECLARE_DEBUG_CHANNEL(<channel>);</function> + If so the offending fuction may also uses one of these alternate + channels. Look through the the function for + <function>TRACE_(<channel>)(" ... /n");</function> and add any + additional channels to the commandline. + </para> </listitem> <listitem> <para> Additional information on how to debug using the internal debugger can be found in - <filename>debugger/README</filename>. + <filename>programs/winedbg/README</filename>. </para> </listitem> <listitem> @@ -386,29 +395,25 @@ </listitem> <listitem> <para> - If even that isn't enough, add more debug output for - yourself into the functions you find relevant. See - <filename>documentation/debug-msgs</filename>. You might + If even that isn't enough, add more debug output for yourself + into the functions you find relevant. See The section on Debug + Logging in this guide for more information. You might also try to run the program in <command>gdb</command> instead of using the WINE-debugger. If you do that, use <parameter>handle SIGSEGV nostop noprint</parameter> to disable the handling of seg faults inside - <command>gdb</command> (needed for Win16). If you don't use - the <parameter>--desktop</parameter> or - <parameter>--managed</parameter> option, start the WINE - process with <parameter>--sync</parameter>, or chances are - good to get X into an unusable state. + <command>gdb</command> (needed for Win16). </para> </listitem> <listitem> <para> - You can also set a breakpoint for that function. Start wine - with the <parameter>--debug</parameter> option added to the - commandline. After loading the executable wine will enter - the internal debugger. Use <parameter>break - KERNEL_LSTRLEN</parameter> (replace by function you want - to debug, CASE IS RELEVANT) to set a breakpoint. Then use - <command>continue</command> to start normal + You can also set a breakpoint for that function. Start wine + useing <command>winedbg</command> instead of + <command>wine</command>. Once the debugger is is running enter + <command>break</command> <parameter>KERNEL_LSTRLEN</parameter> + (replace by function you want to debug, CASE IS RELEVANT) + to set a breakpoint. Then + use <command>continue</command> to start normal program-execution. Wine will stop if it reaches the breakpoint. If the program isn't yet at the crashing call of that function, use <command>continue</command> again @@ -425,6 +430,7 @@ <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 @@ -449,8 +455,7 @@ </para> <para> Since the failure happens usually directly before setting up - the Messagebox you can start wine with - <parameter>--debug</parameter> added to the commandline, set a + the Messagebox you can start winedbg and set a breakpoint at <function>MessageBoxA</function> (called by win16 and win32 programs) and proceed with <command>continue</command>. With <parameter>--debugmsg

2 3

Re: Some fixes in capabilities
by Andreas Mohr 07 Dec '02

07 Dec '02

On Tue, Nov 26, 2002 at 10:23:55PM +0100, Lionel Ulmer wrote: > Hi all, > > As long as we do not support multi-texturing in our D3D driver, fill the > caps properly. Now SS2 does not try to do multitexturing anymore (not that > it actually works now, it's just that it would break less :-) ). > > Note: is there a way from DLL X to activate relay debugging ? What happens > is that SS2 somehow freezes at one point and doing a relay trace from > the start is about a 3 GB file... So what I would like to do is at a > specific function in the D3D code that I know to be just before the > freeze, call 'activate relay' and voila, I have relaying on :-) (to be > able to do that for all DLLs would be even better). > > But well, considering DLL separation and all that, I doubt that this > would be possible :-/ Oh pleeeeze... I thought that at least the Wine developers are reading the wine docu properly... ;-) Let's see... first you use completely inacceptable words, and then you admit to never reading the docu... bad, bad, very bad guy. :) Read wine.man. It explains how to do relay logging for a single DLL. Although I'm afraid that this might actually be broken at the moment maybe :-\ -- "My attitude is, everybody should try competing with Microsoft once in their life. Once." - Marc Andreessen, former Netscape lead employee, in a "browser wars" interview

7 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel