- wine-devel - winehq.org

ODBC
by "Ludueña, Leonardo" 24 Apr '03

24 Apr '03

We have an application developed by our company, that application use a ODBC connection. I need to know if there previous experiencies with that kind of port. TIA

2 1

Re: PATCH: include/objidl.h
by Uwe Bonnes 24 Apr '03

24 Apr '03

>>>>> "Gerald" == Gerald Pfeifer <pfeifer(a)dbai.tuwien.ac.at> writes: Gerald> Modern compilers (such as the one shipped with SuSE Linux 8.2) Gerald> complain about this construct, which is quite useless anyway. Gerald> Gerald Gerald> ChangeLog: Remove useless DUMMYSTRUCTNAME from _userSTGMEDIUM. Gerald, either this is wrong for the other 30 occurances in ~/include, or more explanation is needed, why this is wrong here and not in the other places. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

I: Wine and SQl server.
by Carlo Pelini 24 Apr '03

24 Apr '03

> -----Messaggio originale----- > Da: Carlo Pelini > Inviato: giovedì 24 aprile 2003 17.42 > A: 'wine-users(a)Winehq.com' > Oggetto: Wine and SQl server. > > Hy. I am a computer science student, and I am studing wine for my degree > thesis. > I have succeded to run VisualFoxPro on wine and by VisualFoxPro i have > succeded to utilize the unixODBC and the ODBC windows. With the unixODBC I > have succeded to open a connession with a database SQL server, to execute > a interrogation and to visualize the result. > For to can to do there, I dont'have utilized directly the driver SQL > server, but I have utilzed easysoft ODBC-ODBC bridge > (http://www.easysoft.com/products/oob/main.phtml), a ODBCF driver, which > do precisely from bridge between the ODBC client and the ODBC server, and > allow the connession with a database SQL server. > Thank at there proceeding, I have succeded to run AD HOC REVOLUTION, a > managerial software, even if is slow. > Bye.

1 0

Server Crash
by Jeremy Newman 24 Apr '03

24 Apr '03

It's time for the annual server crash kids! Whee! Our server melted last night at about 3am or so after 2 days of solid high traffic (the load average was up over 100). I managed to get it up and running with some WD-40, Duct Tape, and some bubble gum. I can't guarantee uptime right now. I AM, however, scrambling to beef it up to handle the load. I apologize in advance for any further downtime. As you can imagine, with all this good press, I don't want the server do be down any longer than a few nanoseconds. If anyone has a quad processor Xeon they are not using, feel free to send it my way. :-D -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

1 0

WineHQ's CVS server performance..
by Lionel Ulmer 23 Apr '03

23 Apr '03

Hi all, Am I the only to find the current CVS performance abyssmal ? About 5 minutes for a CVS update and 10 for a CVS diff is not what I usually have on my connection... Let's hope it's Alexandre merging all the Crossover Office 2.0 patches <g>. Lionel -- Lionel Ulmer - http://www.bbrox.org/

3 2

CVS Character set (was: lostwages/templates/en documentation.template)
by Joerg Mayer 23 Apr '03

23 Apr '03

I'm noticing that during the last few weeks several mails have been sent to the cvs list that use 8-bit characters but do not specifiy an encoding in the mail header. Would it be possible to either add one (depends on whether cvs does recognize the encoding type) or remove those extra characters? On Tue, Apr 22, 2003 at 01:28:01PM -0500, Jeremy Newman wrote: > Log message: > ChangeLog > Â Â Â Dimitrie O. Paun <dpaun(a)rogers.com> > Â Â Â Remove references to no longer existing document. > > Patch: http://cvs.winehq.com/patch.py?id=7945 Thanks Jörg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

1 0

RE: FoxPro & Wine :)
by Patrik Stridvall 23 Apr '03

23 Apr '03

> On Wed, 23 Apr 2003, Patrik Stridvall wrote: > > > While, I suppose, you can have a license the regulates this to, even > > if the LGPL doesn't, the problem is the doctrine of first sale means > > anybody that it can be distributed to can resell (or give) that copy > > to anybody that can't be distributed directly to. > > And that is in no contradiction with the (L)GPL, as it does not > restrict to whom we can redistribute, but rather under what > conditions a derived work can be distributed. But that is exactly what I said above. Should I interpret it as you agree? But please note that the last step meantioned above is not distribution, it is sale (or gift) on an invidual copy allowed by first sale. And as I said earlier, it makes the conditions for redistribution is rather meaningless, since anybody regardless or willingless or abillity to follow the redistribution conditional can indirectly for all intent and purposed have distributed to anybody your work, while seperately distributing anything that uses, modififies, adapts etc your work for his purposes on the end users computer. The situation for the Microsoft Visual FoxPro (MVFP) runtime is almost identical since you analagous to above can for all intent and purpose have it distributed seperately. Summary: Microsoft released the MVFP runtime for all intent an purpose for free since they thought that charging for it would be bad for their purposes. Some people release some work under the LGPL because they thought charging for it would be bad for their purposes... Nobody can both have the cake and eat it. Microsoft can't, I can't, you can't... And futher more, again, Copyright law is designed that way on purpose, not by accident.

1 0

odd message
by Robert Lunnon 23 Apr '03

23 Apr '03

I am debugging a shareware game my kids often play called little fighter 2 (It deadlocks after creating the third thread) But before I get to the deadloack I noticed I get the following two messages from wine, err:module:BUILTIN_LoadModule loaded .so but dll wineaudioio.drv still not found err:module:BUILTIN_LoadModule loaded .so but dll joystick.drv still not found from what I can see wine is loading the two shared libraries ok and __wine_dll_register gets properly called EG Breakpoint 2, __wine_dll_register (header=0xdcb82480, filename=0xdcb721f6 "wineaudioio.drv") at loader.c:327 Yet find_dll_descr( dllname ) in builtin.c fails to find the name ?? Any hints would be appreciated

1 1

Re: oleaut32 patch
by Alexandre Julliard 23 Apr '03

23 Apr '03

Ove Kaaven <ovek(a)arcticnet.no> writes: > The oaidl_p.c is almost unmodified MIDL output generated from Wine's > oaidl.idl (I only had to add an #undef __WINE__ at the top to get all > the Winelib definitions, perhaps this isn't needed under Wine anymore), > so it shouldn't be hard to maintain, and Alexandre once said MIDL output > is acceptable as a stopgap solution. I don't know if proper > InstallShield repaint support calls for stopgaps, though. One problem is that this code causes hundreds of warnings, and I don't think that's acceptable (it also fails to link but that could be fixed by adding a few stubs). We could fix the warnings manually but that will cause obvious maintenance problems. How far are we from being able to generate that with widl? -- Alexandre Julliard julliard(a)winehq.com

3 3

Wintab32 dll devlopment
by Robert North 23 Apr '03

23 Apr '03

I have just posted a status update on my wintab32 development to the following wine bug. http://bugs.winehq.com/show_bug.cgi?id=1160 And following on from that update there are a number of questions I need answered to guide my further development: 1. Cross over office and tablets. I heard somewhere that Crossover office had a tablet implementation. Does anyone know about this, and who to contact to find out more? If they've got an implementation of wintab, I wonder if it's worth continuing the development. 2. When to post patches I could start producing patches quite soon. For instance, I could post patches when the WTInfo function is working. Or, I could wait till the whole system is working fully with at least one app? 3. Size of the patches. Is it better to break patches into small (valid compile, but non-functioning) chunks, or to release large functioning patches? 4. Config files Wintab will need some config data. I assume the best place to put this is in the ~/.wine/config file, within a registry key named "wintab"? 5. Development notes. I have some notes on the design that other developers will probably find useful. Where in the wine project should they go? There seems to be no place for rough notes. 6. x11drv integration. Currently the code is implemented to connect to X11 in a similar way to directX. No additional code is placed in the x11drv dll. This X11 connection should be discarded. To this end I have a number of functions that I'd like to place in x11drv dll. The question is: Should I put them into x11drv before releasing any patches, or maintain the directX style connection in the initial wine patches? 7. Cross-platform abilities Is there any need to think about allowing alternatives to XInput to plug into the wintab dll? Yeah, I know that's a lot of questions, But I hope you guys can give me some guidance. Bye -Rob.

4 4

Re: Winelib CoolPlayer port
by Dimitrie O. Paun 23 Apr '03

23 Apr '03

On April 22, 2003 04:17 pm, Vincent Béron wrote: > Next is the actual Winelib stuff, which is very small. Just a few lines indeed! > The first part is an MFC header (thankfully, nothing else seems to be > needed from MFC). This is the: --- CoolPlayerCVS-20030421-2130-orig/afxres.h 1969-12-31 19:00:00.000000000 -0500 +++ CoolPlayerCVS-20030421-2130/afxres.h 2003-04-21 21:51:07.000000000 -0400 @@ -0,0 +1 @@ +#include "winres.h" right? > The second part is the only problematic thing. The current div > implementation works fine for binary compatibility on i386, but doesn't > work well for source level compatibility on the same platform. I would prefer if we fix this one in Wine, so we don't have to submit this part for inclusion in the CoolPlayer code. This would be _our_ benefit for the port, no? :) -- Dimi.

1 0

Re: Fix trackbar size
by Dimitrie O. Paun 23 Apr '03

23 Apr '03

On April 22, 2003 05:55 pm, Maxime Bellengé wrote: > + * Copyright 2003 Maxime Belleng�<maxime.bellenge(a)laposte.net> > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -231,13 +232,13 @@ > channel->top = lpRect.top + offsetedge; > channel->bottom = lpRect.bottom - offsetedge; > channel->left = lpRect.left + offsetthumb; > - if (dwStyle & (TBS_BOTH | TBS_LEFT)) channel->left += 8; > + if (dwStyle & (TBS_BOTH | TBS_LEFT)) channel->left += > (lpRect.right-lpRect.left-offsetthumb-cyChannel)/2; Unfortunately, the patch seems to be wrapped, and your name did not show up properly in the copyright notice. -- Dimi.

1 0

Re: Fix Maskedit from Delphi - part 2 - Resend as attach to fix formatting
by Alexandre Julliard 23 Apr '03

23 Apr '03

Brad Campbell <brad(a)seme.com.au> writes: > EM_REPLACESTR was not respecting buffer_limit set > by EM_SETLIMITTEXT. Shouldn't the EDIT_MakeFit() call a few lines above already take care of that? Why doesn't it work? -- Alexandre Julliard julliard(a)winehq.com

2 1

RE: FoxPro & Wine :)
by Patrik Stridvall 22 Apr '03

22 Apr '03

> On Tue, 22 Apr 2003, Patrik Stridvall wrote: > > > EULAs tries to restrict, yes. However a copyright license > does as well, > > if it, like most copyleft licenses, tries to take back the rights > > you have already given up by allowing redistribution of the work > > in the first place. > > This is the source of the confusion. I don't take back anything, as > I don't allow limitless redistribution. Since you allow everybody that wants the work to legally get it for free, that is just meaningless game withs words. Even if not everybody can (re)distribute it, enough can to make it for all intent and purpose a meaningless distiction. See below. > I allow redistribution only > under certain condition. It's conditional: > A => B > You seem to think that one can not use conditionals. This is obviously > false. "You can do B IF condition A holds" is a very reasonable > statement. It's basic logic, no cake and no eating involved. [You don't really expect me to have missed something as trivial as that, do you?] The problem is that you with the LGPL only have conditionals on who can (re)distribute the work, but no conditional on whom it can be (re)distributed to. While, I suppose, you can have a license the regulates this to, even if the LGPL doesn't, the problem is the doctrine of first sale means anybody that it can be distributed to can resell (or give) that copy to anybody that can't be distributed directly to. Futhermore I would argue that first sale doctrine, for all intent and purpose, means that you as the copyright holder, can't regulate who ultimately a copy of your work, ends up with. So any such clause would be null and void, so no trickery would be needed. Note that copyright is designed that way on purpose, not as a freak accident. So now we are back to: 1. You can give your work away for free 2. You can sell your work for a fee But you can't control whom ultimately recieves and uses your work. So again: "You can't both have the cake and eat it"

3 2

RE: FoxPro & Wine :)
by Patrik Stridvall 22 Apr '03

22 Apr '03

> On Tue, 22 Apr 2003, Patrik Stridvall wrote: > > > Very, very simplified. You have basicly have two choices: > > 1. Distribute your work (or part of it) for free > > 2. Distribute your work (or part of it) for a fee. > > Says who? Says close to every business who uses copyright. Open sourse is not that large yet, you know. > Why would you think price is *the* fundamental feature? Because in the end there is really nothing else. If the work is useful to some extent, somebody will profit from directly or indirectly. Hopefully the author will as well... Futhermore, since if we are to have things like first sale, which we have, you really can't avoid that somebody converts each copy you have allowed the distribution of, to money. (Except by releasing more copies which will at least in theory drive the price to zero.) So unless you convert each copy you allow to distribute to money somebody else will. Note however this is not nessarily negative for you. Indirectly you might get more back that would have gotten through direct sale. > Copyright law gives you rights (by restricting other's rights) > so that you could use them, if you so desire, to get some money > for your work. Copyleft just says you give up some of your rights, > EULA restricts. Which is fine, but within limits -- it's much > harder (legally) to take from people than to give. EULAs tries to restrict, yes. However a copyright license does as well, if it, like most copyleft licenses, tries to take back the rights you have already given up by allowing redistribution of the work in the first place. That is what I mean by "trying to both have the cake and eat it". You have voluntary "eaten the cake" by allowing redistribution of the work and now you want it back... > As I said, why would we want to give the manufacturer of a TV set > the right to tell me what programs I'm allowed to watch on my TV? > Or what brand of gas to put in my car. Or what brand of detergent > in my washing machine? Agreed. However, your argument supports my position concerning LGPL, more than yours. > Having generally accepted interfaces (steering wheel, pedals, and > stick for a car, gas of certain octane, etc) is good because it > allows for multiple implementations == competition. But this works > as long as you can't restrict what *implementations* you're allowed > to use. Exactly, but again, it support my position more than yours. > I don't know my histroy right, but I believe this sort of > restrictions (among other things) allowed Rockefeller to build his > Standard Oil monopolistic empire, and is now illegal. IIRC the Standard Oil problem, was more a refusal to do business at all unless you cooperated more than anything else. Not really revelevent to this discussing. In the case above you have already done business by allowing redistribution ("eaten the cake") and later through legal wrangling wants to "have it" back.

2 1

Re: rpc exception
by Robert Shearman 22 Apr '03

22 Apr '03

> I see that Greg's exception stuff is not in Wine yet. Until that's > accepted, this'll have to do. [snip] This is just an idea, but would something like this work (obviously without Intel syntax): #define RpcExcept(expr) \ VOID * FuncPtr = GETEIP; \ if (__wine_in_exception_filter()) \ { \ int retval; \ switch( expr ) \ { \ case -1: \ retval = -1; \ break; \ case 0: \ retval = 0; \ break; \ case 1: \ retval = 1; \ break; \ } \ __asm \ { \ mov eax,retval \ ret 4 \ }; \ } \ __EXCEPT((__WINE_FILTER)FuncPtr) Rob

1 0

another wine apps database
by Dan Kegel 22 Apr '03

22 Apr '03

Anyone seen this one yet? http://thetechnozone.com/pcbuyersguide/software/system/TheWineList.html It seems good enough that perhaps there should be a link to it from http://www.winehq.com/?page=supported_applications We might want to nudge the author into disclosing the version number of the Wine he was using, so non-Knoppix users can compare versions. - Dan p.s. Here's its lead-in text: "The WINE List By Graeme Bennett Posted Aug. 6, 2002; updated Mar. 26, 2003 Introduction Wine (which, its authors say, stands for 'Wine is not an emulator') is a Windows-compatible application launching environment for Linux and several other non-Microsoft other operating systems in which users can run many programs designed for Windows. Since not every Windows program runs correctly under Wine, and many of the programs I tested successfully were not listed on the other Wine compatibility lists I found, I've put together this list of programs that work (or at least seem to work -- I didn't test every function of every program!) more or less as they do under Windows. For these tests, I used the Wine version built into Knoppix versions 3.1 and 3.2. Knoppix is a free Debian-based Linux distribution that requires no installation on or changes to your hard drive. It boots and runs its filesystem directly from a CD. Additionally, it write-protects your Windows hard drive(s) by default, making it an exceptionally safe way to test Wine and/or Linux. Zero Config Wine All programs tested were previously installed and no special setup, configuration or manual file copying under Wine was used. In other words, any program listed below works "as is." ..." -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 1

RE: FoxPro & Wine :)
by Patrik Stridvall 22 Apr '03

22 Apr '03

> > > And the question is: is this enforceable? > > > > And the answer is: if it isn't, neither is the (L)GPL. Why > would MS not > > be able to place restrictions on distribution of their own > copyrighted code? > > > > Not in the case of Microsoft. This should fall under the > sherman Anti-Trust Act. Probably true, but I would hate to use that argument in court, unless as the very last line of defence. > If I buy a copy > of MS Visual Studio and I have to redistribute files to > Windows 9x, NT, 2K, XP, Etc then I should > be able to also redistribute the same files to Linux or ReactOS. Also note that if you for example put it on a web site, you are not really redistributing to a special OS, in fact you are not really even redistributing to a special person or company, you are just redistributing it period....

1 0

Re: NTPL & pthreads locks
by Dan Kegel 22 Apr '03

22 Apr '03

Alexandre Julliard wrote: > I don't think we can implement Win32 primitives on top of pthreads, at > least not in a reasonable way. We may be able to do it on top of the > raw kernel futexes, but that's not exactly libc integration (and it > will most likely require new kernel features too). And the only reason > for doing that would be performance, it's certainly not going to make > things more intuitive or more solid. Somebody begs to differ. From http://downloads.transgaming.com/files/winex-3_0_releasenotes.txt : * The core threading model has moved to pthreads to decouple WineX from the continuing changes to certain core system libraries. If Gav can do it, why can't we? :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

4 5

windres: -fo (fwd)
by Dimitrie O. Paun 22 Apr '03

22 Apr '03

---------- Forwarded message ---------- Date: Tue, 22 Apr 2003 14:07:11 -0400 (EDT) From: Dimitrie O. Paun <dimi(a)intelliware.ca> To: binutils(a)sources.redhat.com Subject: windres: -fo This one is the last (famous last words :)) patch in my series of compatibility patches. With this one in, we can hopefully get rid of the ugly ifdefs in Makefiles. You gotta hate MS for the ugly choice of option names... :( BTW, this is now also supported by wrc, so we get the tree way compatibility: windres, wrc, rc. 2003-04-22 Dimitrie O. Paun <dpaun(a)rogers.com> * windres.c: Support -fo for compatibility with rc. (main): Support the -fo option as a synonym for -o. * doc/binutils.texi: Added -fo to the list of options. Index: windres.c =================================================================== RCS file: /cvs/src/src/binutils/windres.c,v retrieving revision 1.17 diff -u -r1.17 windres.c --- windres.c 22 Apr 2003 17:31:08 -0000 1.17 +++ windres.c 22 Apr 2003 18:01:56 -0000 @@ -698,7 +698,7 @@ program_name); fprintf (stream, _(" The options are:\n\ -i --input=<file> Name input file\n\ - -o --output=<file> Name output file\n\ + -o -fo --output=<file> Name output file\n\ -J --input-format=<format> Specify input format\n\ -O --output-format=<format> Specify output format\n\ -F --target=<target> Specify COFF target\n\ @@ -813,7 +813,7 @@ language = 0x409; /* LANG_ENGLISH, SUBLANG_ENGLISH_US. */ use_temp_file = 0; - while ((c = getopt_long (argc, argv, "i:l:o:I:J:O:F:D:U:rhHvV", long_options, + while ((c = getopt_long (argc, argv, "f:i:l:o:I:J:O:F:D:U:rhHvV", long_options, (int *) 0)) != EOF) { switch (c) @@ -822,6 +822,10 @@ input_filename = optarg; break; + case 'f': + if (*optarg != 'o') fatal (_("Unknown option -f%s.\n"), optarg); + optarg++; + /* fall through */ case 'o': output_filename = optarg; break; Index: doc/binutils.texi =================================================================== RCS file: /cvs/src/src/binutils/doc/binutils.texi,v retrieving revision 1.37 diff -u -r1.37 binutils.texi --- doc/binutils.texi 22 Apr 2003 17:31:08 -0000 1.37 +++ doc/binutils.texi 22 Apr 2003 18:02:05 -0000 @@ -2570,6 +2570,7 @@ standard input. @item -o @var{filename} +@item -fo@var{filename} @itemx --output @var{filename} The name of the output file. If this option is not used, then @command{windres} will use the first non-option argument, after any used -- Dimi.

1 0

new script uses winedump
by David Miller 22 Apr '03

22 Apr '03

I have modified the script which cross references dll imports to use winedump instead of dumpbin. It runs in linux now so that more people are able to run it. It is available at http://home.ptd.net/~compsol Please send any questions or comments to me.

1 0

windres: -J -I (take 4)
by Dimitrie O. Paun 22 Apr '03

22 Apr '03

OK, I've received the copyright assignment notification on Apr 10, 2003. (I've forwarded a copy to the list, let me know if you did not get it). So I guess it's prime time for this little patch of mine. Please apply. I have one more patch in mind for windres, and I'm happy :) 2003-04-15 Dimitrie O. Paun <dpaun(a)rogers.com> * windres.c (format_from_name): make the exit on error behaviour optional. (main): Rename the -I option to -J. Introduce -I as synonym for --include-dir. For backwards compatibility also support the old -I behaviour, but issue a deprecation warning. * doc/binutils.texi: Rename -I to -J. Document the new behaviour of the -I option. * testsuite/binutils-all/windres/windres.exp: Add test for the new -J option. Index: windres.c =================================================================== RCS file: /cvs/src/src/binutils/windres.c,v retrieving revision 1.16 diff -u -r1.16 windres.c --- windres.c 5 Apr 2003 08:21:46 -0000 1.16 +++ windres.c 16 Apr 2003 03:14:37 -0000 @@ -106,8 +106,7 @@ /* 150 isn't special; it's just an arbitrary non-ASCII char value. */ -#define OPTION_INCLUDE_DIR 150 -#define OPTION_PREPROCESSOR (OPTION_INCLUDE_DIR + 1) +#define OPTION_PREPROCESSOR 150 #define OPTION_USE_TEMP_FILE (OPTION_PREPROCESSOR + 1) #define OPTION_NO_USE_TEMP_FILE (OPTION_USE_TEMP_FILE + 1) #define OPTION_YYDEBUG (OPTION_NO_USE_TEMP_FILE + 1) @@ -116,8 +115,8 @@ { {"define", required_argument, 0, 'D'}, {"help", no_argument, 0, 'h'}, - {"include-dir", required_argument, 0, OPTION_INCLUDE_DIR}, - {"input-format", required_argument, 0, 'I'}, + {"include-dir", required_argument, 0, 'I'}, + {"input-format", required_argument, 0, 'J'}, {"language", required_argument, 0, 'l'}, {"output-format", required_argument, 0, 'O'}, {"preprocessor", required_argument, 0, OPTION_PREPROCESSOR}, @@ -135,7 +134,7 @@ static void res_init PARAMS ((void)); static int extended_menuitems PARAMS ((const struct menuitem *)); -static enum res_format format_from_name PARAMS ((const char *)); +static enum res_format format_from_name PARAMS ((const char *, int)); static enum res_format format_from_filename PARAMS ((const char *, int)); static void usage PARAMS ((FILE *, int)); static int cmp_res_entry PARAMS ((const PTR, const PTR)); @@ -583,8 +582,9 @@ /* Convert a string to a format type, or exit if it can't be done. */ static enum res_format -format_from_name (name) +format_from_name (name, exit_on_error) const char *name; + int exit_on_error; { const struct format_map *m; @@ -592,7 +592,7 @@ if (strcasecmp (m->name, name) == 0) break; - if (m->name == NULL) + if (m->name == NULL && exit_on_error) { non_fatal (_("unknown format type `%s'"), name); fprintf (stderr, _("%s: supported formats:"), program_name); @@ -699,15 +699,15 @@ fprintf (stream, _(" The options are:\n\ -i --input=<file> Name input file\n\ -o --output=<file> Name output file\n\ - -I --input-format=<format> Specify input format\n\ + -J --input-format=<format> Specify input format\n\ -O --output-format=<format> Specify output format\n\ -F --target=<target> Specify COFF target\n\ --preprocessor=<program> Program to use to preprocess rc file\n\ - --include-dir=<dir> Include directory when preprocessing rc file\n\ + -I --include-dir=<dir> Include directory when preprocessing rc file\n\ -D --define <sym>[=<val>] Define SYM when preprocessing rc file\n\ -U --undefine <sym> Undefine SYM when preprocessing rc file\n\ -v --verbose Verbose - tells you what it's doing\n\ - --language=<val> Set language when reading rc file\n\ + -l --language=<val> Set language when reading rc file\n\ --use-temp-file Use a temporary file instead of popen to read\n\ the preprocessor output\n\ --no-use-temp-file Use popen (default)\n")); @@ -776,6 +776,7 @@ char *input_filename; char *output_filename; enum res_format input_format; + enum res_format input_format_tmp; enum res_format output_format; char *target; char *preprocessor; @@ -812,7 +813,7 @@ language = 0x409; /* LANG_ENGLISH, SUBLANG_ENGLISH_US. */ use_temp_file = 0; - while ((c = getopt_long (argc, argv, "i:l:o:I:O:F:D:U:rhHvV", long_options, + while ((c = getopt_long (argc, argv, "i:l:o:I:J:O:F:D:U:rhHvV", long_options, (int *) 0)) != EOF) { switch (c) @@ -825,12 +826,12 @@ output_filename = optarg; break; - case 'I': - input_format = format_from_name (optarg); + case 'J': + input_format = format_from_name (optarg, 1); break; case 'O': - output_format = format_from_name (optarg); + output_format = format_from_name (optarg, 1); break; case 'F': @@ -869,7 +870,16 @@ verbose ++; break; - case OPTION_INCLUDE_DIR: + case 'I': + /* for backward compatibility, should be removed in the future */ + input_format_tmp = format_from_name (optarg, 0); + if (input_format_tmp != RES_FORMAT_UNKNOWN) + { + fprintf (stderr, _("Option -I is deprecated for setting the input format, please use -J instead.\n")); + input_format = input_format_tmp; + break; + } + if (preprocargs == NULL) { quotedarg = quot (optarg); Index: doc/binutils.texi =================================================================== RCS file: /cvs/src/src/binutils/doc/binutils.texi,v retrieving revision 1.36 diff -u -r1.36 binutils.texi --- doc/binutils.texi 9 Apr 2003 09:55:13 -0000 1.36 +++ doc/binutils.texi 16 Apr 2003 03:14:42 -0000 @@ -2577,7 +2577,7 @@ non-option argument, then @command{windres} will write to standard output. @command{windres} can not write a COFF file to standard output. -@item -I @var{format} +@item -J @var{format} @itemx --input-format @var{format} The input format to read. @var{format} may be @samp{res}, @samp{rc}, or @samp{coff}. If no input format is specified, @command{windres} will @@ -2605,11 +2605,17 @@ to use, including any leading arguments. The default preprocessor argument is @code{gcc -E -xc-header -DRC_INVOKED}. +@item -I @var{directory} @item --include-dir @var{directory} Specify an include directory to use when reading an @code{rc} file. @command{windres} will pass this to the preprocessor as an @option{-I} option. @command{windres} will also search this directory when looking for -files named in the @code{rc} file. +files named in the @code{rc} file. If the argument passed to this command +matches any of the supported @var{formats} (as descrived in the @option{-J} +option), it will issue a deprecation warning, and behave just like the +@option{-J} option. New programs should not use this behaviour. If a +directory happens to match a @var{format}, simple prefix it with @samp{./} +to disable the backward compatibility. @item -D @var{target} @itemx --define @var{sym}[=@var{val}] Index: testsuite/binutils-all/windres/windres.exp =================================================================== RCS file: /cvs/src/src/binutils/testsuite/binutils-all/windres/windres.exp,v retrieving revision 1.3 diff -u -r1.3 windres.exp --- testsuite/binutils-all/windres/windres.exp 27 Jul 2001 16:16:07 -0000 1.3 +++ testsuite/binutils-all/windres/windres.exp 16 Apr 2003 03:14:43 -0000 @@ -81,6 +81,40 @@ setup_xfail *-* } + verbose "$wr -J rc -O res $res tmpdir/$broot.res" 1 + catch "exec $wr -J rc -O res $res tmpdir/$broot.res" err + + if ![string match "" $err] then { + send_log "$err\n" + verbose "$err" 1 + fail "windres/$broot (parse)" + continue; + } + pass "windres/$broot (parse)" + + set rc [open $res] + while { [gets $rc line] != -1 } { + if ![regexp "^(//|/\*|#)" $line] { + break + } + if [regexp "parse-only" $line] { + file delete "tmpdir/$broot.res" + set done 1 + break; + } + if [regexp "\[xc\]fail *(\[^ \]*)" $line junk sys] { + setup_xfail $sys + continue; + } + } + if { $done != 0 } { + continue; + } + + if { "$broot" != "bmpalign" && "$target_xfail" == "yes" } { + setup_xfail *-* + } + verbose "$wr -I rc -O res $res tmpdir/$broot.res" 1 catch "exec $wr -I rc -O res $res tmpdir/$broot.res" err -- Dimi.

2 1

vxd idea
by Vilppa Salt 22 Apr '03

22 Apr '03

Hi Could this Qemu emulator be used for running applications with vxd files on x86? If ring 0 is reserved so could it be emulated with qemu and mapped appropriately inside Wine? --- Vilppa- Sunpoint.net ilmoittaa: Sunpoint.net tarjoaa kaikille rekisteröityneille käyttäjilleen kuukausimaksuttoman Internet -yhteyden (pvm). http://www.sunpoint.net/SunAds/click.htm?mode=footer&id=71&jump=http%3A%2F%…

2 1

Re: named pipe patch
by Dan Kegel 22 Apr '03

22 Apr '03

Bill Medland wrote: >>Agreed. But blocking is hard. It may require the full rewrite of >>wine's named pipe support the other guy is working on. > > > It probably requires more than that; I reckon it may require a rewrite of the > general flushing code. Since it has to block, I don't know where the waiting > is supposed to happen (in the server or in the client) I had an idea on this -- might not be so hard after all. >>My guess is that the data loss you were running into is the >>main real-world issue, and the fact we don't blocking on pipe flush >>won't be a showstopper. Please do try my patch, and >>let me know what you see in practice. I'd like to know if >>what I'm doing is even close. > > > Doesn't seem to work, I'm afraid. OK, I'll chuck that part of my patch then. > Don't bother trying to hack it on my behalf, just do it for yourself. I get > around it by sticking a 50ms sleep in the server before the flush; it's long > enough to force a process switch and for the client to read the pipe. It'll > do for a few months while I am developing and hopefully the proper fix will > be out then. I bet I can stick in a test on bytes in the pipe and loop appropriately. My need has vanished -- now I'm just trying to achieve win32 compliance. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

RE: FoxPro & Wine :)
by Patrik Stridvall 22 Apr '03

22 Apr '03

> Dimitrie O. Paun wrote: > > On April 22, 2003 01:17 am, Dan Kegel wrote: > > > >>It may not be, but at least it brings it into the realm > >>of Microsoft moves we've seen before. (cf. MFC dlls, which are > >>never distributed with Windows itself, and may legally > >>tie all MFC apps to run on Windows alone, if the MFC EULA > >>holds. Or so I recall.) > > > > > > And the question is: is this enforceable? > > And the answer is: if it isn't, neither is the (L)GPL. Why > would MS not > be able to place restrictions on distribution of their own > copyrighted code? With risk of rekindling the LGPL debate, I have to agree. Both the Wine LGPL issue and the Microsoft "DLL" redistribution issue above have one thing in common: "Somebody is both trying to have the cake and eat it." I have a long time, invain it seems, been trying to argue that copyright law neither: 1. Should (from a sane public policy point of view) 2. Intends (from what copyright traditionally is meant for) 3. Does (from a strict, by the letter, analysis on the law) support the view that it is allowed to both "have the cake and eat it". Very, very simplified. You have basicly have two choices: 1. Distribute your work (or part of it) for free 2. Distribute your work (or part of it) for a fee. if you choose (1) because you for some reason doesn't think (2) is to your advantages you have no right to complain that things didn't work out as you hoped. In the Microsoft Visual FoxPro it is quite obvious that demanding a fee for the "runtime" would reduce the number of developers using the product, so they didn't. Now they have to live with the consequences...

2 1

re: FoxPro & Wine :)
by Dan Kegel 22 Apr '03

22 Apr '03

Dimi wrote: > Summary: Microsoft threatens developers for running > Visual FoxPro on Linux using Wine. > > http://yro.slashdot.org/yro/03/04/21/2045200.shtml?tid=109&tid=125 > > I still don't get it how it is legal to tie a product to the OS. It's the redistributable files. See http://www.linuxtransfer.com/h/misc_vfplinuxjackofhearts.htm for the details. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

7 8

getopt_long not found, even though it is present
by Gerald Pfeifer 22 Apr '03

22 Apr '03

Assume we are on a system which does have /usr/local/include/getopt.h, and support for getopt_long, but where getopt_long is _not_ in libc. Our configure then diagnoses #define HAVE_GETOPT_H 1 /* #undef HAVE_GETOPT_LONG */ which leads a compilation error for tools/wrc/wrc.c which includes "wine/port.h" and <getopt.h>, for _both_ define struct option. As far as I can see, the problem here is that in tools/wrc/wrc.c we check for the presence of HAVE_GETOPT_H, while in wine/port.h we check for HAVE_GETOPT_LONG. The patch below is one way to fix this problem, another way would be to move the #inclusion of <getopt.h> from individual files to wine/port.h. Yet another option would be the hack autoconf to try linking libgnugetopt when looking for getopt_long, but I don't know how to hack this into configure. How should we resolve this? Gerald Index: wrc.c =================================================================== RCS file: /home/wine/wine/tools/wrc/wrc.c,v retrieving revision 1.33 diff -u -3 -p -r1.33 wrc.c --- wrc.c 28 Mar 2003 19:31:49 -0000 1.33 +++ wrc.c 17 Apr 2003 10:18:18 -0000 @@ -32,7 +32,9 @@ #include <ctype.h> #include <signal.h> #ifdef HAVE_GETOPT_H -# include <getopt.h> +# ifdef HAVE_GETOPT_LONG +# include <getopt.h> +# endif #endif #include "wrc.h"

1 1

Abiword on Wine. Still pathological text display.
by Dan Kegel 22 Apr '03

22 Apr '03

Various people have tried running Abiword on Wine in the past. I and one other person had trouble with 0.9 and 0.99: http://www.winehq.com/hypermail/wine-devel/2001/08/0036.html http://www.abisource.com/mailinglists/abiword-dev/01/November/0005.html http://www.kegel.com/linux/winelog.html#abiword I thought I'd see if things were working any better today, with Abiword 1.0.5 and Wine cvs (April 19, 2003). Installation on redhat 9 went perfectly -- I even got a nice desktop icon -- but when I ran Abiword, it used a dingbats font for the UI! After I finished laughing, I ran --debugmsg +font, and saw trace:font:WineEngCreateFontInstance L"System", h=16, it=0, weight=400, PandF=22, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance Chosen: L"Dingbats" L"Regular" I'm running a vanilla Red Hat 9 installation, and I'd expect *some* system font to be a better match for System than the one Wine picked, "Dingbats". Amusingly, it looks like what's going on is that Abiword itself installs Dingbats into %WINDIR%/Fonts. Since I'm using a fake Windows, this is then the *only* font in that directory, and it's used for all matches. Heh. OK, so I removed that one font. That lets AbiWord present a user interface (yay), but just try typing into it! Each successive line displays more or less directly on top of the previous one. This is the same failure mode I observed in my previous runs. Wine has evidently not progressed much in this area. Guess it's time to open a bug report in the wine bug tracker (perhaps marking it as related to http://bugs.winehq.com/show_bug.cgi?id=698 ). (And ask the guy who rated AbiWord "works great" what he was smoking. Maybe he was using a real Windows installation?) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Solaris Maintenance
by Robert Lunnon 21 Apr '03

21 Apr '03

I am doing some maintenance for Solaris x86 Two major (new) things were noted. 1. The introduction of ptrace(GETREGS... which is not supported under Solaris was patched with a suitable stub file. This will be moved to an emulation of ptrace using /proc debugging facilities as time allows. For now this works without the debugger. 2. There are some NULL pointers being passed to printf and friends again, this might work under linux/glibc but is not at all portable to other libc implementations where you can expect a segmentation fault If I might be so bold as to suggest the following advise 1. Check portability of interfaces you use against the docs for the platforms Wine supports. For Solaris look at http://docs.sun.com 2. Be carefull about passing null pointers to library functions unless the documentation for all affected systems says it's allowable. Be particularly careful with printf and friends because NULL gets accepted silently on linux (quite improperly IMHO). Now I have one question Someone cleaned up a whole pile of NULL pointer passing to printf some time ago, how was this done ? I.E. was there a generallised solution to this problem or was it an instance by instance search and destroy mission ? Thanks Bob

1 0

FoxPro & Wine :)
by Dimitrie O. Paun 21 Apr '03

21 Apr '03

Summary: Microsoft threatens developers for running Visual FoxPro on Linux using Wine. http://yro.slashdot.org/yro/03/04/21/2045200.shtml?tid=109&tid=125 I still don't get it how it is legal to tie a product to the OS. -- Dimi.

1 0

System Shock 2 Working (Almost)
by OverrideX 21 Apr '03

21 Apr '03

Hey guys, I don't know if anyone else has but I've been trying to get system shock 2 working with wine for quite some time. It segfaults with the latest versions of winex, but with a cvs of wine from 20030115 it works! Menus, sound and 3D all seem to be working fine, except for some slight texture corruption on things like door handles. The problem is the 2D overlay stuff - the HUD, inventory, etc. are all missing which makes it unplayable. I saw on some other forum that it had been added to either wine or winex... anyone have any ideas? Another problem is that ss2 no longer seems to work with the newer wine builds (20030327 at least) it just displays a message that says video card not supported. So, I'd just like to know if the 2D stuff may work in the latest wines or not, and if so how to fix the video card not supported message - thanks for any info :) -Dan -- OverrideX <overridex(a)punkass.com> GPG Key Fingerprint = 4AD5 CE9C D7C8 0069 BDD3 7F72 3AB2 642A 5A5D EB89 The Road goes ever on and on Down from the door where it began. Now far ahead the Road has gone, And I must follow, if I can, Pursuing it with eager feet, Until it joins some larger way Where many paths and errands meet. And whither then? I cannot say. -- J. R. R. Tolkien

1 0

dlls/d3d8/device.c: `GL_DOT3_RGBA' undeclared
by Gerald Pfeifer 21 Apr '03

21 Apr '03

The following change to dlls/d3d8/device.c unfortunately broke building an many systems: revision 1.39 date: 2003/04/19 20:30:58; author: julliard; state: Exp; lines: +7 -3 Jason Edmeades <us(a)the-edmeades.demon.co.uk> Add DotProduct3 support if supported by opengl. Here is the diagnostics I got: /usr/bin/gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D_REENTRANT -fPIC -D__WINESRC__ -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -g -O2 -o device.o device.c device.c: In function `IDirect3DDevice8Impl_SetTextureStageState': device.c:3413: `GL_DOT3_RGBA' undeclared (first use in this function) device.c:3413: (Each undeclared identifier is reported only once device.c:3413: for each function it appears in.) gmake[2]: *** [device.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/d3d8' gmake[1]: *** [d3d8] Error 2 Would you mind having a look? Gerald The packages I've installed are the following; this is a FreeBSD system, but the breakage appears "portable". % pkg_info | grep -i XF XFree86-4.2.0_1,1 X11/XFree86 core distribution (complete, using mini/meta-po XFree86-FontServer-4.2.0 XFree86-4 Font Server XFree86-Server-4.2.1_3 XFree86-4 X server and related programs XFree86-VirtualFramebufferServer-4.2.1 XFree86-4 Virtual Framebuffer Server XFree86-aoutlibs-3.3.6.9 XFree86 a.out compatibility libraries XFree86-clients-4.2.1_1 XFree86-4 Client environments XFree86-documents-4.2.0 XFree86-4 Document Files XFree86-font100dpi-4.2.0 XFree86-4 bitmap 100 dpi fonts XFree86-font75dpi-4.2.0 XFree86-4 bitmap 75 dpi fonts XFree86-fontCyrillic-4.2.0_4 XFree86-4 Cyrillic Fonts XFree86-fontDefaultBitmaps-4.2.0 XFree86-4 default bitmap fonts XFree86-fontEncodings-4.2.0 XFree86-4 font encoding files XFree86-fontScalable-4.2.0 XFree86-4 Scalable font files XFree86-libraries-4.2.1_1 XFree86-4 include/(shared) library kit % pkg_info | grep -i mesa Mesa-3.4.2_2 A graphics library similar to SGI's OpenGL

2 1

Re: Localization to portuguese of ptb.nls and ptg.nls
by Dmitry Timoshkov 21 Apr '03

21 Apr '03

"Marcelo Duarte" <wine-devel(a)bol.com.br> wrote: > > Please do not change standard LOCALE_Sxxx and LOCALE_Ixxx values, they > > all were generated automatically by Alexandre to return exactly the same > > values as Windows does. > > Ok, but the correct it's what I send. For ptb.nls I sure. What source of information are you referring as a correct one? I think that Alexandre uses NT 4.0 as a reference system. I believe that the case of the first letter should not be a source for disagreement and debates. -- Dmitry.

1 0

Re: keyboard mapping with XFree86 4.3.0
by Paulo Sousa 21 Apr '03

21 Apr '03

Hi, I just installed RH9 with XFree 4.3.0 and my Portuguese Keyboard is detected as a "close match" of a Latin American one. As I saw that, I tried to figure out if there was no support for Portuguese keyboards, but there was. The layout is this one: /*** Portuguese keyboard layout */ static const char main_key_PT[MAIN_LEN][4] = { "\\¦","1!","2\"@","3#£","4$§","5%","6&","7/{","8([","9)]","0=}","'?","«»", "qQ", "wW","eE", "rR", "tT", "yY", "uU", "iI", "oO", "pP", "+*\\¨","\\'\\`", "aA", "sS","dD", "fF", "gG", "hH", "jJ", "kK", "lL", "çÇ", "ºª", "\\~\\^", "zZ", "xX","cC", "vV", "bB", "nN", "mM", ",;", ".:", "-_", "<>" }; This is prety much correct (except for the missing Euro sign in some new keyboards). I then checked out what where the undetected keys and noticed that they were the ones with 3 caracters (eg: 3#£). By removing the third character I got this layout: /*** Portuguese keyboard layout */ static const char main_key_PT[MAIN_LEN][4] = { "\\|","1!","2\"","3#","4$","5%","6&","7/","8(","9)","0=","'?","«»", "qQ", "wW","eE", "rR", "tT", "yY", "uU", "iI", "oO", "pP", "+*","´`", "aA", "sS","dD", "fF", "gG", "hH", "jJ", "kK", "lL", "çÇ", "ºª", "~^", "zZ", "xX","cC", "vV", "bB", "nN", "mM", ",;", ".:", "-_", "<>" }; After compiling, this new layout is detected perfectly, although it does not reflect all the characters in my keyboard. Also, the "«'çº" keys do not work! Does anybody know why isn't the third character being reported by XFree? Is this a XFree bug? Thanks, Paulo Sousa

2 1

Wine10?
by Dan Kegel 21 Apr '03

21 Apr '03

Any interest in a party to celebrate Wine's 10th birthday? We could date it from the first Usenet message that mentions Wine, which I think is: > Newsgroups: comp.os.linux > From: bob(a)amscons.com (Bob Amstadt) > Subject: Re: Impressions of WABI/Univel vs Linux > References: <C9JoGx.IMM(a)news2.cis.umn.edu> > Organization: Amstadt Consulting Group > Date: Fri, 2 Jul 1993 17:36:48 GMT > X-Newsreader: Tin 1.1 PL4 > Message-ID: <1993Jul2.173648.3202(a)amscons.com> > Lines: 7 > > > Of course, for those of you who are interested in running Windows programs > there is an effort in progress to create something similar to Sun's WABI. > There is an activists channel, "WABI", for discussion of this project. > There is need for many volunteers to complete this project. > -- > Bob Amstadt > bob(a)amscons.com - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 1

Re: Localization to portuguese of ptb.nls and ptg.nls
by Dmitry Timoshkov 21 Apr '03

21 Apr '03

"Marcelo Duarte" <wine-devel(a)bol.com.br> wrote: > Changelog > * Localization to portuguese of ptb.nls and ptg.nls > - LOCALE_SMONTHNAME11 "novembro" > - LOCALE_SMONTHNAME12 "dezembro" > + LOCALE_SMONTHNAME11 "Novembro" > + LOCALE_SMONTHNAME12 "Dezembro" > - LOCALE_SSHORTDATE "d/M/yyyy" > + LOCALE_SSHORTDATE "dd/MM/yyyy" Please do not change standard LOCALE_Sxxx and LOCALE_Ixxx values, they all were generated automatically by Alexandre to return exactly the same values as Windows does. -- Dmitry.

1 0

Re: [dx8-7] Fix compile problem introduced by dx8-2
by Marcelo Duarte 21 Apr '03

21 Apr '03

Em Dom 20 Abr 2003 07:34, Ann and Jason Edmeades escreveu: > Sorry about the compilation problem - missed this one! > > Changelog > > DOT3 isnt there on earlier opengl versions > > Jason other compiler problem: make[2]: Entering directory `/home/mduarte/wine/dlls/d3d8' gcc -c -I. -I. -I../../include -I../../include -I/usr/X11R6/include -D_REENTRANT -fPIC -D__WINESRC__ -Wall -mpreferred-stack-boundary=2 -gstabs+ -g -O2 -o device.o device.c device.c: In function `IDirect3DDevice8Impl_SetTextureStageState': device.c:3456: `GL_MIRRORED_REPEAT_ARB' undeclared (first use in this function) device.c:3456: (Each undeclared identifier is reported only once device.c:3456: for each function it appears in.) make[2]: *** [device.o] Error 1 make[2]: Leaving directory `/home/mduarte/wine/dlls/d3d8' make[1]: *** [d3d8] Error 2 make[1]: Leaving directory `/home/mduarte/wine/dlls' make: *** [dlls] Error 2

1 0

compiling wine under cygwin - status ??
by Kai Kai 20 Apr '03

20 Apr '03

Hi, all, I am a NEWBIE in this area. I am very interested inthe wine and cygwin. Can wine work under cygwin now? Or Can I build Wine dll under cygwin? I just found the status from David on Nov28, 2002, isthere news about it now? howto is better:-) Thanks Kai _________________________________________________________ Do You Yahoo!? 雅虎邀你参与CCTV-2对话节目调查：移动、联通、灵通，要说爱你不容易 http://rd.yahoo.com/mail_cn/tag/?http://cn.surveys.yahoo.com/cctv_wireless_…

2 1

New trace option?
by Ann and Jason Edmeades 20 Apr '03

20 Apr '03

I just noticed there is an option --debugmsg +tid which adds the thread prefix to the debugmsg trace. I would really, really like a timestamp prefix - Is this something people would/could find acceptable? I've hacked a version for my own use using gettimeofday, but anything which shows seconds or slightly higher resolution would be invaluable. Perhaps a +time option? Is this something people would find useful? If so, anyone know a good, portable way of doing it? Jason

4 3

Re: REFIXED: [dx8-7] Fix compile problem introduced by dx8-2
by keisangi 20 Apr '03

20 Apr '03

Ann and Jason Edmeades wrote: >Please use this fix rather than the last one - Just noticed the break >statement was the wrong side of the #endif > >Changelog > >DOT3 isnt there on earlier opengl versions > >Jason > > hi, i've subscribed this mailling list for testing purposes only, now i'd like to unsubscribe but i can't figure how to do. could someone can tell me?

3 2

Re: Remove db2html-winehq
by Alexandre Julliard 20 Apr '03

20 Apr '03

"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > There is no reason to have our own db2html hack. It creates > problems, we never got it to work reliably on different distros, > etc. We should use the one provided with the system, it's a far > safer bet. Also, our build system uses the standard db2html, > it's only the make_winehq script that used it. And that script > is used only on WineHQ, where we should be able to control the > environment to have a half-decent db2html that supports the > -d option. Do we actually need that make_winehq script at all? It seems almost everything it does is already done in the normal makefiles, except the bit about the winehq stylesheet. And I'm not sure what this one is for, since the docs on WineHQ look identical to the one we get by doing 'make doc'. Does anyone know how this is all supposed to work? -- Alexandre Julliard julliard(a)winehq.com

3 6

cvs woes
by Ann and Jason Edmeades 20 Apr '03

20 Apr '03

| device.c: In function `IDirect3DDevice8Impl_SetTextureStageState': | device.c:3456: `GL_MIRRORED_REPEAT_ARB' undeclared (first use in this function) | device.c:3456: (Each undeclared identifier is reported only once | device.c:3456: for each function it appears in.) Hmm - This is a more tricky one to fix - Lionel, got any ideas? I have #if'defed it for GL_VERSION_1_3, but it looks like some headers who define GL_VERSION_1_3 dont have the mirrored repeat ARB defines. As a workaround, add #define GL_MIRRORED_REPEAT_ARB 0x8370 at the top of the source part. Question - If you look in your glext.h, does it define GL_MIRRORED_REPEAT instead? Jason

3 3

compiling wine under cygwin - status ??
by Kai Kai 20 Apr '03

20 Apr '03

Hi, all, I am a NEWBIE in this area. I am very interested in the wine and cygwin. Can wine work under cygwin now? Or can Wine DLL be build under cygwin? I just found the status from David on Nov28, 2002, is there news about it now? howto is better:-) Thanks Kai _________________________________________________________ Do You Yahoo!? 雅虎邀你参与CCTV-2对话节目调查：移动、联通、灵通，要说爱你不容易 http://rd.yahoo.com/mail_cn/tag/?http://cn.surveys.yahoo.com/cctv_wireless_…

1 0

CVS build failed
by Paul Millar 20 Apr '03

20 Apr '03

Anyone else getting this? On a fairly standard RH7.3 machine: device.c: In function `IDirect3DDevice8Impl_SetTextureStageState': device.c:3413: `GL_DOT3_RGBA' undeclared (first use in this function) device.c:3413: (Each undeclared identifier is reported only once device.c:3413: for each function it appears in.) make[2]: *** [device.o] Error 1 Looks like http://cvs.winehq.com/patch.py?id=7915 is the cause. See http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php and http://www.astro.gla.ac.uk/users/paulm/WRT/buildinfo.php?id=394 for more details .. Cheers, Paul. ---- Paul Millar

3 2

Re: UPDATED: video mode changes
by Lionel Ulmer 20 Apr '03

20 Apr '03

Just a small nitpick : > + XF86VidModeModeInfo *mode; > + DWORD dwBpp = GetSystemMetrics(SM_WINE_BPP); > + if (dwBpp == 24) dwBpp = 32; I would prefer this change to be done directly in the 'GetDeviceCaps' function of the X11DRV to always return 32 in case the scren depth is 24. I know for sure that this fixes at least one application and should not hurt others :-) A part from that, the patch looks nice... If it breaks apps on Desktop mode, we will fix it then by re-adding the 'dummy' modes :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

Re: [dx8-5] Windows never reports 24 bit screen depths
by Ann and Jason Edmeades 19 Apr '03

19 Apr '03

(Apologies for the duplicate sent - Didnt put a subject on first time) >> Windows never reports 24 bit colours, and some games fail to work unless in >> specific modes. Report 16bit colour for 24bit modes >Out of curiosity, in that case, why report 24 bits at all ? Why not just >report 8, 16 and 32 ? I dont - I query it with GetDeviceCaps and this is what gets returned. hdc = CreateDCA("DISPLAY", NULL, NULL, NULL); bpp = GetDeviceCaps(hdc, BITSPIXEL); DeleteDC(hdc); Actually, all the screen handling in the dx8 code is awful (I can say that as I put it there...). I am hoping that if the recent changes to the window modes is implemented, I can use that code to query what modes this device supports, and to change the mode/resolution appropriately. The code that we have is a semi working stopgap really. Jason

2 3

(no subject)
by Ann and Jason Edmeades 19 Apr '03

19 Apr '03

>> Windows never reports 24 bit colours, and some games fail to work unless in >> specific modes. Report 16bit colour for 24bit modes >Out of curiosity, in that case, why report 24 bits at all ? Why not just >report 8, 16 and 32 ? I dont - I query it with GetDeviceCaps and this is what gets returned. hdc = CreateDCA("DISPLAY", NULL, NULL, NULL); bpp = GetDeviceCaps(hdc, BITSPIXEL); DeleteDC(hdc); Actually, all the screen handling in the dx8 code is awful (I can say that as I put it there...). I am hoping that if the recent changes to the window modes is implemented, I can use that code to query what modes this device supports, and to change the mode/resolution appropriately. The code that we have is a semi working stopgap really. Jason

1 0

Re: [dx8-5] Windows never reports 24 bit screen depths
by Lionel Ulmer 19 Apr '03

19 Apr '03

> Windows never reports 24 bit colours, and some games fail to work unless in > specific modes. Report 16bit colour for 24bit modes Out of curiosity, in that case, why report 24 bits at all ? Why not just report 8, 16 and 32 ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: [Resend] Implements languagegroups functions
by Alexandre Julliard 19 Apr '03

19 Apr '03

Maxime Bellengé <maxime.bellenge(a)laposte.net> writes: > This patch implements the languagegroups functions. > As I have access to a French and English windows 2k+, I set > the resources accordingly for the kernel32 resources. However, as > I don't know the resources for other languages, I have put English > resources in the other nls files. People will have to change them to the > correct values. > As suggested by alexandre, I chose some unused resource ids because even > win2k and winxp don't store them the same way and both of them > conflicted with the actual kernel32 resources from wine. I applied the resource strings, but the rest will still need a bit of work: you can't use a global variable to store the callback function, this is not reentrant, you need to do everything on the stack. Also I think the locale->language group mapping should be stored in the resources too, not in the code. And I'd suggest pretending that all language groups are installed, since we can't install them dynamically anyway. -- Alexandre Julliard julliard(a)winehq.com

1 0

winedbg
by Michal Janusz Miroslaw 19 Apr '03

19 Apr '03

Hello, Is anyone working on winedbg ? I have some ideas and would like to hear opinions/more ideas/flames: * enabling/disabling of displays [done] * displays shown in one function only [done] * implement define command to add symbols on the fly (didn't find it is sources except in help text ...) * save/restore breakpoints/displays/defined symbols * reverse backtrace list (so current frame is at the bottom and you dont have to scroll all the way up) * remove limit of 10 entries in DEBUG_GetSymbolValue [done] * remove duplicated code in DEBUG_FindNearestSymbol/DEBUG_CheckLinenoStatus I haven't looked everywhere, yet, but `grep FIXME *|wc -l` shows 106 now, so I should find something. :) -- Michal Miroslaw

3 4

Wine keyboard focus and bug 1385
by Roderick Colenbrander 19 Apr '03

19 Apr '03

Hi, When playing for example the game Jedi Outcast on Wine (quake3 based) in non-deskop a keyboard related problem appears. The game starts fine but doesn't receive any keyboard input. When I press for example the A key, the character appears in the console. I saw this problem before and it looks a lot like bug 1385: http://bugs.winehq.com/show_bug.cgi?id=1385 After looking a bit at the source code I found a way to fix my problem. I edited some code in the SetFocus function from x11drv/window.c. The original code looks like this: /* we must not use CurrentTime (ICCCM), so try to use last message time instead */ /* FIXME: this is not entirely correct */ XSetInputFocus( display, win, RevertToParent, /*CurrentTime*/ GetMessageTime() + X11DRV_server_startticks ); When I set the time to CurrentTime the problem was gone. According to the description and the FIXME neither solutions are correct. I don't know enough about the working of the x11 driver and X programming, so perhaps someone can help? Thanks, Roderick Colenbrander

1 0

Palettes - Any experts?
by Ann and Jason Edmeades 19 Apr '03

19 Apr '03

Hello, Having taken a break for a few months I thought I'd try playing with wine again... I have been trying to work out why one game I am investigating never even shows its splash screen, and have got most of the way until I have got stuck. Can anyone offer me some advice? The game launcher kicks off a process whose first thread creates a dummy 16x16 window which is placed in the center of the screen (who knows why!), and launches another thread. The main thread then proceeds to create another process, and wait for it to complete. This means the dummy window is not processing any messages and if sent any the whole thing hangs :-( The launched thread creates the splash screen and begins a WM_PAINT operation. During this processing it calls CreateCompatibleDC, SelectObject, SelectPalette and finally RealizePalette This RealizePalette call (UserRealizePalette, windows\painting.c) results in 256 colors being mapped in, and SendMessageA( HWND_BROADCAST, WM_PALETTECHANGED, (WPARAM)hWnd, 0L); to occur. This broadcast hangs attempting to send the message to the first thread as it is in a hung state waiting for another process to end. Under windows, the RealizePalette returns 0, and spy on Windows does not show this message being sent to the 'hung' thread. 'Interestingly', putting an xterm behind the splash panel, and trying to bring it to the front (to force a repaint) shows that UserRealizePalette is always returning 256, which I thing is the underlying bug. It appears to create a palette every WM_PAINT operation. Commenting out the broadcast makes the splashscreen appear perfectly, so I know I am along the right lines. Can anyone fill in some gaps and point me in the right direction? Debug logs willingly available! :-) Thanks Jason

3 6

FreeBSD and Total Annihilation (Bug 1392)
by Rod Taylor 19 Apr '03

19 Apr '03

With the sound fix, the demo version works great. The real version (which I just bought) doesn't work at all (blank screen) as shipped or with patches from the distributor. Attached is a trace of dplay and virtual, and below is the code snippit which I believe to be causing the problem. FreeBSD 4.8-RELEASE using 20030408 Wine sources ('official port') Any suggestions? Interesting lines from trace: trace:dplay:DPLAYX_ConstructData Through wait trace:dplay:DPLAYX_ConstructData File mapped 0x5c created trace:virtual:NtMapViewOfSection handle=0x5c addr=0x50000000 off=000000000 size=0 access=4 err:dplay:DPLAYX_ConstructData : unable to map static data into process memory space (487) trace:virtual:NtAllocateVirtualMemory 0x0 00110000 2000 00000040 The source of the error (487) seems to be line 466 in ntdll/virtual.c: static NTSTATUS anon_mmap_aligned( void **addr, unsigned int size, int prot, int flags ) { void *ptr, *base = *addr; unsigned int view_size = size + (base ? 0 : granularity_mask + 1); if ((ptr = wine_anon_mmap( base, view_size, prot, flags )) == (void *)-1) { if (errno == ENOMEM) return STATUS_NO_MEMORY; return STATUS_INVALID_PARAMETER; } if (!base) { /* Release the extra memory while keeping the range * starting on the granularity boundary. */ if ((unsigned int)ptr & granularity_mask) { unsigned int extra = granularity_mask + 1 - ((unsigned int)ptr & granularity_mask); munmap( ptr, extra ); ptr = (char *)ptr + extra; view_size -= extra; } if (view_size > size) munmap( (char *)ptr + size, view_size - size ); } else if (ptr != base) { /* We couldn't get the address we wanted */ munmap( ptr, view_size ); return STATUS_CONFLICTING_ADDRESSES; /* !! HERE !! */ } -- Rod Taylor <rbt(a)rbt.ca> PGP Key: http://www.rbt.ca/rbtpub.asc

1 0

named pipe patch
by Dan Kegel 18 Apr '03

18 Apr '03

Here's a draft of a patch that tries to fix two problems: 1. can't open a pipe until server has called ConnectNamedPipe (on Win32, pipes can be opened immediately after CreateNamedPipe) 2. client loses any data in pipe if server calls FlushFileBuffers and then immediately calls DisconnectNamedPipe. I work around this by keeping a reference to the server side fd in the client pipe user. FlushFileBuffers still doesn't work, but we don't care; this is kind of a unixification of named pipe semantics. It shifts our win32 noncompliance from a very touchy spot to a less touchy spot, I hope. In both cases, I try to solve the problem by passing fd's inside wineserver. I have no idea if I'm doing this right, but it does pass most of my single-process regression tests. (Overlapped I/O is still broken, and I'm not sure if this fd passing magic will work if the pipe ends are in different processes.) Interestingly, it seems that the DisconnectNamedPipe()/ConnectNamedPipe() sequence as previously written would have failed if a unix file descriptor was created or deleted between pipe disconnection and reconnection. This is because a new fd is used for each pipe session, but the old fd number was never removed from the handle-to-unix-fd cache upon DisconnectNamedPipe. My workaround for the data loss problem exposed this issue. I "fixed" it by invalidating the cached fd for the handle passed to DisconnectNamedPipe. (If there are any other handles to this object, their fds won't be invalidated. Shouldn't matter in practice...) This patch also includes an improved test for named pipes. I'm posting it here rather than to wine-patches to get feedback on whether the fd passing I'm doing is sane. Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 Index: server/object.c =================================================================== RCS file: /home/wine/wine/server/object.c,v retrieving revision 1.27 diff -d -u -r1.27 object.c --- server/object.c 19 Feb 2003 00:33:33 -0000 1.27 +++ server/object.c 18 Apr 2003 17:41:17 -0000 @@ -193,6 +193,7 @@ struct object *grab_object( void *ptr ) { struct object *obj = (struct object *)ptr; + assert( obj ); assert( obj->refcount < INT_MAX ); obj->refcount++; return obj; Index: server/file.h =================================================================== RCS file: /home/wine/wine/server/file.h,v retrieving revision 1.7 diff -d -u -r1.7 file.h --- server/file.h 26 Mar 2003 23:41:43 -0000 1.7 +++ server/file.h 18 Apr 2003 17:41:17 -0000 @@ -49,6 +49,7 @@ extern struct fd *create_anonymous_fd( const struct fd_ops *fd_user_ops, int unix_fd, struct object *user ); extern void *get_fd_user( struct fd *fd ); +extern void set_fd_user( struct fd *fd, struct object *user ); extern int get_unix_fd( struct fd *fd ); extern void fd_poll_event( struct fd *fd, int event ); extern int check_fd_events( struct fd *fd, int events ); Index: server/fd.c =================================================================== RCS file: /home/wine/wine/server/fd.c,v retrieving revision 1.8 diff -d -u -r1.8 fd.c --- server/fd.c 26 Mar 2003 01:32:18 -0000 1.8 +++ server/fd.c 18 Apr 2003 17:41:18 -0000 @@ -884,6 +884,12 @@ return fd->user; } +/* change the object that is using an fd */ +void set_fd_user( struct fd *fd, struct object *user ) +{ + fd->user = user; +} + /* retrieve the unix fd for an object */ int get_unix_fd( struct fd *fd ) { @@ -993,15 +999,22 @@ return fd; } -/* flush a file buffers */ +/* flush a file's buffers */ DECL_HANDLER(flush_file) { - struct fd *fd = get_handle_fd_obj( current->process, req->handle, 0 ); - - if (fd) - { - fd->fd_ops->flush( fd ); - release_object( fd ); + struct object *obj = get_handle_obj(current->process, req->handle, 0, NULL); + if (!obj) { + set_error( STATUS_INVALID_HANDLE ); + } else { + struct fd *fd = get_obj_fd(obj); + /* It's ok for named pipes, and possibly other kinds of objects, + * to not have fds associated sometimes, so do nothing if no fd. + */ + if (fd) { + fd->fd_ops->flush( fd ); + release_object( fd ); + } + release_object( obj ); } } Index: server/handle.h =================================================================== RCS file: /home/wine/wine/server/handle.h,v retrieving revision 1.12 diff -d -u -r1.12 handle.h --- server/handle.h 14 Feb 2003 20:27:10 -0000 1.12 +++ server/handle.h 18 Apr 2003 17:41:18 -0000 @@ -39,6 +39,7 @@ extern struct object *get_handle_obj( struct process *process, obj_handle_t handle, unsigned int access, const struct object_ops *ops ); extern int get_handle_unix_fd( struct process *process, obj_handle_t handle, unsigned int access ); +extern void invalidate_handle_unix_fd( struct process *process, obj_handle_t handle ); extern int set_handle_info( struct process *process, obj_handle_t handle, int mask, int flags, int *fd ); extern obj_handle_t duplicate_handle( struct process *src, obj_handle_t src_handle, struct process *dst, unsigned int access, int inherit, int options ); Index: server/handle.c =================================================================== RCS file: /home/wine/wine/server/handle.c,v retrieving revision 1.26 diff -d -u -r1.26 handle.c --- server/handle.c 19 Feb 2003 00:33:33 -0000 1.26 +++ server/handle.c 18 Apr 2003 17:41:19 -0000 @@ -397,6 +397,17 @@ return entry->fd; } +/* invalidate the cached fd for a given handle */ +void invalidate_handle_unix_fd( struct process *process, obj_handle_t handle ) +{ + struct handle_entry *entry; + + entry = get_handle( process, handle ); + /*fprintf(stderr, "invalidate_handle_unix_fd: handle %d, clearing client unix process fd %d\n", (int)handle, entry->fd);*/ + if (entry) + entry->fd = -1; +} + /* find the first inherited handle of the given type */ /* this is needed for window stations and desktops (don't ask...) */ obj_handle_t find_inherited_handle( struct process *process, const struct object_ops *ops ) Index: server/named_pipe.c =================================================================== RCS file: /home/wine/wine/server/named_pipe.c,v retrieving revision 1.22 diff -d -u -r1.22 named_pipe.c --- server/named_pipe.c 4 Apr 2003 22:26:34 -0000 1.22 +++ server/named_pipe.c 18 Apr 2003 17:41:19 -0000 @@ -48,12 +48,13 @@ enum pipe_state { ps_none, - ps_idle_server, - ps_wait_open, - ps_wait_connect, + ps_fresh_server, /* server after create, before first connect */ + ps_idle_server, /* server after disconnect */ + ps_wait_open, /* server during ConnectNamedPipe() wait */ + ps_wait_connect, /* client during WaitNamedPipe() */ ps_connected_server, ps_connected_client, - ps_disconnected + ps_disconnected, /* client after disconnect */ }; struct named_pipe; @@ -62,6 +63,7 @@ { struct object obj; struct fd *fd; + struct fd *fd_for_peer; enum pipe_state state; struct pipe_user *other; struct named_pipe *pipe; @@ -103,6 +105,7 @@ static void pipe_user_destroy( struct object *obj); static int pipe_user_get_poll_events( struct fd *fd ); +static int pipe_user_flush( struct fd *fd ); static int pipe_user_get_info( struct fd *fd, struct get_file_info_reply *reply, int *flags ); static const struct object_ops pipe_user_ops = @@ -121,7 +124,7 @@ { pipe_user_get_poll_events, /* get_poll_events */ default_poll_event, /* poll_event */ - no_flush, /* flush */ + pipe_user_flush, /* flush */ pipe_user_get_info, /* get_file_info */ no_queue_async /* queue_async */ }; @@ -163,6 +166,8 @@ static struct fd *pipe_user_get_fd( struct object *obj ) { struct pipe_user *user = (struct pipe_user *)obj; + if (!user->fd) + return NULL; return (struct fd *)grab_object( user->fd ); } @@ -177,15 +182,20 @@ if(user->other) { - release_object( user->other->fd ); - user->other->fd = NULL; switch(user->other->state) { case ps_connected_server: user->other->state = ps_idle_server; + release_object( user->other->fd ); + user->other->fd = NULL; break; case ps_connected_client: user->other->state = ps_disconnected; + if (user->fd) { + user->other->fd_for_peer = user->fd; + set_fd_user(user->fd, &user->other->obj); + user->fd = NULL; + } break; default: fprintf(stderr,"connected pipe has strange state %d!\n", @@ -202,6 +212,7 @@ if (user->thread) release_object(user->thread); release_object(user->pipe); if (user->fd) release_object( user->fd ); + if (user->fd_for_peer) release_object(user->fd_for_peer); } static int pipe_user_get_poll_events( struct fd *fd ) @@ -209,6 +220,14 @@ return POLLIN | POLLOUT; /* FIXME */ } +static int pipe_user_flush( struct fd *fd ) +{ + /* Pretend we work. We don't, but the fact that we don't + * destroy contents on disconnect makes up for it in most cases. + */ + return 0; +} + static int pipe_user_get_info( struct fd *fd, struct get_file_info_reply *reply, int *flags ) { if (reply) @@ -273,6 +292,7 @@ return NULL; user->fd = NULL; + user->fd_for_peer = NULL; user->pipe = pipe; user->state = ps_none; user->other = NULL; @@ -290,13 +310,14 @@ return user; } -static struct pipe_user *find_partner(struct named_pipe *pipe, enum pipe_state state) +/* Find a pipe_user in any of the given states */ +static struct pipe_user *_find_partner(struct named_pipe *pipe, int states) { struct pipe_user *x; for(x = pipe->users; x; x=x->next) { - if(x->state==state) + if((1 << x->state) & states) break; } @@ -306,6 +327,12 @@ return (struct pipe_user *)grab_object( x ); } +/* Find a pipe_user in the given state */ +static inline struct pipe_user *find_partner(struct named_pipe *pipe, enum pipe_state s) +{ + return _find_partner(pipe, 1<<s); +} + DECL_HANDLER(create_named_pipe) { struct named_pipe *pipe; @@ -329,7 +356,14 @@ if(user) { - user->state = ps_idle_server; + int fds[2]; + user->state = ps_fresh_server; + if (!socketpair(PF_UNIX, SOCK_STREAM, 0, fds)) + { + user->fd = create_anonymous_fd( &pipe_user_fd_ops, fds[1], &user->obj ); + user->fd_for_peer = create_anonymous_fd( &pipe_user_fd_ops, fds[0], &user->obj ); + /* fprintf(stderr, "create_named_pipe: user %p, created fd %p, created fd_for_peer %p\n", user, user->fd, user->fd_for_peer); */ + } reply->handle = alloc_handle( current->process, user, GENERIC_READ|GENERIC_WRITE, 0 ); release_object( user ); } @@ -349,7 +383,7 @@ set_error( STATUS_NO_SUCH_FILE ); return; } - if (!(partner = find_partner(pipe, ps_wait_open))) + if (!(partner = _find_partner(pipe, (1<<ps_wait_open) | (1<<ps_fresh_server)))) { release_object(pipe); set_error( STATUS_PIPE_NOT_AVAILABLE ); @@ -359,22 +393,36 @@ { int fds[2]; - if(!socketpair(PF_UNIX, SOCK_STREAM, 0, fds)) - { - user->fd = create_anonymous_fd( &pipe_user_fd_ops, fds[1], &user->obj ); - partner->fd = create_anonymous_fd( &pipe_user_fd_ops, fds[0], &partner->obj ); - if (user->fd && partner->fd) - { - notify_waiter(partner,STATUS_SUCCESS); - partner->state = ps_connected_server; - partner->other = user; - user->state = ps_connected_client; - user->other = partner; - reply->handle = alloc_handle( current->process, user, req->access, 0 ); - } - } - else file_set_error(); + if (partner->fd_for_peer != NULL) { + /* Server side is fresh, so it already created the fds. + * Grab the fd it created for us, and set its user (since + * it couldn't know ahead of time). + */ + user->fd = partner->fd_for_peer; + partner->fd_for_peer = NULL; + set_fd_user(user->fd, &user->obj); + /* fprintf(stderr, "open_named_pipe: user %p grabbing fd %p from partner %p\n", user, user->fd, partner); */ + } else if (!socketpair(PF_UNIX, SOCK_STREAM, 0, fds)) { + /* Server side isn't fresh, so we have to create the fds for + * both sides. + */ + user->fd = create_anonymous_fd( &pipe_user_fd_ops, fds[1], &user->obj ); + partner->fd = create_anonymous_fd( &pipe_user_fd_ops, fds[0], &partner->obj ); + /* fprintf(stderr, "open_named_pipe: user %p, created fd %p, created fd %p for partner %p\n", user, user->fd, partner->fd, partner); */ + } else + file_set_error(); + if (user->fd && partner->fd) + { + enum pipe_state old_partner_state = partner->state; + partner->state = ps_connected_server; + partner->other = user; + user->state = ps_connected_client; + user->other = partner; + reply->handle = alloc_handle( current->process, user, req->access, 0 ); + if (old_partner_state == ps_wait_open) + notify_waiter(partner,STATUS_SUCCESS); + } release_object( user ); } release_object( partner ); @@ -389,7 +437,7 @@ if(!user) return; - if( user->state != ps_idle_server ) + if( (user->state & (ps_idle_server|ps_fresh_server)) == 0 ) { set_error(STATUS_PORT_ALREADY_SET); } @@ -455,16 +503,28 @@ if( (user->state == ps_connected_server) && (user->other->state == ps_connected_client) ) { - release_object( user->other->fd ); + /* This duplicates a fair bit of code from the destroy method */ + if (user->fd) { + /* fprintf(stderr, "disconnect_named_pipe: user %p passing fd %p to partner %p\n", user, user->fd, user->other); */ + user->other->fd_for_peer = user->fd; + set_fd_user(user->fd, &user->other->obj); + user->fd = NULL; + } user->other->fd = NULL; user->other->state = ps_disconnected; user->other->other = NULL; - - release_object( user->fd ); - user->fd = NULL; - user->state = ps_idle_server; user->other = NULL; + user->state = ps_idle_server; } + + /* IMPOSSIBLE PART: invalidate the cached unix fd for all + * handles that refer to user. + * We can only do it for the handle we were passed, + * so this will only work if that handle has no duplicate. + * FIXME: find out what happens to a handle in win32 when you + * disconnect a duplicate of it. + */ + invalidate_handle_unix_fd(current->process, req->handle); release_object(user); } Index: dlls/kernel/tests/pipe.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/pipe.c,v retrieving revision 1.2 diff -d -u -r1.2 pipe.c --- dlls/kernel/tests/pipe.c 25 Feb 2003 03:56:43 -0000 1.2 +++ dlls/kernel/tests/pipe.c 18 Apr 2003 17:41:20 -0000 @@ -21,23 +21,40 @@ #include <stdlib.h> #include <stdio.h> #include <time.h> +#include <assert.h> + +#include <wtypes.h> +#include <windef.h> +#include <winbase.h> +#include <winerror.h> #ifndef STANDALONE #include "wine/test.h" +#define trace2(a,b) trace((a),(b)) #else #include <assert.h> #define START_TEST(name) main(int argc, char **argv) #define ok(condition, msg) assert(condition) -#define todo_wine +#define todo_wine if (0) +static void trace2(const char *s, const char *t) +{ + DWORD cbWritten; + char buf[512]; + sprintf(buf, s, t); + WriteFile(GetStdHandle(STD_ERROR_HANDLE), buf, strlen(buf), &cbWritten, NULL); +} +static void trace(const char *s) +{ + DWORD cbWritten; + char buf[512]; + sprintf(buf, "%s", s); + WriteFile(GetStdHandle(STD_ERROR_HANDLE), buf, strlen(buf), &cbWritten, NULL); +} #endif -#include <wtypes.h> -#include <windef.h> -#include <winbase.h> -#include <winerror.h> - #define PIPENAME "\\\\.\\PiPe\\tests_" __FILE__ + void test_CreateNamedPipeA(void) { HANDLE hnp; @@ -45,8 +62,9 @@ const char obuf[] = "Bit Bucket"; char ibuf[32]; DWORD written; - DWORD gelesen; + DWORD nbytes_read; + trace("test_CreateNamedPipe starting\n"); /* Bad parameter checks */ hnp = CreateNamedPipeA("not a named pipe", PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE|PIPE_WAIT, @@ -86,10 +104,8 @@ /* lpSecurityAttrib */ NULL); ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); - hFile = CreateFileA(PIPENAME, GENERIC_READ|GENERIC_WRITE, 0, - NULL, OPEN_EXISTING, 0, 0); - todo_wine - { + hFile = CreateFileA(PIPENAME, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, 0); + todo_wine { ok(hFile != INVALID_HANDLE_VALUE, "CreateFile failed"); } @@ -101,15 +117,15 @@ memset(ibuf, 0, sizeof(ibuf)); ok(WriteFile(hnp, obuf, sizeof(obuf), &written, NULL), "WriteFile"); ok(written == sizeof(obuf), "write file len"); - ok(ReadFile(hFile, ibuf, sizeof(obuf), &gelesen, NULL), "ReadFile"); - ok(gelesen == sizeof(obuf), "read file len"); + ok(ReadFile(hFile, ibuf, sizeof(obuf), &nbytes_read, NULL), "ReadFile"); + ok(nbytes_read == sizeof(obuf), "read file len"); ok(memcmp(obuf, ibuf, written) == 0, "content check"); memset(ibuf, 0, sizeof(ibuf)); ok(WriteFile(hFile, obuf, sizeof(obuf), &written, NULL), "WriteFile"); ok(written == sizeof(obuf), "write file len"); - ok(ReadFile(hnp, ibuf, sizeof(obuf), &gelesen, NULL), "ReadFile"); - ok(gelesen == sizeof(obuf), "read file len"); + ok(ReadFile(hnp, ibuf, sizeof(obuf), &nbytes_read, NULL), "ReadFile"); + ok(nbytes_read == sizeof(obuf), "read file len"); ok(memcmp(obuf, ibuf, written) == 0, "content check"); /* Picky conformance tests */ @@ -148,9 +164,460 @@ } ok(CloseHandle(hnp), "CloseHandle"); + + trace("test_CreateNamedPipe returning\n"); +} + +void test_CreateNamedPipe_instances_must_match(void) +{ + HANDLE hnp, hnp2; + + /* Check no mismatch */ + hnp = CreateNamedPipeA(PIPENAME, PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 2, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + hnp2 = CreateNamedPipeA(PIPENAME, PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 2, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp2 != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + ok(CloseHandle(hnp), "CloseHandle"); + ok(CloseHandle(hnp2), "CloseHandle"); + + /* Check nMaxInstances */ + hnp = CreateNamedPipeA(PIPENAME, PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 1, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + todo_wine { + hnp2 = CreateNamedPipeA(PIPENAME, PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 1, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp2 == INVALID_HANDLE_VALUE + && GetLastError() == ERROR_PIPE_BUSY, "nMaxInstances not obeyed"); + } + + ok(CloseHandle(hnp), "CloseHandle"); + + /* Check PIPE_ACCESS_* */ + hnp = CreateNamedPipeA(PIPENAME, PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 2, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + todo_wine { + hnp2 = CreateNamedPipeA(PIPENAME, PIPE_ACCESS_INBOUND, PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 1, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp2 == INVALID_HANDLE_VALUE + && GetLastError() == ERROR_ACCESS_DENIED, "PIPE_ACCESS_* mismatch allowed"); + } + + /* etc, etc */ +} + +/** implementation of alarm() */ +static DWORD CALLBACK alarmThreadMain(LPVOID arg) +{ + DWORD timeout = (DWORD) arg; + trace("alarmThreadMain\n"); + Sleep(timeout); + ok(FALSE, "alarm"); + ExitProcess(1); + return 1; +} + +HANDLE hnp = INVALID_HANDLE_VALUE; + +/** Trivial byte echo server - disconnects after each session */ +static DWORD CALLBACK serverThreadMain1(LPVOID arg) +{ + int i; + + trace("serverThreadMain1 start\n"); + /* Set up a simple echo server */ + hnp = CreateNamedPipeA(PIPENAME "serverThreadMain1", PIPE_ACCESS_DUPLEX, + PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 1, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + for (i = 0; ; i++) { + char buf[512]; + DWORD written; + DWORD nbytes_read; + DWORD success; + + /* Wait for client to connect */ + trace("Server calling ConnectNamedPipe...\n"); + ok(ConnectNamedPipe(hnp, NULL) + || GetLastError() == ERROR_PIPE_CONNECTED, "ConnectNamedPipe"); + trace("ConnectNamedPipe returned.\n"); + + /* Echo bytes once */ + memset(buf, 0, sizeof(buf)); + + trace("Server reading...\n"); + success = ReadFile(hnp, buf, sizeof(buf), &nbytes_read, NULL); + trace("Server done reading.\n"); + ok(success, "ReadFile"); + trace2("Server read '%s'\n", buf); + ok(memcmp(buf, "client->server", 14) == 0, "content check"); + + trace("Server writing...\n"); + sprintf(buf, "server->client i %d ", i); + ok(WriteFile(hnp, buf, nbytes_read, &written, NULL), "WriteFile"); + trace("Server done writing.\n"); + ok(written == nbytes_read, "write file len"); + + /* finish this connection, wait for next one */ + trace("Server flushing.\n"); + todo_wine { + ok(FlushFileBuffers(hnp), "FlushFileBuffers"); + } + trace("Server disconnecting.\n"); + ok(DisconnectNamedPipe(hnp), "DisconnectNamedPipe"); + } +} + +/** Trivial byte echo server - closes after each connection */ +static DWORD CALLBACK serverThreadMain2(LPVOID arg) +{ + int i; + HANDLE hnpNext = 0; + + trace("serverThreadMain2\n"); + /* Set up a simple echo server */ + hnp = CreateNamedPipeA(PIPENAME "serverThreadMain2", PIPE_ACCESS_DUPLEX, + PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 2, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + for (i = 0; ; i++) { + char buf[512]; + DWORD written; + DWORD nbytes_read; + DWORD success; + + /* Wait for client to connect */ + trace("Server calling ConnectNamedPipe...\n"); + ok(ConnectNamedPipe(hnp, NULL) + || GetLastError() == ERROR_PIPE_CONNECTED, "ConnectNamedPipe"); + trace("ConnectNamedPipe returned.\n"); + + /* Echo bytes once */ + memset(buf, 0, sizeof(buf)); + + trace("Server reading...\n"); + success = ReadFile(hnp, buf, sizeof(buf), &nbytes_read, NULL); + trace("Server done reading.\n"); + ok(success, "ReadFile"); + + trace("Server writing...\n"); + ok(WriteFile(hnp, buf, nbytes_read, &written, NULL), "WriteFile"); + trace("Server done writing.\n"); + ok(written == nbytes_read, "write file len"); + + /* finish this connection, wait for next one */ + trace("Server flushing.\n"); + todo_wine { ok( FlushFileBuffers(hnp), "FlushFileBuffers"); } + trace("Server disconnecting.\n"); + ok(DisconnectNamedPipe(hnp), "DisconnectNamedPipe"); + + /* Set up next echo server */ + hnpNext = + CreateNamedPipeA(PIPENAME "serverThreadMain2", PIPE_ACCESS_DUPLEX, + PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 2, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + + ok(hnpNext != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + ok(CloseHandle(hnp), "CloseHandle"); + hnp = hnpNext; + } +} + +/** Trivial byte echo server - uses overlapped named pipe calls */ +static DWORD CALLBACK serverThreadMain3(LPVOID arg) +{ + int i; + HANDLE hEvent; + + trace("serverThreadMain3\n"); + /* Set up a simple echo server */ + hnp = CreateNamedPipeA(PIPENAME "serverThreadMain3", PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED, + PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 1, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + hEvent = CreateEvent(NULL, // security attribute + TRUE, // manual reset event + FALSE, // initial state + NULL); // name + ok(hEvent != NULL, "CreateEvent"); + + for (i = 0; ; i++) { + char buf[512]; + DWORD written; + DWORD nbytes_read; + DWORD dummy; + DWORD success; + OVERLAPPED oOverlap; + int letWFSOEwait = (i & 2); + int letGORwait = (i & 1); + DWORD err; + + memset(&oOverlap, 0, sizeof(oOverlap)); + oOverlap.hEvent = hEvent; + + /* Wait for client to connect */ + trace("Server calling overlapped ConnectNamedPipe...\n"); + success = ConnectNamedPipe(hnp, &oOverlap); + err = GetLastError(); + ok(success || err == ERROR_IO_PENDING + || err == ERROR_PIPE_CONNECTED, "overlapped ConnectNamedPipe"); + trace("overlapped ConnectNamedPipe returned.\n"); + if (!success && (err == ERROR_IO_PENDING) && letWFSOEwait) + ok(WaitForSingleObjectEx(hEvent, INFINITE, TRUE) == 0, "wait ConnectNamedPipe"); + success = GetOverlappedResult(hnp, &oOverlap, &dummy, letGORwait); + if (!letGORwait && !letWFSOEwait && !success) { + ok(GetLastError() == ERROR_IO_INCOMPLETE, "GetOverlappedResult"); + success = GetOverlappedResult(hnp, &oOverlap, &dummy, TRUE); + } + ok(success, "GetOverlappedResult ConnectNamedPipe"); + trace("overlapped ConnectNamedPipe operation complete.\n"); + + /* Echo bytes once */ + memset(buf, 0, sizeof(buf)); + + trace("Server reading...\n"); + success = ReadFile(hnp, buf, sizeof(buf), NULL, &oOverlap); + trace("Server ReadFile returned...\n"); + err = GetLastError(); + ok(success || err == ERROR_IO_PENDING, "overlapped ReadFile"); + trace("overlapped ReadFile returned.\n"); + if (!success && (err == ERROR_IO_PENDING) && letWFSOEwait) + ok(WaitForSingleObjectEx(hEvent, INFINITE, TRUE) == 0, "wait ReadFile"); + success = GetOverlappedResult(hnp, &oOverlap, &nbytes_read, letGORwait); + if (!letGORwait && !letWFSOEwait && !success) { + ok(GetLastError() == ERROR_IO_INCOMPLETE, "GetOverlappedResult"); + success = GetOverlappedResult(hnp, &oOverlap, &nbytes_read, TRUE); + } + trace("Server done reading.\n"); + ok(success, "overlapped ReadFile"); + + trace("Server writing...\n"); + success = WriteFile(hnp, buf, nbytes_read, NULL, &oOverlap); + trace("Server WriteFile returned...\n"); + err = GetLastError(); + ok(success || err == ERROR_IO_PENDING, "overlapped WriteFile"); + trace("overlapped WriteFile returned.\n"); + if (!success && (err == ERROR_IO_PENDING) && letWFSOEwait) + ok(WaitForSingleObjectEx(hEvent, INFINITE, TRUE) == 0, "wait WriteFile"); + success = GetOverlappedResult(hnp, &oOverlap, &written, letGORwait); + if (!letGORwait && !letWFSOEwait && !success) { + ok(GetLastError() == ERROR_IO_INCOMPLETE, "GetOverlappedResult"); + success = GetOverlappedResult(hnp, &oOverlap, &written, TRUE); + } + trace("Server done writing.\n"); + ok(success, "overlapped WriteFile"); + ok(written == nbytes_read, "write file len"); + + /* finish this connection, wait for next one */ + trace("Server flushing.\n"); + todo_wine { ok( FlushFileBuffers(hnp), "FlushFileBuffers"); } + trace("Server disconnecting.\n"); + ok(DisconnectNamedPipe(hnp), "DisconnectNamedPipe"); + } +} + +static void exercizeServer(const char *pipename, HANDLE serverThread) +{ + int i; + DWORD success; + + trace("exercizeServer starting\n"); + for (i = 0; i < 8; i++) { + HANDLE hFile; + char obuf[32]; + char ibuf[32]; + DWORD written; + DWORD nbytes_read; + int loop; + + for (loop = 0; loop < 3; loop++) { + DWORD err; + trace("Client connecting...\n"); + /* Connect to the server */ + hFile = CreateFileA(pipename, GENERIC_READ | GENERIC_WRITE, 0, + NULL, OPEN_EXISTING, 0, 0); + if (hFile != INVALID_HANDLE_VALUE) + break; + err = GetLastError(); + if (loop == 0) + ok(err == ERROR_PIPE_BUSY || err == ERROR_FILE_NOT_FOUND, "connecting to pipe"); + else + ok(err == ERROR_PIPE_BUSY, "connecting to pipe"); + trace("connect failed, retrying\n"); + Sleep(200); + } + ok(hFile != INVALID_HANDLE_VALUE, "client opening named pipe"); + + /* Make sure it can echo */ + memset(ibuf, 0, sizeof(ibuf)); + sprintf(obuf, "client->server i %d ", i); + trace2("Client writing '%s'...\n", obuf); + ok(WriteFile(hFile, obuf, sizeof(obuf), &written, NULL), "WriteFile to client end of pipe"); + ok(written == sizeof(obuf), "write file len"); + trace("Client reading...\n"); + success = ReadFile(hFile, ibuf, sizeof(ibuf), &nbytes_read, NULL); + if (!success) + printf("ReadFile(%p, %p, %d,,0) failed, err %ld\n", hFile, ibuf, sizeof(ibuf), GetLastError()); + trace2("Client read '%s'\n", ibuf); + ok(success, "ReadFile from client end of pipe"); + ok(nbytes_read == sizeof(obuf), "read file len"); + /*ok(memcmp(obuf, ibuf, written) == 0, "content check");*/ + + trace("Client closing...\n"); + ok(CloseHandle(hFile), "CloseHandle"); + } + + ok(TerminateThread(serverThread, 0), "TerminateThread"); + CloseHandle(hnp); + trace("exercizeServer returning\n"); +} + +void test_NamedPipe_2(void) +{ + HANDLE serverThread; + DWORD serverThreadId; + HANDLE alarmThread; + DWORD alarmThreadId; + + trace("test_NamedPipe_2 starting\n"); + /* Set up a ten second timeout */ + alarmThread = CreateThread(NULL, 0, alarmThreadMain, (void *) 10000, 0, &alarmThreadId); + + /* The servers we're about to exercize do try to clean up carefully, + * but to reduce the change of a test failure due to a pipe handle + * leak in the test code, we'll use a different pipe name for each server. + */ + + trace("Try server #1\n"); + serverThread = CreateThread(NULL, 0, serverThreadMain1, 0, 0, &serverThreadId); + ok(serverThread != INVALID_HANDLE_VALUE, "CreateThread"); + exercizeServer(PIPENAME "serverThreadMain1", serverThread); + + trace("Try server #2\n"); + serverThread = CreateThread(NULL, 0, serverThreadMain2, 0, 0, &serverThreadId); + ok(serverThread != INVALID_HANDLE_VALUE, "CreateThread"); + exercizeServer(PIPENAME "serverThreadMain2", serverThread); + + todo_wine { + trace("Try server #3\n"); + serverThread = CreateThread(NULL, 0, serverThreadMain3, 0, 0, &serverThreadId); + ok(serverThread != INVALID_HANDLE_VALUE, "CreateThread"); + exercizeServer(PIPENAME "serverThreadMain3", serverThread); + + ok(TerminateThread(alarmThread, 0), "TerminateThread"); + trace("test_NamedPipe_2 returning\n"); + } +} + +void test_DisconnectNamedPipe(void) +{ + HANDLE hnp; + HANDLE hFile; + const char obuf[] = "Bit Bucket"; + char ibuf[32]; + DWORD written; + DWORD nbytes_read; + + hnp = CreateNamedPipeA(PIPENAME, PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE | PIPE_WAIT, + /* nMaxInstances */ 1, + /* nOutBufSize */ 1024, + /* nInBufSize */ 1024, + /* nDefaultWait */ NMPWAIT_USE_DEFAULT_WAIT, + /* lpSecurityAttrib */ NULL); + ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + + ok(WriteFile(hnp, obuf, sizeof(obuf), &written, NULL) == 0 + && GetLastError() == ERROR_PIPE_LISTENING, "WriteFile to not-yet-connected pipe"); + ok(ReadFile(hnp, ibuf, sizeof(ibuf), &nbytes_read, NULL) == 0 + && GetLastError() == ERROR_PIPE_LISTENING, "ReadFile from not-yet-connected pipe"); + + hFile = CreateFileA(PIPENAME, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, 0); + todo_wine { + ok(hFile != INVALID_HANDLE_VALUE, "CreateFile failed"); + } + + /* don't try to do i/o if one side couldn't be opened, as it hangs */ + if (hFile != INVALID_HANDLE_VALUE) { + + /* see what happens if server calls DisconnectNamedPipe + * when there are bytes in the pipe + */ + + ok(WriteFile(hFile, obuf, sizeof(obuf), &written, NULL), "WriteFile"); + ok(written == sizeof(obuf), "write file len"); + ok(DisconnectNamedPipe(hnp), "DisconnectNamedPipe while messages waiting"); + ok(WriteFile(hFile, obuf, sizeof(obuf), &written, NULL) == 0 + && GetLastError() == ERROR_PIPE_NOT_CONNECTED, "WriteFile to disconnected pipe"); + ok(ReadFile(hnp, ibuf, sizeof(ibuf), &nbytes_read, NULL) == 0 + && GetLastError() == ERROR_PIPE_NOT_CONNECTED, + "ReadFile from disconnected pipe with bytes waiting"); + ok(CloseHandle(hFile), "CloseHandle"); + } + + ok(CloseHandle(hnp), "CloseHandle"); + } START_TEST(pipe) { + trace("test 1 of 4:\n"); test_CreateNamedPipeA(); + trace("test 2 of 4:\n"); + test_CreateNamedPipe_instances_must_match(); + trace("test 3 of 4:\n"); + test_NamedPipe_2(); + trace("test 4 of 4:\n"); + test_DisconnectNamedPipe(); + trace("all tests done\n"); }

1 0

winelib on sparc?
by Robert Reif 18 Apr '03

18 Apr '03

I would like to do some winelib programming on a sparc and I'm struggling with a few concepts. winelib and wine are the same sources? When you build and run the tests in wine, are the tests really winelib apps? Has anyone really done this? The docs just say "uncharted territory" and don't go any further. I added code for my architecture and compile the wine source but get assembler errors on the spec files. Any help would be welcomed. Thanks, Bob.

1 0

Bug Hunting - uninstaller.exe on Win2K with uninstall information.
by Steven Edwards 18 Apr '03

18 Apr '03

Hello Everyone, This bug is a year+ old and I have not done much work on it untill now as I never could debug the stupid thing. This has always bothered me because this program should work fine under Win2K if we are compatible with the registry APIs and such. Does anyone have a idea as to what is going on? Here is the info from bug 1395 in bugzilla When running uninstaller built from Mingw or MS-VC++ 6 under Win2K the application seems to work and run fine when there is no information in the uninstall branch of the registry. As soon as a program is registered and uninstaller is run the program crashes. This has been tested on 3 systems and with many differnt sources and versions of Mingw. When debugging under MSVC with uninstall information in the registry the debugger stops at this code. FetchUninstallInformation() Line 225/226: entries[numentries-1].key = HeapAlloc(GetProcessHeap(), 0, strlen(subKeyName)+1); Entries : Cxx0030: Expression could not be evaluated I will attach a Visual Stdio build with sources/debugging information this evening. Thanks Steven

1 0

Re: remove server silliniess
by Bill Medland 18 Apr '03

18 Apr '03

On April 16, 2003 01:51 pm, Gregory M. Turner wrote: > remove run-time checks of compile-time constants. Why is that a silliness? I dearly wish that there were a way of doing compile-time assertion, but there isn't, so it has to be done by a runtime assertion. So it adds a tiny amount to the runtime. If that really bugs you then create a function of compile-time assertions and ensure that it gets called once only. Personally considering the current status of wine and the way we have to work on code that we don't really understand I am surprised at how few assertions there are (and lets not get started on internal code documentation) Or are you saying that assertions are a waste of time :-) -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

5 5

Re: docu: remove uber document
by Francois Gouget 18 Apr '03

18 Apr '03

On Thu, 17 Apr 2003, Dimitrie O. Paun wrote: [...] > Index: documentation/architecture.sgml > =================================================================== > RCS file: /home/wine/wine/documentation/architecture.sgml,v > retrieving revision 1.6 > diff -u -r1.6 architecture.sgml > --- documentation/architecture.sgml 1 Apr 2003 03:26:13 -0000 1.6 > +++ documentation/architecture.sgml 17 Apr 2003 22:09:52 -0000 > @@ -1029,6 +1029,5 @@ >  IMHO, rather than removing these lines, it would be better to modify them to attach the file to the proper book: wine-user.sgml or winelib-user.sgml. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ f u kn rd ts, ur wy 2 gky 4 ur wn gd.

2 2

Re: rpc server patch
by Gregory M. Turner 18 Apr '03

18 Apr '03

On Thursday 17 April 2003 09:36 pm, Ove Kaaven wrote: > diff -u -r1.12 rpc_server.c > --- dlls/rpcrt4/rpc_server.c 18 Apr 2003 02:04:17 -0000 1.12 > +++ dlls/rpcrt4/rpc_server.c 18 Apr 2003 02:16:51 -0000 > @@ -285,11 +286,18 @@ > > static void RPCRT4_new_client(RpcConnection* conn) > { > - conn->thread = CreateThread(NULL, 0, RPCRT4_io_thread, conn, 0, NULL); > - if (!conn->thread) { > + HANDLE thread = CreateThread(NULL, 0, RPCRT4_io_thread, conn, 0, NULL); > + if (!thread) { > DWORD err = GetLastError(); > ERR("failed to create thread, error=%08lx\n", err); > + RPCRT4_DestroyConnection(conn); > } > + /* we could set conn->thread, but then we'd have to make the io_thread wait > + * for that, otherwise the thread might finish, destroy the connection, and > + * free the memory we'd write to before we did, causing crashes and stuff - > + * so let's implement that later, when we really need conn->thread */ > + > + CloseHandle( thread ); > } > > static DWORD CALLBACK RPCRT4_server_thread(LPVOID the_arg) great, I don't understand this underlying pipe issue yet, but somehow, I'm betting this was just what the doctor ordered to get RPC back in on its feet ... thanks! btw, if you have kludgy patches that you would like to get back to wine, I reccomend you post them to wine-devel, which differentiates "not ready" from "ready" patches (that's just how I do it -- for all I know, this might contradict some official guideline). -- gmt "Democracy is the theory that holds that the common people know what they want, and deserve to get it good and hard." HL Mencken

1 0

Re: remove server silliniess
by John K. Hohm 18 Apr '03

18 Apr '03

Thus spake "Gregory M. Turner" <gmturner007(a)ameritech.net>: > ah, the hidden powers of the preprocessor -- how it drives us to obsfucation > with it's robotic stupidity... I wonder, is cpp a turing machine? Makes me > want to implement vim as a sed script ;) I don't think so. However, the C++ compile-time template mechanism *is* a turing machine (proof omitted). That is a persuasive argument, but I'm not sure if it's for or against C++.

1 0

winecfg kickoff
by Dimitrie O. Paun 17 Apr '03

17 Apr '03

Hi Alexandre, I have a little (and hopefully not too controversial :) suggesting on how to kickoff our little winecfg utility. Namely, we need to get the load/save from/to registry code going. To do so, we need the regisry key structure in place. Item C1 says "Merge configuration into the registry": http://www.dssd.ca/wine/Wine-0.9-TODO.html#conf So here's my proposal: 1. Do C1 now, but keep the current configuration in place 2. Label the conf file in CVS, to know when we merged it 3. Work on winecfg to load/save stuff properly 4. When done, compare the current version of the conf file with the labeled one, to see what's changed. 5. Adapt winecfg to the new changes 6. Drop the old config file Now, if this sounds like a plan, I was hopeing you could do (1) & (2) as it seems you have an idea where things should end up :) (and because only you can label stuff in CVS). Hopefully people will pick up on (3), if not I guess I can take a look, time permitting. -- Dimi.

2 1

Re: my dmusic and dpnhpast work, revised and resent
by Alexandre Julliard 17 Apr '03

17 Apr '03

"Rok Mandeljc" <rokmandeljc(a)hotmail.com> writes: > I just found out that my dpnhpast patch doesn't apply to current cvs tree > (msvcrtd implementation changed Makefile.in and configure). This also mean > that dmusic patch I've sent won't apply either. So I'm sending it again, > this time in one patch. It *should* apply to (today's) cvs cleanly. I have applied all the new dlls, but not the dmusic stubs. I think you should try to group related interfaces in the same source file (and possibly merge some of the existing files too), we can't have 40 different source files for a stub dll. A dozen files is the maximum IMO. -- Alexandre Julliard julliard(a)winehq.com

5 8

Re: Set TZ environment variable when not set
by Rein Klazes 17 Apr '03

17 Apr '03

On Wed, 16 Apr 2003 21:05:28 +0200, you wrote: > Changelog: > memory/environ.c: build_environment > Set the TZ value to GMT0, if TZ is not set > > Synplify.exe from the Quicklogic FPGA suite refused to work with the demo > license. Setting TZ to any value made it work. GMT0 should be a good > approach. > > Awaiting the "flame war" about noise level for that silent change :-) Uwe, Some programs, like Agent email/news client that I use, check the existence of TZ before attempting other timezone API call's. With your patch Agent displays all times in UTC, which is not making me happy. A correct patch should take care of the local timezone and daylight saving. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 4

Re: Initialise tid in WIN_CreateDesktopWindow
by Alexandre Julliard 17 Apr '03

17 Apr '03

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > windows/win.c: WIN_CreateDesktopWindow > Initialise pWndDesktop->tid > > This makes the Xilinx command line tools run with ttydrv This is wrong, the desktop should not be owned by the current thread. What's the problem with Xilinx? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine/ files/dos_fs.c dlls/kernel/tests/file.c
by Uwe Bonnes 17 Apr '03

17 Apr '03

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)wine.codeweavers.com> writes: Alexandre> ChangeSet ID: 7890 CVSROOT: /opt/cvs-commit Module name: wine Alexandre> Changes by: julliard(a)wine.codeweavers.com 2003/04/16 21:10:04 Alexandre> Modified files: files : dos_fs.c dlls/kernel/tests: file.c Alexandre> Log message: Uwe Bonnes Alexandre> <bon(a)elektron.ikp.physik.tu-darmstadt.de> FindFirstFile on Alexandre> root directory should fail. Alexandre> Patch: http://cvs.winehq.com/patch.py?id=7890 @@ -1937,7 +1937,6 @@ UINT codepage; data->dwReserved0 = data->dwReserved1 = 0x0; - if (!lpFileName) return 0; if (lpFileName[0] == '\\' && lpFileName[1] == '\\') { ERR("UNC path name\n"); This first patch thunk wasn't in the patch I sent. Is this intentional? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: wine/include/msvcrt malloc.h
by Dimitrie O. Paun 17 Apr '03

17 Apr '03

On Wed, 16 Apr 2003, Alexandre Julliard wrote: > Log message: > Fixed alloca handling the way mingw does it (reported by Vincent > Béron). > #ifndef USE_MSVCRT_PREFIX > -static inline void* alloca(MSVCRT(size_t) i) { return _alloca(i); } > +# ifdef __GNUC__ > +# define _alloca(x) __builtin_alloca((x)) > +# define alloca(x) __builtin_alloca((x)) > +# endif > #endif /* USE_MSVCRT_PREFIX */ If we know it's GNUC, isn't it better to use the alias feature, so we don't run into problems with the macros, like we use to? -- Dimi.

2 1

RE: What happend to the Stdole2 / Stdole32 (RESEND) patch fromRobert Shearman
by Robert Shearman 17 Apr '03

17 Apr '03

> -----Original Message----- > From: Uwe Bonnes [mailto:bon@elektron.ikp.physik.tu-darmstadt.de] > Sent: 02 April 2003 14:40 > To: Robert Shearman > Subject: Re: What happend to the Stdole2 / Stdole32 (RESEND) patch > fromRobert Shearman > > > >>>>> "Robert" == Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > > >> what happend to the stdole32.tlb patch that Robert sent > around 22.1? > Robert> It was rejected on the grounds that we shouldn't have binary > Robert> files in CVS and we can't generate the .tlb files at > the moment. > > Did you generate the files from some source you wrote? Yes. > What compiler was used? MkTypLib from MS Platform SDK > What constraints are put on distributing those generated files? None, as far as I could tell. > The present need for stdole*.tlb from a windows installation is > unsatisfactory. Agreed. > Bye > > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Hope this helps and sorry for not getting back to you sooner, Rob

1 0

Winelib MFC?
by Christopher Thielen 17 Apr '03

17 Apr '03

Hello, I've written an application in MFC which runs beautifully in wine. I'd like to distribute a Winelib version, so Unix users don't need wine. Can I recompile MFC applications with Winelib? Is this possible? -- chris (chris(a)luethy.net)

3 4

wild pointers in current named pipe implementation?
by Dan Kegel 17 Apr '03

17 Apr '03

I know Mike is planning to rewrite the named pipe implementation, but the current implementation could use a little love while we're waiting for the new one. So I'm looking into the recent user complaint about FlushFileBuffers and named pipes, in hopes I can find a very simple patch that will tide us over until the new named pipes code is ready (whenever that might be; Mike's busy on other things at the moment). So I added an early call to FlushFileBuffers in the named pipe regression test (see attached patch). While poking around in wineserver, I found a few places where pointers were not set to NULL after being invalidated, and after I added the missing statements to set them to NULL, wineserver started behaving badly on the regression test. A run of wineserver under valgrind showed a null pointer access, so I added a couple null pointer check asserts (see attached patch). And sure enough, they fire. So the question is -- did I screw up, or did I uncover a real issue? The answer will help me as I continue digging into the FlushFileBuffers named pipe bug report (and testing possible simple enhancements to the current named pipe implementation). Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 Index: server/object.c =================================================================== RCS file: /home/wine/wine/server/object.c,v retrieving revision 1.27 diff -d -u -r1.27 object.c --- server/object.c 19 Feb 2003 00:33:33 -0000 1.27 +++ server/object.c 14 Apr 2003 16:59:45 -0000 @@ -193,6 +193,7 @@ struct object *grab_object( void *ptr ) { struct object *obj = (struct object *)ptr; + assert( obj ); assert( obj->refcount < INT_MAX ); obj->refcount++; return obj; Index: server/named_pipe.c =================================================================== RCS file: /home/wine/wine/server/named_pipe.c,v retrieving revision 1.22 diff -d -u -r1.22 named_pipe.c --- server/named_pipe.c 4 Apr 2003 22:26:34 -0000 1.22 +++ server/named_pipe.c 14 Apr 2003 16:59:45 -0000 @@ -163,6 +163,7 @@ static struct fd *pipe_user_get_fd( struct object *obj ) { struct pipe_user *user = (struct pipe_user *)obj; + assert(user->fd); return (struct fd *)grab_object( user->fd ); } @@ -200,8 +201,11 @@ if (user->prev) user->prev->next = user->next; else user->pipe->users = user->next; if (user->thread) release_object(user->thread); + user->thread = NULL; release_object(user->pipe); + user->pipe = NULL; if (user->fd) release_object( user->fd ); + user->fd = NULL; } static int pipe_user_get_poll_events( struct fd *fd ) Index: dlls/kernel/tests/pipe.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/pipe.c,v retrieving revision 1.2 diff -d -u -r1.2 pipe.c --- dlls/kernel/tests/pipe.c 25 Feb 2003 03:56:43 -0000 1.2 +++ dlls/kernel/tests/pipe.c 14 Apr 2003 16:59:45 -0000 @@ -86,6 +86,10 @@ /* lpSecurityAttrib */ NULL); ok(hnp != INVALID_HANDLE_VALUE, "CreateNamedPipe failed"); + if (!FlushFileBuffers(hnp)) { + /* we'll add a check here once we know how windows behaves */ + fprintf(stderr, "FlushFileBuffers on new pipe failed, err %d\n", GetLastError()); + } hFile = CreateFileA(PIPENAME, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, 0); todo_wine

5 14

Re: Duplicate messages
by Michal Janusz Miroslaw 17 Apr '03

17 Apr '03

> I receive duplicate messages with following headers. Could people please > look after their setup? It's my fault. Apologies for everyone. My fetchmail went crazy and I wasn't fast enough to stop it. :( -- Michal Miroslaw

1 0

Duplicate messages
by Uwe Bonnes 17 Apr '03

17 Apr '03

Hallo, I receive duplicate messages with following headers. Could people please look after their setup? Thanks Return-Path: <wine-devel-admin(a)winehq.com> Received: from mailserver2.hrz.tu-darmstadt.de (mailserver2.hrz.tu-darmstadt.de [130.83.22.129]) by elektron.ikp.physik.tu-darmstadt.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id h3HDs0j28561 for <bon(a)elektron.ikp.physik.tu-darmstadt.de>; Thu, 17 Apr 2003 15:54:00 +0200 Received: from ziemniak.ustronie.pw.edu.pl (czuby.resetnet.pl [62.233.189.254]) by mailserver2.hrz.tu-darmstadt.de (8.12.9/8.12.8) with ESMTP id h3HDqNdj008074 for <bon(a)elektron.ikp.physik.tu-darmstadt.de>; Thu, 17 Apr 2003 15:52:25 +0200 Received: (qmail 7122 invoked by uid 1000); 17 Apr 2003 13:56:56 -0000 Received: from mion.elka.pw.edu.pl [194.29.160.35] by localhost with IMAP (fetchmail-6.2.2) for mirq-forwarded@localhost (single-drop); Thu, 17 Apr 2003 15:56:55 +0200 (CEST) Received: from [198.144.4.3] ([198.144.4.3]:39372 "EHLO wine.codeweavers.com") by mion.elka.pw.edu.pl with ESMTP id <S318308AbTDQAbg>; Thu, 17 Apr 2003 02:31:36 +0200 Received: from localhost.localdomain (wine [127.0.0.1]) by wine.codeweavers.com (8.11.6/8.11.6) with ESMTP id h3H0BHG22385; Wed, 16 Apr 2003 19:11:17 -0500 Received: from mail.wine.dyndns.org (adsl-64-142-4-165.sonic.net [64.142.4.165]) by wine.codeweavers.com (8.11.6/8.11.6) with ESMTP id h3H0A5G22281 for <wine-devel(a)winehq.com>; Wed, 16 Apr 2003 19:10:05 -0500 -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: wineinstall: use pwd and drop ttydrv
by Steven Edwards 17 Apr '03

17 Apr '03

--- Vincent B�ron <vberon(a)mecano.gme.usherb.ca> wrote: > Testing as shown that either x11drv or ttydrv could be set, even without > X present, as long as the app doesn't use user or gdi. > Also, the second change allows to build from anywhere, not limited to > one of the pre-mapped drives. > > Changelog: > Don't change to ttydrv to install registry, regedit doesn't use X. > Make sure the current dir is mapped in DOS. regedit will use user32 and friends if the ReactOS changes are merged in. ATM our regedit is read only when you use the GUI but you can still use the command-line for writes. __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com

1 0

winsock.h portability patch causing portability problem
by Gerald Pfeifer 17 Apr '03

17 Apr '03

Alexandre, I am afraid the following patch revision 1.52 date: 2003/03/31 23:56:35; author: julliard; state: Exp; lines: +63 -60 Try to make winsock.h more portable (based on a patch by Francois Gouget). actually caused a portability problem for FreeBSD. /usr/bin/gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -gstabs+ -Wpointer-arith -fPIC -D_REENTRANT -o pipe.o pipe.c In file included from ../../../include/winsock2.h:47, from ../../../include/windows.h:62, from ../../../include/rpc.h:22, from ../../../include/wtypes.h:2, from pipe.c:34: ../../../include/winsock.h:925: conflicting types for `htonl' /usr/include/machine/endian.h:63: previous declaration of `htonl' ../../../include/winsock.h:926: conflicting types for `htons' /usr/include/machine/endian.h:64: previous declaration of `htons' ../../../include/winsock.h:927: conflicting types for `ntohl' /usr/include/machine/endian.h:65: previous declaration of `ntohl' ../../../include/winsock.h:928: conflicting types for `ntohs' /usr/include/machine/endian.h:66: previous declaration of `ntohs' gmake[3]: *** [pipe.o] Error 1 gmake[3]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/kernel/tests' gmake[2]: *** [tests] Error 2 gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/kernel' The FreeBSD declarations are unsigned long htonl __P((unsigned long)); unsigned short htons __P((unsigned short)); unsigned long ntohl __P((unsigned long)); unsigned short ntohs __P((unsigned short)); Sorry, Gerald

2 6

Re: Set TZ environment variable when not set
by Alexandre Julliard 17 Apr '03

17 Apr '03

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Changelog: > memory/environ.c: build_environment > Set the TZ value to GMT0, if TZ is not set > > Synplify.exe from the Quicklogic FPGA suite refused to work with the demo > license. Setting TZ to any value made it work. You should set it in your environment then, this doesn't belong in Wine. -- Alexandre Julliard julliard(a)winehq.com

4 4

RE: remove server silliniess
by Patrik Stridvall 17 Apr '03

17 Apr '03

> On Thursday 17 April 2003 02:13 am, Fabian Cenedese wrote: > > >> remove run-time checks of compile-time constants. > > > > > >I dearly wish that there were a way of doing compile-time > assertion, but > > > there isn't, so it has to be done by a runtime assertion. > > > > Well, there seem to be some reasonable tricks for that: > > http://www.jaggersoft.com/pubs/CVu11_3.html > > http://www.panelsoft.com/murphyslaw/apr01.htm > > > > This is for C++ but maybe also adaptable for C: > > http://www.boost.org/libs/static_assert/static_assert.htm > > > > bye Fabi > > ah, the hidden powers of the preprocessor -- how it drives us > to obsfucation > with it's robotic stupidity... I wonder, is cpp a turing > machine? I don't think so. > Makes me > want to implement vim as a sed script ;) :-) > nonetheless, considering one must sometimes make do with what > one has, that > array-of-zero trick is super-clever... perhaps I'll actually make a > constructive patch out of this debacle yet.. Note that Wine already have a macro for this that is not a Wine specific invention but is rather a feature of the Win32 API. >From include/winnt.h: /* Compile time assertion */ #if defined(_MSC_VER) # define C_ASSERT(e) typedef char __C_ASSERT__[(e)?1:-1] #elif defined(__GNUC__) # define C_ASSERT(e) extern char __C_ASSERT__[(e)?1:-1] #endif

1 0

winedbg regression?
by Mike Hearn 17 Apr '03

17 Apr '03

Hi, For the past week or so winedbg has refused to start, it just hangs whenever it tries to attach to a pid. Some traces indicate it's getting an access denied error when trying to attach? Not sure why i'd be getting that. I thought it was just my tree at first but Splinter on IRC says he has the same problem. Does anybody else see this?

6 9

Re: div in msvcrt
by Alexandre Julliard 17 Apr '03

17 Apr '03

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > This was in msvcrt/stdlib.h since version 1.1, probably straight from > mingw. It caused some problems because div_t is a structure, not a long > long (same thing for ldiv_t). > > Changelog: > Fixed the definition of div/ldiv. This won't work, the calling sequence on i386 is not compatible. I'm not sure there's a good solution for that one... -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Set TZ environment variable when not set
by Michael Stefaniuc 16 Apr '03

16 Apr '03

On Wed, Apr 16, 2003 at 09:05:28PM +0200, Uwe Bonnes wrote: > Changelog: > memory/environ.c: build_environment > Set the TZ value to GMT0, if TZ is not set > > Synplify.exe from the Quicklogic FPGA suite refused to work with the demo > license. Setting TZ to any value made it work. GMT0 should be a good > approach. > > Awaiting the "flame war" about noise level for that silent change :-) Well, can't help with that but we could start a new flame war about why UTC is better for this then GMT0. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

3 4

Re: Fallback to ttydrv (third attempt)
by Alexandre Julliard 16 Apr '03

16 Apr '03

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > Index: wine/dlls/user/user_main.c > =================================================================== > RCS file: /home/wine/wine/dlls/user/user_main.c,v > retrieving revision 1.50 > diff -u -r1.50 user_main.c > --- wine/dlls/user/user_main.c 3 Dec 2002 23:34:54 -0000 1.50 > +++ wine/dlls/user/user_main.c 15 Apr 2003 11:05:08 -0000 > { > count = sizeof(buffer); > RegQueryValueExA( hkey, "GraphicsDriver", 0, &type, buffer, &count ); > + count = sizeof(buffer2); > + RegQueryValueExA( hkey, "TTYdrvFallback", 0, &type, buffer2, &count ); > RegCloseKey( hkey ); > } > + > + if (!strcasecmp("x11drv",buffer) && > + (GetEnvironmentVariableA("DISPLAY",buffer1,MAX_PATH-1) == 0) && > + !strcasecmp("y",buffer2)) USER has no business checking the DISPLAY variable, that's an X11 thing. The right way to do this would be to make x11drv fail its initialization in that case, and have USER check for that. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: winedbg improvement - display
by Pouech Eric DMI AEI CAEN 16 Apr '03

16 Apr '03

> Objet : winedbg improvement - display > I've just hacked winedbg 'display' handling. It now allows for temporary > disabling of displays and restricting them to one function. Look for > yourselves, comments welcome. :) since I'm away from home on a poor remote connection, I couldn't spend much time on this from a first look, enable/disable facility is fine but, here are, at least, two remarks : - first, I don't think we should have two ways of expressing the same thing (like disable display 1 and display disable 1). IMO, we should stick the former form (as we currently do) (I agree that current undisplay 1 and delete display 1 are may be a bit overkill too) - secondly, and most important, I don't like storing the frame context in the display information. I don't see how you're going to ensure that we got a correct context for evaluating an expression. Keeping the local frame name isn't even sufficient when calling the same function recursively. What I'm afraid of here is the user's perception of this specific context for evaluation. I know gdb has some of those tricks (i.e. that no one, except the one who wrote the code, is going to understand what context is going to be used for evaluating the expression). I really wonder what gdb does here. A+

2 1

Re: remove server silliniess
by Alexandre Julliard 16 Apr '03

16 Apr '03

"Gregory M. Turner" <gmturner007(a)ameritech.net> writes: > remove run-time checks of compile-time constants. What's wrong with that? and how do you propose to do the check then? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: WineHQ: whitespace
by Jeremy Newman 16 Apr '03

16 Apr '03

On Tue, 2003-04-15 at 14:55, Dimitrie O. Paun wrote: > Jer, > > When you apply my patches, please try to no change the whitespace, as it > creates conflicts on my side, and I can't tell if you've changed anything. > > I think you applied my patches from Windows, and the line endings changed, > or something like that. Please don't accuse me of using Windows. I would never do such a thing. ;) The problem comes from copy/paste the patch from my email prog (Evolution) to my text editor (Anjuta). I my web code, I prefer to use 4 spaces for indenting, no tab characters please. Don't give me the spaces take more time to transfer over http crap, our web server uses gzip encoding. <g> The patch was rejected by the patch command, so I had to manually line by line apply it (ish). In the future, attachments will be preferred for patches. I may just decide to not apply them otherwise.

3 4

Re: Keyboard Problem solved, one solution ...
by Dmitry Timoshkov 16 Apr '03

16 Apr '03

"Duncan Rubinger" <duncan(a)semanticedge.de> wrote: > I have a german keyboard layout and I'm using RH9 and KDE 3.1 > > After trying out some Keyboard layout settings I got the idea to > change one entry: > > From: > /*AltGrMask = event->state & 0x6000;*/ > > To: > AltGrMask = event->state; > > Now it works. Looks reasonable to me. Probably we have to be a bit picky what flags we want to save/restore. Does the attached patch work for you? -- Dmitry.

1 0

!IsWindowVisible && SetMenu
by Michal Janusz Miroslaw 16 Apr '03

16 Apr '03

When an app creates window without a menu, and later adds the menu without showing the window first, window's size doesn't update. Removing one if() in menu.c (as in patch attached) fixes it. (At least in DesignWorks 3.20. The app still hangs after showing it's windows, but at least menu is ok :). Is it a good fix, or the update should happen somewhere else when window is not visible ? -- Michal Miroslaw Index: controls/menu.c =================================================================== RCS file: /home/wine/wine/controls/menu.c,v retrieving revision 1.163 diff -u -r1.163 menu.c --- controls/menu.c 7 Mar 2003 23:03:27 -0000 1.163 +++ controls/menu.c 16 Apr 2003 09:43:49 -0000 @@ -3779,7 +3779,6 @@ } SetWindowLongA( hWnd, GWL_ID, (LONG_PTR)hMenu ); - if (IsWindowVisible(hWnd)) SetWindowPos( hWnd, 0, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE | SWP_NOZORDER | SWP_FRAMECHANGED ); return TRUE;

1 0

Re: winedbg regression?
by Mike Hearn 16 Apr '03

16 Apr '03

> I had this one: > [Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug] 996976720 > "Auto"="1" > "Debugger"="winedbg.exe --debugmsg -all %ld %ld" > > removing the '.exe' and adding --auto did not help. But i found the patch that > broke winedbg for me: > > http://www.winehq.com/hypermail/wine-cvs/2003/03/0371.html Hmm, more of Alexandres deep threading code. I don't really want to unapply that as I have no idea what it does or what its dependancies are. Alexandre, could you take a look at why this patch might have broken winedbg? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

1 0

winedbg improvement - display
by Michal Janusz Miroslaw 16 Apr '03

16 Apr '03

I've just hacked winedbg 'display' handling. It now allows for temporary disabling of displays and restricting them to one function. Look for yourselves, comments welcome. :) Patch follows, -- Michal Miroslaw index: programs/winedbg/Makefile.in =================================================================== RCS file: /home/wine/wine/programs/winedbg/Makefile.in,v retrieving revision 1.2 diff -u -r1.2 Makefile.in --- programs/winedbg/Makefile.in 15 Dec 2002 01:19:53 -0000 1.2 +++ programs/winedbg/Makefile.in 16 Apr 2003 03:04:56 -0000 @@ -31,6 +31,8 @@ @MAKE_PROG_RULES@ +DEFS += -DYYERROR_VERBOSE + y.tab.c y.tab.h: dbg.y $(YACC) -d -t $(SRCDIR)/dbg.y Index: programs/winedbg/dbg.y =================================================================== RCS file: /home/wine/wine/programs/winedbg/dbg.y,v retrieving revision 1.9 diff -u -r1.9 dbg.y --- programs/winedbg/dbg.y 1 Apr 2003 00:12:50 -0000 1.9 +++ programs/winedbg/dbg.y 16 Apr 2003 03:04:56 -0000 @@ -52,8 +52,6 @@ %token tCONT tPASS tSTEP tLIST tNEXT tQUIT tHELP tBACKTRACE tINFO tWALK tUP tDOWN %token tENABLE tDISABLE tBREAK tWATCH tDELETE tSET tMODE tPRINT tEXAM tABORT tVM86 -%token tCLASS tMAPS tMODULE tSTACK tSEGMENTS tSYMBOL tREGS tWND tLOCAL tEXCEPTION -%token tPROCESS tTHREAD tEOL tEOF %token tCLASS tMAPS tMODULE tSTACK tSEGMENTS tSYMBOL tREGS tWND tQUEUE tLOCAL tEXCEPTION %token tPROCESS tTHREAD tMODREF tEOL tEOF %token tFRAME tSHARE tCOND tDISPLAY tUNDISPLAY tDISASSEMBLE @@ -137,13 +135,6 @@ | tSHOW tDIR tEOL { DEBUG_ShowDir(); } | tDIR pathname tEOL { DEBUG_AddPath( $2 ); } | tDIR tEOL { DEBUG_NukePath(); } - | tDISPLAY tEOL { DEBUG_InfoDisplay(); } - | tDISPLAY expr tEOL { DEBUG_AddDisplay($2, 1, 0); } - | tDISPLAY tFORMAT expr tEOL{ DEBUG_AddDisplay($3, $2 >> 8, $2 & 0xff); } - | tDELETE tDISPLAY tNUM tEOL{ DEBUG_DelDisplay( $3 ); } - | tDELETE tDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } - | tUNDISPLAY tNUM tEOL { DEBUG_DelDisplay( $2 ); } - | tUNDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } | tCOND tNUM tEOL { DEBUG_AddBPCondition($2, NULL); } | tCOND tNUM expr tEOL { DEBUG_AddBPCondition($2, $3); } | tSOURCE pathname tEOL { DEBUG_Parser($2); } @@ -154,6 +145,7 @@ | tDETACH tEOL { return DEBUG_Detach(); /* FIXME: we shouldn't return, but since we cannot simply clean the symbol table, exit debugger for now */ } | list_command | disassemble_command + | display_command | set_command | x_command | print_command @@ -163,6 +155,22 @@ | walk_command | run_command | noprocess_state + ; + +display_command: + | tDISPLAY tEOL { DEBUG_InfoDisplay(); } + | tDISPLAY expr tEOL { DEBUG_AddDisplay($2, 1, 0, FALSE); } + | tDISPLAY tFORMAT expr tEOL{ DEBUG_AddDisplay($3, $2 >> 8, $2 & 0xff, FALSE); } + | tDISPLAY tLOCAL expr tEOL { DEBUG_AddDisplay($3, 1, 0, TRUE); } + | tDISPLAY tLOCAL tFORMAT expr tEOL { DEBUG_AddDisplay($4, $3 >> 8, $3 & 0xff, TRUE); } + | tDISPLAY tDELETE tNUM tEOL{ DEBUG_DelDisplay( $3 ); } + | tDISPLAY tDELETE tEOL { DEBUG_DelDisplay( -1 ); } + | tDISPLAY tENABLE tNUM tEOL{ DEBUG_EnableDisplay( $3, TRUE ); } + | tDISPLAY tDISABLE tNUM tEOL { DEBUG_EnableDisplay( $3, FALSE ); } + | tDELETE tDISPLAY tNUM tEOL{ DEBUG_DelDisplay( $3 ); } + | tDELETE tDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } + | tUNDISPLAY tNUM tEOL { DEBUG_DelDisplay( $2 ); } + | tUNDISPLAY tEOL { DEBUG_DelDisplay( -1 ); } ; set_command: Index: programs/winedbg/debug.l =================================================================== RCS file: /home/wine/wine/programs/winedbg/debug.l,v retrieving revision 1.3 diff -u -r1.3 debug.l --- programs/winedbg/debug.l 30 Jan 2003 00:24:18 -0000 1.3 +++ programs/winedbg/debug.l 16 Apr 2003 03:04:56 -0000 @@ -58,6 +58,7 @@ %s WALK_CMD %s SHOW_CMD %s MODE_CMD +%s DISP_CMD %s NOCMD %x ASTRING_EXPECTED @@ -86,12 +87,12 @@ "0x"{HEXDIGIT}+ { sscanf(yytext, "%x", &yylval.integer); return tNUM; } {DIGIT}+ { sscanf(yytext, "%d", &yylval.integer); return tNUM; } -<FORMAT_EXPECTED>"/"{DIGIT}+{FORMAT} { char* last; +<DISP_CMD,FORMAT_EXPECTED>"/"{DIGIT}+{FORMAT} { char* last; yylval.integer = strtol( yytext+1, &last, 0 ) << 8; yylval.integer |= *last; return tFORMAT; } -<FORMAT_EXPECTED>"/"{FORMAT} { yylval.integer = (1 << 8) | yytext[1]; return tFORMAT; } +<DISP_CMD,FORMAT_EXPECTED>"/"{FORMAT} { yylval.integer = (1 << 8) | yytext[1]; return tFORMAT; } {STRING} { yylval.string = DEBUG_MakeSymbol(yytext); return tSTRING; } <ASTRING_EXPECTED>[^\n]+ { char* p = yytext; while (*p == ' ' || *p == '\t') p++; @@ -105,7 +106,7 @@ <INITIAL>enable|enabl|enab|ena { BEGIN(NOCMD); return tENABLE;} <INITIAL>disable|disabl|disab|disa|dis { BEGIN(NOCMD); return tDISABLE; } <INITIAL>disassemble|disassembl|disassemb|disassem|disasse|disass|disas { BEGIN(NOCMD); return tDISASSEMBLE; } -<INITIAL,INFO_CMD,DEL_CMD>display|displa|displ|disp { BEGIN(FORMAT_EXPECTED); return tDISPLAY; } +<INITIAL,INFO_CMD,DEL_CMD>display|displa|displ|disp { BEGIN(DISP_CMD); return tDISPLAY; } <INITIAL>undisplay|undispla|undispl|undisp|undis|undi|und { BEGIN(NOCMD); return tUNDISPLAY; } <INITIAL>delete|delet|dele|del { BEGIN(DEL_CMD); return tDELETE; } <INITIAL,NOPROCESS>quit|qui|qu|q { BEGIN(NOCMD); return tQUIT; } @@ -155,6 +156,11 @@ <INFO_CMD,WALK_CMD>window|windo|wind|win|wnd { return tWND; } <HELP_CMD>info|inf|in { return tINFO; } <MODE_CMD>vm86 { return tVM86; } +<DISP_CMD>local { BEGIN(FORMAT_EXPECTED); return tLOCAL; } +<DISP_CMD>delete|delet|dele|del { BEGIN(NOCMD); return tDELETE; } +<DISP_CMD>enable|enabl|enab|ena|en { BEGIN(NOCMD); return tENABLE; } +<DISP_CMD>disable|disabl|disab|disa|dis { BEGIN(NOCMD); return tDISABLE; } + <INITIAL,SHOW_CMD>directories|directorie|directori|director|directo|direct|direc|direc|dir { BEGIN(PATH_EXPECTED); return tDIR; } Index: programs/winedbg/debugger.h =================================================================== RCS file: /home/wine/wine/programs/winedbg/debugger.h,v retrieving revision 1.9 diff -u -r1.9 debugger.h --- programs/winedbg/debugger.h 1 Apr 2003 00:02:36 -0000 1.9 +++ programs/winedbg/debugger.h 16 Apr 2003 03:04:56 -0000 @@ -327,10 +327,11 @@ extern int DEBUG_ReadLine(const char* pfx, char* buffer, int size); /* debugger/display.c */ -extern int DEBUG_DoDisplay(void); -extern int DEBUG_AddDisplay(struct expr * exp, int count, char format); -extern int DEBUG_DelDisplay(int displaynum); -extern int DEBUG_InfoDisplay(void); +int DEBUG_DoDisplay(void); +int DEBUG_AddDisplay(struct expr * exp, int count, char format, int local_frame); +int DEBUG_DelDisplay(int displaynum); +int DEBUG_InfoDisplay(void); +int DEBUG_EnableDisplay(int displaynum, int enable); /* debugger/expr.c */ extern void DEBUG_FreeExprMem(void); @@ -386,6 +387,7 @@ struct datatype * type); extern BOOL DEBUG_Normalize(struct name_hash * nh ); void DEBUG_InfoSymbols(const char* str); +const char *DEBUG_GetSymbolName(const struct name_hash *); /* debugger/info.c */ extern void DEBUG_PrintBasic( const DBG_VALUE* value, int count, char format ); Index: programs/winedbg/display.c =================================================================== RCS file: /home/wine/wine/programs/winedbg/display.c,v retrieving revision 1.1 diff -u -r1.1 display.c --- programs/winedbg/display.c 13 Sep 2002 17:54:28 -0000 1.1 +++ programs/winedbg/display.c 16 Apr 2003 03:04:56 -0000 @@ -2,6 +2,7 @@ * File display.c - display handling for Wine internal debugger. * * Copyright (C) 1997, Eric Youngdale. + * Improved a bit by Michał Mirosław. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public @@ -27,130 +28,172 @@ #include <stdarg.h> -#define MAX_DISPLAY 25 +#define DISPTAB_DELTA 8 /* needs to be power of 2, search for MARK to see why :) */ -struct display -{ - struct expr * exp; - int count; - char format; +struct display { + struct expr *exp; + int count; + char format; + char enabled; + struct name_hash *frame_name; }; -static struct display displaypoints[MAX_DISPLAY]; +static struct display *displaypoints = NULL; +static unsigned int maxdisplays = 0, ndisplays = 0; -int -DEBUG_AddDisplay(struct expr * exp, int count, char format) +static struct name_hash *DEBUG_GetCurrentFrameName(void) { - int i; + struct name_hash *name; + unsigned int eip, ebp; - /* - * First find a slot where we can store this display. - */ - for(i=0; i < MAX_DISPLAY; i++ ) - { - if( displaypoints[i].exp == NULL ) - { - displaypoints[i].exp = DEBUG_CloneExpr(exp); - displaypoints[i].count = count; - displaypoints[i].format = format; - break; - } - } - - return TRUE; -} - -int -DEBUG_InfoDisplay(void) -{ - int i; - - /* - * First find a slot where we can store this display. - */ - for(i=0; i < MAX_DISPLAY; i++ ) - { - if( displaypoints[i].exp != NULL ) - { - DEBUG_Printf(DBG_CHN_MESG, "%d : ", i+1); - DEBUG_DisplayExpr(displaypoints[i].exp); - DEBUG_Printf(DBG_CHN_MESG, "\n"); - } - } - - return TRUE; -} - -int -DEBUG_DoDisplay(void) -{ - DBG_VALUE value; - int i; - - /* - * First find a slot where we can store this display. - */ - for(i=0; i < MAX_DISPLAY; i++ ) - { - if( displaypoints[i].exp != NULL ) - { - value = DEBUG_EvalExpr(displaypoints[i].exp); - if( value.type == NULL ) - { - DEBUG_Printf(DBG_CHN_MESG, "Unable to evaluate expression "); - DEBUG_DisplayExpr(displaypoints[i].exp); - DEBUG_Printf(DBG_CHN_MESG, "\nDisabling...\n"); - DEBUG_DelDisplay(i); - } - else - { - DEBUG_Printf(DBG_CHN_MESG, "%d : ", i + 1); - DEBUG_DisplayExpr(displaypoints[i].exp); - DEBUG_Printf(DBG_CHN_MESG, " = "); - if( displaypoints[i].format == 'i' ) - { - DEBUG_ExamineMemory( &value, - displaypoints[i].count, - displaypoints[i].format); - } - else - { - DEBUG_Print( &value, - displaypoints[i].count, - displaypoints[i].format, 0); + if (DEBUG_GetCurrentFrame(&name, &eip, &ebp)) + return name; + return NULL; +} + +int DEBUG_AddDisplay(struct expr *exp, int count, char format, int in_frame) +{ + int i; + + for (i = 0; i < ndisplays; i++) + if (displaypoints[i].exp == NULL) + break; + + if (i == maxdisplays) /* no space left - expand */ + displaypoints = DBG_realloc(displaypoints, + (maxdisplays += DISPTAB_DELTA) * sizeof(*displaypoints)); + + if (i == ndisplays) + ++ndisplays; + + displaypoints[i].exp = DEBUG_CloneExpr(exp); + displaypoints[i].count = count; + displaypoints[i].format = format; + displaypoints[i].enabled = TRUE; + displaypoints[i].frame_name = + (in_frame ? DEBUG_GetCurrentFrameName() : NULL); + + return TRUE; +} + +int DEBUG_InfoDisplay(void) +{ + int i; + + for (i = 0; i < ndisplays; i++) { + if (displaypoints[i].exp == NULL) + continue; + + if (displaypoints[i].frame_name) + DEBUG_Printf(DBG_CHN_MESG, "%d in %s%s : ", i + 1, + DEBUG_GetSymbolName(displaypoints[i].frame_name), + (displaypoints[i].enabled ? + (displaypoints[i].frame_name != DEBUG_GetCurrentFrameName() ? + " (out of scope)" : "") + : " (disabled)") + ); + else + DEBUG_Printf(DBG_CHN_MESG, "%d%s : ", i + 1, + (displaypoints[i].enabled ? "" : " (disabled)")); + DEBUG_DisplayExpr(displaypoints[i].exp); + DEBUG_Printf(DBG_CHN_MESG, "\n"); + } + + return TRUE; +} + +void DEBUG_PrintOneDisplay(int i) +{ + DBG_VALUE value; + + if (displaypoints[i].enabled) { + value = DEBUG_EvalExpr(displaypoints[i].exp); + if (value.type == NULL) { + DEBUG_Printf(DBG_CHN_MESG, "Unable to evaluate expression "); + DEBUG_DisplayExpr(displaypoints[i].exp); + DEBUG_Printf(DBG_CHN_MESG, "\nDisabling display %d ...\n", i + 1); + displaypoints[i].enabled = FALSE; + return; } - } } - } - return TRUE; + DEBUG_Printf(DBG_CHN_MESG, "%d : ", i + 1); + DEBUG_DisplayExpr(displaypoints[i].exp); + DEBUG_Printf(DBG_CHN_MESG, " = "); + if (!displaypoints[i].enabled) + DEBUG_Printf(DBG_CHN_MESG, "(disabled)\n"); + else + if (displaypoints[i].format == 'i') + DEBUG_ExamineMemory(&value, displaypoints[i].count, displaypoints[i].format); + else + DEBUG_Print(&value, displaypoints[i].count, displaypoints[i].format, 0); } -int -DEBUG_DelDisplay(int displaynum) -{ - int i; - - if( displaynum >= MAX_DISPLAY || displaynum == 0 || displaynum < -1 ) - { - DEBUG_Printf(DBG_CHN_MESG, "Invalid display number\n"); - return TRUE; - } - if( displaynum == -1 ) - { - for(i=0; i < MAX_DISPLAY; i++ ) - { - if( displaypoints[i].exp != NULL ) - { - DEBUG_FreeExpr(displaypoints[i].exp); - displaypoints[i].exp = NULL; - } - } - } - else if( displaypoints[displaynum - 1].exp != NULL ) - { - DEBUG_FreeExpr(displaypoints[displaynum - 1].exp); - displaypoints[displaynum - 1].exp = NULL; - } - return TRUE; +int DEBUG_DoDisplay(void) +{ + int i; + struct name_hash *cur_frame_name = DEBUG_GetCurrentFrameName(); + + for (i = 0; i < ndisplays; i++) { + if (displaypoints[i].exp == NULL || !displaypoints[i].enabled) + continue; + if (displaypoints[i].frame_name + && displaypoints[i].frame_name != cur_frame_name) + continue; + DEBUG_PrintOneDisplay(i); + } + + return TRUE; +} + +int DEBUG_DelDisplay(int displaynum) +{ + int i; + + if (displaynum > ndisplays || displaynum == 0 || displaynum < -1 + || displaypoints[displaynum - 1].exp == NULL) { + DEBUG_Printf(DBG_CHN_MESG, "Invalid display number\n"); + return TRUE; + } + + if (displaynum == -1) { + for (i = 0; i < ndisplays; i++) { + if (displaypoints[i].exp != NULL) { + DEBUG_FreeExpr(displaypoints[i].exp); + displaypoints[i].exp = NULL; + } + } + displaypoints = DBG_realloc(displaypoints, + (maxdisplays = DISPTAB_DELTA) * sizeof(*displaypoints)); + ndisplays = 0; + } else if (displaypoints[--displaynum].exp != NULL) { + DEBUG_FreeExpr(displaypoints[displaynum].exp); + displaypoints[displaynum].exp = NULL; + while (displaynum == ndisplays - 1 + && displaypoints[displaynum].exp == NULL) + --ndisplays, --displaynum; + if (maxdisplays - ndisplays >= 2 * DISPTAB_DELTA) { + maxdisplays = (ndisplays + DISPTAB_DELTA - 1) & ~(DISPTAB_DELTA - 1); /* MARK */ + displaypoints = DBG_realloc(displaypoints, + maxdisplays * sizeof(*displaypoints)); + } + } + return TRUE; } + +int DEBUG_EnableDisplay(int displaynum, int enable) +{ + --displaynum; + if (displaynum >= ndisplays || displaynum < 0 || displaypoints[displaynum].exp == NULL) { + DEBUG_Printf(DBG_CHN_MESG, "Invalid display number\n"); + return TRUE; + } + + displaypoints[displaynum].enabled = enable; + if (!displaypoints[displaynum].frame_name + || displaypoints[displaynum].frame_name == DEBUG_GetCurrentFrameName()) + DEBUG_PrintOneDisplay(displaynum); + + return TRUE; +} + Index: programs/winedbg/hash.c =================================================================== RCS file: /home/wine/wine/programs/winedbg/hash.c,v retrieving revision 1.7 diff -u -r1.7 hash.c --- programs/winedbg/hash.c 19 Feb 2003 03:41:48 -0000 1.7 +++ programs/winedbg/hash.c 16 Apr 2003 03:04:57 -0000 @@ -1314,6 +1314,11 @@ return TRUE; } +const char *DEBUG_GetSymbolName(const struct name_hash * sym) +{ + return sym->name; +} + #ifdef HAVE_REGEX_H static int cmp_sym_by_name(const void * p1, const void * p2) Index: programs/winedbg/info.c =================================================================== RCS file: /home/wine/wine/programs/winedbg/info.c,v retrieving revision 1.5 diff -u -r1.5 info.c --- programs/winedbg/info.c 14 Feb 2003 19:22:48 -0000 1.5 +++ programs/winedbg/info.c 16 Apr 2003 03:04:57 -0000 @@ -214,6 +214,8 @@ " stepi [N] nexti [N]", " x <addr> print <expr>", " display <expr> undisplay <disnum>", +" display local <expr> display delete <disnum>", +" display enable <disnum> display disable <disnum>", " delete display <disnum> pass", " bt frame <n>", " up down",

1 0

Fwd: Keyboard Problem solved, one solution ...
by Sylvain Petreolle 16 Apr '03

16 Apr '03

What do you think of this fix ? ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Winelib _alloca/alloca linking problem
by Vincent Béron 15 Apr '03

15 Apr '03

Ok, so this won't get into CVS (way too "hacked until it works for me and only me"), but I don't know where to look further. Can somebody explain me where _alloca is supposed to be implemented/forwarded/ends up being called? The provided small program should be able to compile with either _alloca or alloca being called. Under Winelib, with the current msvcrt headers, _alloca is not found at all and linking fails. With the included patch, the program runs. Should I add a forward in msvcrt.spec from _alloca to MSVCRT_alloca, which itself calls (glibc's) alloca? Or is there something obvious I missed? Vincent Index: wine/include/msvcrt/malloc.h =================================================================== RCS file: /home/wine/wine/include/msvcrt/malloc.h,v retrieving revision 1.5 diff -u -r1.5 malloc.h --- wine/include/msvcrt/malloc.h 22 Mar 2003 21:15:41 -0000 1.5 +++ wine/include/msvcrt/malloc.h 15 Apr 2003 23:34:34 -0000 @@ -79,9 +79,6 @@ } #endif - -#ifndef USE_MSVCRT_PREFIX -static inline void* alloca(MSVCRT(size_t) i) { return _alloca(i); } -#endif /* USE_MSVCRT_PREFIX */ +static inline void* _alloca(MSVCRT(size_t) i) { return alloca(i); } #endif /* __WINE_MALLOC_H */ #include <malloc.h> #include <stdio.h> #include <stdlib.h> char *mp() { char *p; p = _alloca(2); p[0] = 0x41; /* A */ p[1] = 0; return p; } int main(void) { char *p; p = mp(); printf("%02x %02x\n", p[0], p[1]); exit(0); return 0; }

1 0

Re: version patch
by Vincent Béron 15 Apr '03

15 Apr '03

Andreas Mohr a écrit: > @@ -162,16 +174,18 @@ > }, > /* NT2K */ > { > + "Windows 2000", > 0x05005F03, > 0x08930005, > { > sizeof(OSVERSIONINFOA), 5, 0, 0x893, > VER_PLATFORM_WIN32_NT, "Service Pack 2", > - 2, 0, 0, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field with a value! */ > + 2, 0, 0, VER_NT_WORKSTATION, 30 /* FIXME: Great, a reserved field with a value! Is this correct? */ I still have this value (30) on 2K SP3. What do others have for 2K and XP (see attached program)? Besides, shouldn't we report SP3 for NT2K? And SP1 for XP? Vincent #include <windows.h> #include <stdio.h> typedef struct _OSVERSIONINFOEXAB { DWORD dwOSVersionInfoSize; DWORD dwMajorVersion; DWORD dwMinorVersion; DWORD dwBuildNumber; DWORD dwPlatformId; CHAR szCSDVersion[ 128 ]; // Maintenance string for PSS usage WORD wServicePackMajor; WORD wServicePackMinor; WORD wSuiteMask; BYTE wProductType; BYTE wReserved; } OSVERSIONINFOEXAB, *POSVERSIONINFOEXAB, *LPOSVERSIONINFOEXAB; int main(void) { OSVERSIONINFOEXAB ver; ver.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEXAB); GetVersionExA((OSVERSIONINFOA *) &ver); printf("%d %d %d %d %d \"%s\" %d %d %d %d %d\n", ver.dwOSVersionInfoSize, ver.dwMajorVersion, ver.dwMinorVersion, ver.dwBuildNumber, ver.dwPlatformId, ver.szCSDVersion, ver.wServicePackMajor, ver.wServicePackMinor, ver.wSuiteMask, ver.wProductType, ver.wReserved); exit(0); return 0; }

2 1

manual patch tracking system for ntdll
by thomas.mertes＠gmx.at 15 Apr '03

15 Apr '03

Hello Since I am following the ntdll development, I noticed some not applied patches: - Ntdll atom stuff: http://www.winehq.com/hypermail/wine-patches/2003/04/0064.html - Ntdll atom tests. http://www.winehq.com/hypermail/wine-patches/2003/04/0065.html The tests where verified by Dmitry Timoshkov in this mail: http://www.winehq.com/hypermail/wine-devel/2003/04/0192.html - Resend: Implement some ACE functions http://www.winehq.com/hypermail/wine-patches/2003/04/0129.html IMHO, if a patch is correct (can be verified by tests) it should be applied, even if no application needs this functions (at the moment). If this functions are needed later, some implementation (with FIXMEs) is already there as base for further development. This is easier than looking for a (possibly outdated) patch in the archieves. I see the wine source also as a information repository, which is easier to access, than a patch archive. In the worst case it should be possible that a function is accepted but deactivated with #ifdef. Greetings Thomas Mertes -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

3 2

Re: Fall back to ttydrv
by Dimitrie O. Paun 15 Apr '03

15 Apr '03

On April 14, 2003 06:11 pm, Uwe Bonnes wrote: > + MESSAGE( "Falling back to ttydrv\n"); Again, I'd say this message is not appropriate, especially now that the user has to enable this configurations. For people using command line tools under Wine will be just pure spam. -- Dimi.

5 6

Cross compiling tests
by Hans Leidekker 15 Apr '03

15 Apr '03

Hi, I'm trying to cross compile the regression tests using MinGW as a cross compiler (i.e. I have installed the MinGW cross compiler on Linux and run 'make crosstest'). First problem I encountered was that my versions of the compiler and dlltool weren't detected at configure stage. Mine are called i386-mingw-gcc and i386-mingw-dlltool, whereas configure looks for i586-mingw32msvc-gcc and i586-mingw32msvc-dlltool. I've sent a patch to wine-patches that adds the former names to the configure check. Second major problem happens at the build stage. The Makefile for a test specifies -L$(DLLDIR) when linking the test executables, which is where the *Wine* libraries reside. I think this is wrong, we should link against the target platform libraries (MinGW in this case) when cross compiling. Removing -L$(DLLDIR) from the Makefile also solves a conflict that arises from the fact that both MinGW and Wine have an implementation of the C runtime: make crosstest i386-mingw32-gcc generated.cross.o testlist.cross.o -o urlmon_crosstest.exe -L../../../dlls -lurlmon -lm ../../../dlls/libmsvcrt.a(ds00443.o)(.text+0x0): multiple definition of `atexit' /usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x230):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:266: first defined here ../../../dlls/libmsvcrt.a(ds00319.o)(.text+0x0): multiple definition of `_onexit' /usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x250):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:274: first defined here Patch sent to wine-patches. Now most tests happily compile ;-). I have two tests left that have problems linking. It appears that they use symbols that are not available in any import library (not even Wine's): i386-mingw32-gcc dsound.cross.o testlist.cross.o -o dsound_crosstest.exe -ldsound -luser32 -lkernel32 -lm dsound.cross.o(.text+0x1656): In function `dsenum_callback': /usr/local/src/wine-cvs/wine/dlls/dsound/tests/dsound.c:403: undefined reference to `wine_dbgstr_guid' dsound.cross.o(.text+0x24dd): In function `dscenum_callback': /usr/local/src/wine-cvs/wine/dlls/dsound/tests/dsound.c:649: undefined reference to `wine_dbgstr_guid' make: *** [dsound_crosstest.exe] Error 1 The wine_ prefix suggests that this is a Wine internal function, so it will never be avaliable on Windows/MinGW. Can these be removed? Or is there an alternative that works on all platforms? This is the other one that fails: i386-mingw32-gcc safearray.cross.o vartest.cross.o testlist.cross.o -o oleaut32_crosstest.exe -loleaut32 -lm safearray.cross.o(.text+0x1496): In function `func_safearray': /usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:277: undefined reference to `IID_IUnknown' safearray.cross.o(.text+0x14d1):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:278: undefined reference to `IID_IUnknown' safearray.cross.o(.text+0x150e):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:281: undefined reference to `IID_IDispatch' safearray.cross.o(.text+0x1549):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:282: undefined reference to `IID_IDispatch' make: *** [oleaut32_crosstest.exe] Error 1 Same problem I guess. Any suggestion as to how this one might be fixed is welcome. -Hans

3 10

mouse_event()
by Brad Campbell 15 Apr '03

15 Apr '03

G'day all, I have been doing some testing of the mouse_event call in windows and wine. There is only one incompatibility that I can see. In windows 95, a call to mouse_event does not _move_ the mouse pointer, whereas in wine, the mouse pointer follows the mouse. In windows, I have to make a call to mouse_event then another call to setcursorpos() to make the pointer follow the mouse. When using a touchscreen for input, we use a setcursorpos() call to move the mouse pointer off the screen, and then just feed windows mouse_event calls with the position and button state. This works under wine, but of course the pointer follows the mouse_event. It looks like this would be difficult to fix as from what I can see the pointer movement seems to be pretty closely tied to the mouse position. Any ideas? -- Brad.... /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \

1 0

Re: Better fix for named pipe problem.
by Gregory M. Turner 14 Apr '03

14 Apr '03

FYI fixing the linewraps in the patch and applying does indeed stop the wineserver from crashing using the experimental pipe.c, and runs fine against CVS's pipe.c. However, also FWIW, using the experimental pipe.c from Bill, I still get a pipe.ok when I shouldn't doing make test... -- gmt "Democracy is the theory that holds that the common people know what they want, and deserve to get it good and hard." HL Mencken

1 0

re: Is it possible to call DLL functions from a Linux program?
by Dan Kegel 14 Apr '03

14 Apr '03

Eloy wrote: > Now, I want to run this program natively under Linux - I mean, I don't > want to run wcmd because that requires an X server. I suggest just running your little Windows program under Wine. Don't use wcmd, you don't need it. For instance, in my ~/bin, I have a shell script winword which just contains wine -- "c:\\Program Files\\Microsoft Office\\Office\\winword.exe" "$@" That more or less lets me run microsoft word from the commandline. You can configure wine to not require X. I've done it on some commandline Windows programs I wanted to use in shell scripts on Linux. It was and is a pain, I believe, because so few of the Wine developers use commandline Windows programs without X, but it is doable. (And maybe it's easier than it used to be; I don't know.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

3 6

Bug: "Type" = "cdrom" allows writing !!
by Sylvain Petreolle 14 Apr '03

14 Apr '03

Trying to run "dir >test" in a drive set to "Type" = "Cdrom" will create a test file containing the directory listing. Test case: [Drive W] "Path" = "/home/wine" "Type" = "cdrom" "Label" = "WineSrc" "Filesystem" = "win95" [syl@snoop wine]$ ls -l z ls: z: No such file or directory [syl@snoop wine]$ wcmd fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (French keyboard layout) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. WCMD Version 0.17 W:\>dir >z W:\>exit [syl@snoop wine]$ ls -l z -rw-r--r-- 1 syl wine 2413 Apr 14 23:59 z ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: OLE storage SetFilePointer fix
by Dimitrie O. Paun 14 Apr '03

14 Apr '03

On Sat, 12 Apr 2003, Andreas Mohr wrote: > P.S.: Alexandre, I'd REALLY like you to finally put a patch status > tracking system in place. The number of people submitting patches > for the second, third, bazillionth time is astonishing (I speak > from my very own experience, too!). I really don't know how many very > valuable Wine patches got lost due to not getting applied without any > status reply whatsoever... > (particularly the ones from "foreigners") > Someone recently said (in WWN) that patch management was perfect or > something to that extent. I better don't comment on that statement, > you know my hot temper ;) > OK, it's definitely not awful, but I guess it could be better. First off, I don't think the current system is bad. Second, I was the one this in the WWN (so sue me :P). Any system that we would put in place would have to work with email just like the current one. Other suck big time, see the SF one. Once you notice that, you realize that the problem is not the system, but rather that Alexandre needs to reply to patches he rejects, wether through email/web based form/what have you. Don't get me wrong -- I've been multiple times at the rejecting end of this, and it's frustrating. But in retrospective, it's all for a better Wine, and I'd be hard pressed to produce a patch which got rejected by Alexandre, and which I still think should be applied. Also, your assesment that 'very many valuable Wine patches got lost' is a gross exageration. In fact, please produce 3 such patches that got lost in the last year (heck, in the last 3 years for that matter). I think you'll have a hard time finding a single such patch in the last X years (choose X as you may) that match your description. There is good reason for this: people put work into their patches, and if they don't get apply, they ask why. This is where I don't understand Alexandre: he will eventually have to reply to such questions, why not do it proactively, it's the same amount of work, me thinks. But I'm not the one putting in the time and effort to sort through the patches, so I may be missing many things. -- Dimi.

4 4

patch tracking system redux
by Dan Kegel 14 Apr '03

14 Apr '03

Steven Edwards (steven_ed4153(a)yahoo.com) wrote: > --- Dominik Strasser <Dominik.Strasser(a)t-online.de> wrote: >> The attached patch implements proxies in wininet to an extent that at >> least IE6 install works behind a firewall. >> >> ChangeLog: >> partially implement proxy support in wininet >> >> This is the third time I am sending this patch. Is anything wrong with it ? > > I think we are starting to see we need a patch tracking system =) I think Alexandre feels differently. Have you read http://www.winehq.com/hypermail/wine-devel/2003/04/0384.html ? I do know of one patch tracking system that works well (http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/). It's restricted to "trivial" patches, and wouldn't handle the wininet proxy change, but might still be useful for Wine. I dunno. Alexandre silently ignored several of my patches recently, but that's just fine with me. They needed more work, and it was pretty obvious to me which direction I needed to go in to make him happy. Since I care about them, I will keep plugging away until they meet his criteria. - Dan

1 0

Re: lostwages/templates/en todo_lists.template
by Vincent Béron 14 Apr '03

14 Apr '03

Jeremy Newman a écrit: > ChangeSet ID: 7866 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: jnewman(a)wine.codeweavers.com 2003/04/14 11:03:55 > > Modified files: > templates/en : todo_lists.template > > Log message: > Dimitrie O. Paun <dpaun(a)rogers.com> > Update TODO Lists to Wine 0.9 TODO v0.8 from: > Â http://www.dssd.ca/wine/Wine-0.9-TODO-0.8.html > > Patch: http://cvs.winehq.com/patch.py?id=7866 > > Old revision New revision Changes Path > 1.4 1.5 +281 -258 lostwages/templates/en/todo_lists.template It would be nice if my last name (and maybe other people's names) wouldn't be mangled. This is due to the <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> in the header of the page, but with the use of UTF-8 chars in the body. On Dimi's site it looks fine (same header, but use of iso-8859-1 chars in the body). It might be in the transfer that the characters get transformed (had to chase something akin to that yesterday with a text attachment in Evolution). Vincent

1 0

Is it possible to call DLL functions from a Linux program?
by Eloy A. Paris 14 Apr '03

14 Apr '03

Hi! Sorry if this has been covered before, but I could not find any answers in the archives or by Googling... Here's the situation: I have a Windows DLL and a small Windows program that calls functions from this DLL. The Windows program does not have a GUI (it's command-line based.) I have the C source code for this program, but don't have the source code for the DLL. I built the program with Visual C and was able to run it under WINE just fine with wcmd. Now, I want to run this program natively under Linux - I mean, I don't want to run wcmd because that requires an X server. The first question is: is this possible? (have a Unix program that calls functions from a native Windows DLL). I started experimenting with winelib, but am not sure if this is the correct way... If this is possible, how should I do it? I ran winemaker, configure, make, but am getting errors from winbebuild. Summarizing: I have the C source code. This C program calls function foo() that is in a Windows DLL. I want to run this program under Linux without the need for an X server. The program calls gets(), printf(), etc. I want these functions to be from my Linux's libc, not Windows'. Any help will be greatly appreciated. Thanks in advance! Eloy.- P.S. I read the winelib user guide, but couldn't find the answer there. If it is there, it's not clear to me :(

4 4

Re: Implement proxies in wininet
by Steven Edwards 14 Apr '03

14 Apr '03

--- Dominik Strasser <Dominik.Strasser(a)t-online.de> wrote: > The attached patch implements proxies in wininet to an extent that at > least IE6 install works behind a firewall. > > ChangeLog: > partially implement proxy support in wininet > > This is the third time I am sending this patch. Is anything wrong with it ? I think we are starting to see we need a patch tracking system =) Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

1 0

Latest wine tarball not compiling with egcs and --disable-debug
by Gabriele 14 Apr '03

14 Apr '03

Hi all, I'm trying to compile wine 20030408 with a pretty old compiler which is gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) If I run the configure scipt without passing --disable-debug and --disable-trace and then make depend && make everything builds just fine. If I disable debug and trace and then run make I get some errors. The first problem is with some defines in debug.c ../../include/wine/debug.h:84: warning: invalid character in macro parameter name ../../include/wine/debug.h:84: badly punctuated parameter list in `#define' I had to add a string before the '...' to bypass the error: #ifdef NO_DEBUG_MSGS #define WINE_WARN(arg...) do { } while(0) #define WINE_WARN_(ch) WINE_WARN #define WINE_FIXME(arg...) do { } while(0) #define WINE_FIXME_(ch) WINE_FIXME #endif The other error is the following : make[2]: Entering directory `/home/gabriele/wine-20030408/dlls/oleaut32' gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -gstabs+ -fPIC -D__WINESRC__ -D_OLEAUT32_ -DCOM_NO_WINDOWS_H -D_REENTRANT -o typelib.o typelib.c typelib.c: In function `ITypeLib2_fnGetTypeComp': typelib.c:3393: warning: unused variable `This' typelib.c: In function `ITypeLib2_fnReleaseTLibAttr': typelib.c:3584: warning: unused variable `This' typelib.c: In function `ITypeLib2_fnGetLibStatistics': typelib.c:3629: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnGetTypeComp': typelib.c:3870: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnAddressOfMember': typelib.c:4765: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnCreateInstance': typelib.c:4778: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnGetMops': typelib.c:4790: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseTypeAttr': typelib.c:4828: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseFuncDesc': typelib.c:4840: warning: unused variable `This' typelib.c: In function `ITypeInfo_fnReleaseVarDesc': typelib.c:4851: warning: unused variable `This' gcc: Internal compiler error: program cc1 got fatal signal 11 make[2]: *** [typelib.o] Error 1 make[2]: Leaving directory `/home/gabriele/wine-20030408/dlls/oleaut32' make[1]: *** [oleaut32] Error 2 make[1]: Leaving directory `/home/gabriele/wine-20030408/dlls' make: *** [dlls] Error 2

1 0

keyboard mapping with XFree86 4.3.0
by Tim Ruehsen 14 Apr '03

14 Apr '03

With XFree86 4.3.0 I experience the message fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (German keyboard layout without dead keys) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. This is very annoying, I can't use the right alt key any more to reach characters like {,} or [. Very bad for C programming... (I use EditPlus together with wine). The Problem can be found with older versions (20020812) as with newer version (20030317). Here is my keyboard layout from XF86Config: Section "InputDevice" Driver "Keyboard" Identifier "Keyboard[0]" Option "MapName" "Standard Keyboard [ pc105 ]" Option "Protocol" "Standard" Option "XkbLayout" "de" Option "XkbModel" "pc105" Option "XkbRules" "xfree86" Option "XkbVariant" "nodeadkeys" EndSection wine -debugmsh +key,+keyboard application outputs: trace:key:X11DRV_InitKeyboard NumLockMask is 10 trace:keyboard:X11DRV_KEYBOARD_DetectLayout Attempting to match against "United States keyboard layout" trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff1b trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff1b trace:key:X11DRV_KEYBOARD_DetectLayout mismatch for keycode 11, character 2 ... Any idea? Regards, Tim

4 11

Re: Fall Back to ttydrv when DISPLAY is not set
by Andreas Mohr 14 Apr '03

14 Apr '03

On Sun, Apr 13, 2003 at 08:41:04PM +0200, Uwe Bonnes wrote: > > Changelog > wine/dlls/user/user_main.c: load_driver > wine/dlls/gdi/driver.c: load_display_driver > Fall back to the ttydrv when the DIPLAY variable is not set What about falling back to including a patch? ;-) BTW, do you print a SUFFICIENTLY LARGE warning message when doing so? Users should be aware that something "isn't ok" when this happens... (otherwise they'll keep running Wine with ttydrv and not be aware of the real reason for this behaviour, namely the missing DISPLAY variable) Anyway, since this is going towards error handling, you should make sure that people *know* what's going on instead of them confusedly deleting Wine again ;-) Andreas Mohr -- Help prevent Information Technology Fascism! - before it's too late... http://www.againsttcpa.com

4 3

Re: Fall back to ttydrv when DISPLA variable not set(with patch)
by Dimitrie O. Paun 14 Apr '03

14 Apr '03

On April 13, 2003 04:35 pm, Uwe Bonnes wrote: > + { > + MESSAGE( "Falling back to ttydrv\n"); > + strcpy( buffer, "ttydrv" ); /* default value */ > + } I'm not sure this message is a good idea. What about if you don't run X, are we gonna spam people into running it? -- Dimi.

1 0

Re: UPDATED: video mode changes
by Dimitrie O. Paun 14 Apr '03

14 Apr '03

On April 12, 2003 09:34 pm, Alex Pasadyn wrote: > +#define _X_FIELD(prefix, bits) if ((fields) & prefix##_##bits) TRACE(""#bits ","); +static void _dump_CDS_flags(DWORD fields) { > + _X_FIELD(CDS,UPDATEREGISTRY);_X_FIELD(CDS,TEST);_X_FIELD(CDS,FULLSCREEN); > + _X_FIELD(CDS,GLOBAL);_X_FIELD(CDS,SET_PRIMARY);_X_FIELD(CDS,RESET); > + _X_FIELD(CDS,SETRECT);_X_FIELD(CDS,NORESET); > +} > +static void _dump_DM_fields(DWORD fields) { > + _X_FIELD(DM,BITSPERPEL);_X_FIELD(DM,PELSWIDTH);_X_FIELD(DM,PELSHEIGHT); > + _X_FIELD(DM,DISPLAYFLAGS);_X_FIELD(DM,DISPLAYFREQUENCY);_X_FIELD(DM,POSITION); > +} > +#undef _X_FIELD I still think these should return a string as I described in my previous email... Also, there is no need for such tests: > + if (TRACE_ON(x11drv)) The TRACE will take care of things nicely. -- Dimi.

1 0

Re: ALTGR Problem
by Dmitry Timoshkov 13 Apr '03

13 Apr '03

<duncan(a)semanticedge.de> wrote: > When ever I press the AltGr Key, I get the ^ sign and nothin happend > concerning the email "at" sign, the special brackets and so on. I have > a Toshiba notebook, 2430-101 with a qwertz keyboard, german layout. > Under RH everything works fine concerning the keyboard! > I'm not really familiar with keyboard settings, so editing the > keyboard.c will fail ;-) If I gonna try it with no idea what to do. Let's wait for a merge of keyboard patches from CX Office and see whether it works any better. -- Dmitry.

1 0

Re: Fall Back to ttydrv when DISPLAY is not set
by Vincent Béron 13 Apr '03

13 Apr '03

Le dim 13/04/2003 à 14:41, Uwe Bonnes a écrit : > > Changelog > wine/dlls/user/user_main.c: load_driver > wine/dlls/gdi/driver.c: load_display_driver > Fall back to the ttydrv when the DIPLAY variable is not set You forgot the patch this time. Vincent

1 0

Re: OLE storage SetFilePointer fix
by Mike Hearn 13 Apr '03

13 Apr '03

> P.S.: Alexandre, I'd REALLY like you to finally put a patch status > tracking system in place. The number of people submitting patches > for the second, third, bazillionth time is astonishing (I speak > from my very own experience, too!). I really don't know how many very > valuable Wine patches got lost due to not getting applied without any > status reply whatsoever... The main problem as far as I'm concerned isn't so much the lack of a patch "tracker", I'm usually capable of keeping track of whether my patches have been applied or not by watching wine-cvs (though i've found once or twice i've missed the commit), it's more an issue of if a patch is rejected, you have to ask why. That means I'm often left thinking, is my patch simply in the queue, or is something wrong with it? Or, like my last pkgconfig patch, is there another reason it didn't go in? The way gnome/mozilla do it is to have patches put in bugzilla, but for the sheer volume of patches Wine gets with only Alexandre committing (which is fine by me), that wouldn't work. I'd be perfectly happy with the current arrangement if when a patch was dropped, a reason would normally appear on wine-devel - but then I'm not the one doing the work, Alexandre is, so it's easy for me to ask for him to do more work :/ thanks -mike

2 2

Fwd: ALTGR Problem
by Sylvain Petreolle 13 Apr '03

13 Apr '03

Welcome to the club ;-) ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

Re: dos games, vesa and wine
by Jukka Heinonen 13 Apr '03

13 Apr '03

Enrico Horn wrote: > I tried my dos4gw games with dos32a and they "work"(except some warning dos32a > prints) but you have to run these games like this to get an result: > wine -- dos32a game.exe > thats is because the stub which loads the dos extender doesnt work and i have > no idea why. Neither dos4gw stub loader nor dos4gw itself work. Making these work would be nice, but since there are free, compatible DOS extenders available that work rather well with Wine, I'm not particularly interested to figure out what is wrong with them. I have toyed with an idea of trying to contact dos4gw authors (if I can find them) and ask them if they could help, but I'm just too lazy for this kind of stuff. > the games i use all make use of vesa > they want 640x480x256 > ddraw traces show a primary surface that is 8bit paletted. > is there any problem drawing this thing? > where is this done? > is there a routine that regularly updates the screen with content of this > surface? > i have looked in x11drv(can it be that x11drv is in need of a rewrite?) and > havent found anything but i am not expert at this and just poke around > randomly where i see an interest. That mode should work with DOS VESA emulation. It could be that those programs use VESA features that are not supported or that VESA emulation is faulty. It is also possible that those programs are waiting for timer interrupt which is not delivered in protected mode (I have a good idea how to do this, but we shall see when I have time to implement it). See dlls/winedos/int10.c and dlls/winedos/vga.c. It is unlikely that DOS display problems are due to x11drv bugs. -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

LdrGetDllHandle with FlashMX demo
by Darren Cook 13 Apr '03

13 Apr '03

Hi, When trying to run the FlashMX Demo version I got about 120 lines of: fixme:module:LdrGetDllHandle Unknown behavior, please report It then dies with "Failed to initialize Vbox! (0010-0069-0090)". I wasn't sure whether to report it in bugzilla or here as I'm not sure if you consider this a bug. So I thought I'd try here first. I'm using this version of wine: wine-20030408-1rh8winehq.i686.rpm (plus stdole32.tlb, copied from winXP machine). FlashMX demo was copied over from a winXP installation (I couldn't get the installer to run under wine). I also have a full version of FlashMX which works (well, some rough edges :-), also by copying over from winXP. If you need more information, or want me to try in debug mode, etc. let me know (I'm not subscribed to the list). Darren

2 1

Re: OLE storage SetFilePointer fix
by Marcus Meissner 13 Apr '03

13 Apr '03

On Sat, Apr 12, 2003 at 11:07:11PM +0200, Andreas Mohr wrote: > Hi all, > > the OLE storage code basically disabled itself, by doing a > READ_HEADER; > in STORAGE_get_pps_entry(). > This READ_HEADER uses -1 as block number for STORAGE_get_big_block() > (in order to retrieve the storage header block). > And if you look at the SetFilePointer() in STORAGE_get_big_block(), > you might notice that (n+1)*BIGSIZE for some strange reason evaluates > to 0, for n == -1. > Thus, SetFilePointer() seeks to position 0 to read the storage header. > > And now I'm terribly sorry to tell you that STORAGE_get_big_block() > did a > if (!SetFilePointer( hf, (n+1)*BIGSIZE, NULL, SEEK_SET )) > { > WARN(" seek failed (%ld)\n",GetLastError()); > return FALSE; > } > > Sounds like SetFilePointer() is *supposed* to return 0 if it seeks to > position 0, eh? > > In other words: > - fix blatantly wrong SetFilePointer() calls The 16bit storage code is probably not safe to work with, for instance saving is probably not working. It should call forward to the 32bit storage code, which I think is more correct. Ciao, Marcus

1 0

Re: OLE storage SetFilePointer fix
by Alexandre Julliard 12 Apr '03

12 Apr '03

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > P.S.: Alexandre, I'd REALLY like you to finally put a patch status > tracking system in place. The number of people submitting patches > for the second, third, bazillionth time is astonishing (I speak > from my very own experience, too!). I really don't know how many very > valuable Wine patches got lost due to not getting applied without any > status reply whatsoever... You know, nobody prevents you from implementing a better patch tracking system, and if it makes my life easier I'll be more than happy to use it. Or if you don't want to write code, you could volunteer to manually keep track of all submitted patches and resubmit the lost ones. But of course that's a lot more work than simply complaining about it... -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: video mode changes
by Lionel Ulmer 12 Apr '03

12 Apr '03

Hi, I have some comments on this patch : > + if (devmode->dmFields & DM_BITSPERPEL) > + { > + if (devmode->dmBitsPerPel != GetSystemMetrics(SM_WINE_BPP)) > + continue; > + } This may cause problems... It's not per-se a problem in your patch, but from what I know Windows applications expect to have '32' on a 24/32 display and Wine stores here '24'. So you may 'refuse' some modes that should be valid. (again, if ever you have a graphic card still supporting 24/24 mode, please tell me so that I can torture your XFree libraries to find a valid way of checking the difference between 24/24 and 24/32) > + SYSMETRICS_Set( SM_CXSCREEN, devmode->dmPelsWidth ); > + SYSMETRICS_Set( SM_CYSCREEN, devmode->dmPelsHeight ); This are actually 'User' internal functions ? In that case, why not just do the resolution change in the X11 driver and let User itself handle the sysmetric change ? I.e. call these in the 'ChangeDisplaySettingsExW' function and not in the low-level graphic driver. Now my most important grief : did you think about all the people who 1) use Desktop mode and 2) disable XVidMode in their config file ? For those, applications may now abort saying 'Vidmode not supported' (whereas it was working just fine before because we accepted all modes that are smaller than the actual screen size). So I would say that if no VidMode is present or if the User driver function does not exist in the driver, the old 'stub' API should remain as it is. Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 3

Re: winedos / Improve tracing
by BiGgUn 12 Apr '03

12 Apr '03

Why didn't you use TRACE instead of DPRINTF ? Stephan

1 0

Toolbar debug message
by BiGgUn 12 Apr '03

12 Apr '03

Hi How can i see debug messages from toolbar.c ? Neither '--debug-msg trace+toolbar' nor '--debug-msg +toolbar' works. The '+loaddll' option claims that i use the _builtin_ version of comctl32. I do not have no more ideas :( Stephan

2 1

Wine 0.9 TODO v0.8
by Dimitrie O. Paun 12 Apr '03

12 Apr '03

Hi folks, The next version of the 0.9 TODO is way past due (again!), and today is as good as any other day for a brand new release: http://www.dssd.ca/wine/Wine-0.9-TODO-0.8.html ChangeLog * Jer finished the WineHQ redesign (A1) * Brian completed the screenshot galery (A4) * Adam is our new Slackware maintainer (A6) * Andreas updated the User & Development Guide (B1,B3) * I took on the Packaging Guide and Winelib docu (B2,B4,B8) * New task: more modular doc building (B12) * I've updated and integrated Jaco's winecfg into the tree (C2) * John did more work on the DLL registration (C5) * Shachar got a working version of wineboot into the tree (C7) * I finished messing with wrc (D5) * I got winegcc to a working state (D6) * Marcus made the printing system detection dynamic (E3) * Eric improved WinHelp some more (E6) Please note that this version has been in the making for almost 4 month! Lot's of stuff changed, feedback is much appreciated. -- Dimi.

3 2

Re: PATCH: video mode changes
by Dimitrie O. Paun 12 Apr '03

12 Apr '03

On April 12, 2003 12:16 am, Alex Pasadyn wrote: > + if (TRACE_ON(x11drv)) > + { > + MESSAGE("\tDM_fields=");_dump_DM_fields(devmode->dmFields);MESSAGE("\n"); > + MESSAGE(" bpp=%ld\n",devmode->dmBitsPerPel); > + MESSAGE(" width=%ld\n",devmode->dmPelsWidth); > + MESSAGE(" height=%ld\n",devmode->dmPelsHeight); > + MESSAGE(" freq=%ld\n",devmode->dmDisplayFrequency); > + } Please don't use MESSAGE. Use TRACE instead, it will do the right thing. This piece can be rewritten as: TRACE("\tDM_fields=");_dump_DM_fields(devmode->dmFields);TRACE("\n"); TRACE(" bpp=%ld\n",devmode->dmBitsPerPel); TRACE(" width=%ld\n",devmode->dmPelsWidth); TRACE(" height=%ld\n",devmode->dmPelsHeight); TRACE(" freq=%ld\n",devmode->dmDisplayFrequency); Also, it will be a lot nicer if you rewrite _dump_DM_dields to return a string, so you can write: TRACE("\tDM_fields=%s\n", debug_DM_fields(devmode->dmFields)); TRACE(" bpp=%ld\n",devmode->dmBitsPerPel); TRACE(" width=%ld\n",devmode->dmPelsWidth); TRACE(" height=%ld\n",devmode->dmPelsHeight); TRACE(" freq=%ld\n",devmode->dmDisplayFrequency); The debug_DM_fields() function would than look like so: static const char* debug_DM_fields(DWORD fields) { BOOL first = TRUE; char buf[128] = "", *p = buf; #define DEBUG_FIELD(x) if ((fields) & DM_##x) { p += sprintf(p, "%s%s", first ? "" : " ,", #x); first = FALSE; } DEBUG_FIELD(BITSPERPEL); DEBUG_FIELD(PELSWIDTH); DEBUG_FIELD(PELSHEIGHT); DEBUG_FIELD(DISPLAYFLAGS); DEBUG_FIELD(DISPLAYFREQUENCY); DEBUG_FIELD(POSITION); #undef DEBUG_FIELD return wine_dbg_sprintf("%s", buf); } -- Dimi.

2 1

Re: Wine Packaging Guide update
by Mike Hearn 12 Apr '03

12 Apr '03

> NOTE: I am (was?) a strong believer in markup. I started this > work because I thought the document doesn't belong in the > Docu section, and needed updating, without being aware of > the potential problems with SGML. By the time I was done, > I was completely horrified by this SGML business. It has > it's advantages, but they come at a hefty price, so we > have to be very careful when we employ it. It works OK > for documents that don't require a lot of markup, like the > FAQ. In fact, in that case it _saves_ on formating markup. > It works nicely for documents that are essentially books > (such as the User Guide, etc.) where you can expect someone > to print out the nicely formatted .pdf/.ps. However, for > technical documents that need to be maintained often, and > are useful as a online resource that people are likely to > open in an editor, it blows chunks. Now I start to understand > Alexandre's preference for troff for man pages... Hehe, I'm glad I'm not the only one who thinks DocBook is overrated - I've been wrestling with it for the past few weeks as part of writing a shared packaging metadata spec, and an automatic documentation framework for bash libraries, and I have NEVER got it to work correctly. I've found that clean HTML with some small CSS can make a document that looks more professional (imo) and is far easier to read in a text editor, not least because emacs (and i assume vim) can apply the formatting in the tags to the text itself. I've never looked at troff, but free software seems to need a better documentation/markup system - DocBook SGML just seems far, far too complex for doing something that is essentially quite simple.

1 0

Re: PATCH: Winemaker's --wrap option
by Jeremy Newman 12 Apr '03

12 Apr '03

Please stop resending this message to the list. I have gotten more than 20 copies of this message now. On Tue, 2003-04-08 at 14:59, Javier López wrote: > ----- Original Message ----- > From: "Juraj Hercek" <juraj(a)syncad.com> > To: <wine-patches(a)winehq.com> > Sent: Tuesday, April 08, 2003 4:35 AM > Subject: PATCH: Winemaker's --wrap option > > > > Changelog: > > > > Juraj Hercek <juraj(a)syncad.com> > > * tools/winemaker : > > Fixed generation of makefiles and wrapper files when "--wrap" option > > is used. > > > > <snip> -- Jeremy Newman <jnewman(a)codeweavers.com> CodeWeavers, Inc.

4 3

Re: wine/dlls make_dlls Makefile.in Makedll.rules.in
by Vincent Béron 12 Apr '03

12 Apr '03

Alexandre Julliard a écrit: > ChangeSet ID: 7854 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2003/04/11 19:05:28 > > Modified files: > dlls : make_dlls Makefile.in Makedll.rules.in > > Log message: > Fixed rules for auto documentation (reported by Vincent Béron). > > Patch: http://cvs.winehq.com/patch.py?id=7854 > > Old revision New revision Changes Path > 1.23 1.24 +19 -0 wine/dlls/make_dlls > 1.172 1.173 +19 -0 wine/dlls/Makefile.in > 1.52 1.53 +4 -13 wine/dlls/Makedll.rules.in Not good. Won't work correctly for dlls containing subdirs with a Makefile (msacm, etc.). In those cases, only the first level directory will be processed, not the subdirs. Vincent

2 1

Provide USB support in wine ?
by Sylvain Petreolle 11 Apr '03

11 Apr '03

"Accidentally", when updating my RH system, I discovered that libusb is a library that provides user access to the USB devices, regardless of the OS. It appears we could use it in wine, since : - its license compatible (LGPL) - it supports some OSes on which wine is built. Like : Linux FreeBSD NetBSD, OpenBSD (dont know if this works now, referring to http://www.winehq.com/?page=faq#Under_what_hardware_platforms_and_Wine) Darwin (never heard of it for Wine ??) MacOS X (recent Qemu work makes this possible) Could such a support be possible/doable ? ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

5 4

ttydrv on a remote console
by Uwe Bonnes 11 Apr '03

11 Apr '03

Hallo, I am trying to run a complex command line (XST from Xilinx) program with X disabled, like on a remote terminal. With "GraphicsDriver" = "ttydrv" and called like "~/tmp/wine/compile/wine/wine -- /tmp/webpack-5.2/bin/nt/xst -quiet -ifn __projnav/dacswitch.xst -ofn dacswitch.syr" it soon crashes. I tracked it down to a failing WM_NCCREATE mesage in TTYDRV_CreateWindow. Returning unconditional TRUE in TTYDRV_CreateWindow makes the program run. With x11drv, called on the command line like above, wndPtr->parent is not set and the clause { create_desktop( display, wndPtr, cs ); WIN_ReleasePtr( wndPtr ); return TRUE; } is taken. Any ideas? Running with wineconsole and wcmd resulted in a scrambled screen and a crash too. Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Contrib page update
by Dimitrie O. Paun 11 Apr '03

11 Apr '03

They'll be added to the Fun Projects on the next update to that page. ChangeLog Move some of the tasks to the Fun Projects where they belong. Index: templates/en/contributing.template =================================================================== RCS file: /home/wine/lostwages/templates/en/contributing.template,v retrieving revision 1.5 diff -u -r1.5 contributing.template --- templates/en/contributing.template 30 Mar 2003 15:59:45 -0000 1.5 +++ templates/en/contributing.template 11 Apr 2003 15:40:07 -0000 @@ -33,9 +33,7 @@ <ol> <li><a href="#devel_task">Some development task</a> </li><li><a href="#conf_tests">Conformance tests</a> - </li><li><a href="#cross">Cross referencing the windows executables and libraries</a> </li><li><a href="#doc_win_api">Documentation of the windows API functions</a> - </li><li><a href="#check_which">Check which APIs are missing for a given program</a> </li><li><a href="#port_app">Port your windows application to wine</a> </li><li><a href="#code_review">Perform a focused code review</a> @@ -284,24 +282,6 @@ </li></ul> - <a name="cross"></a> - <h3>Cross referencing the Windows executables and libraries</h3> - - <p>The idea is to write a Perl script that analyzes the Windows dlls and executables of a - regular Windows installation and cross references them. This would generate Web pages - telling you which API is used by which program/library and reciprocally. - Analyzing the import/export section of PE executables is quite simple: it's just a matter - of running dumpbin (part of Visual C++) or pedump (open source) on them and then parsing - the resulting text file. This already being done with the wpbtk toolkit. - To view winapi_check output see <a href="http://fgouget.free.fr/wine/winapi_stats-en.shtml">Quick API statistics</a>. - To help with this please contact <a href="mailto:fgouget@free.fr">Francois Gouget</a> - </p> - Required skills: - <ul> - <li>Perl - </li><li>General HTML - </li></ul> - <a name="doc_win_api"></a> <h3>Documentation of the Windows API functions</h3> @@ -320,28 +300,6 @@ <ul> <li>Knowledge of some documentation generation system for the person trying to enhance the documentation generation. </li><li>A bit of C to document the APIs themselves. - </li></ul> - - <a name="check_which"></a> - <h3>Check which APIs are missing for a given program</h3> - - <p>The scripts that scan a Windows environment could be modified to restrict the scan to the dependencies - of a given executable/set of executables. Then these results can be cross-referenced with the results - of the above script to tell you which APIs this program is missing, what percentage they represent, etc. - Reciprocally one can weight each API according to how often they are referenced in a given environment to - produce an approximation of the likely hood that such an API will actually be called. Note that this would - just be an approximation because we would miss all the dynamically loaded APIs and libraries - (since we only scan the statically linked dynamic libraries). This would be an even more approximate - measure of the likely hood that the program will work: even though a program references an API it may never call it, - work even though this API does not work, or really depend on this API or even some undocumented aspect of this API. - Still this may provide a better approximation of the completeness of Wine than just treating all APIs as equivalent. - </p> - Required skills: - <ul> - <li>Perl - - </li><li>General HTML to present the results - </li><li>Maybe querying a database will be necessary too </li></ul> <a name="port_app"></a> -- Dimi.

2 1

Re: Contributing: Check which APIs are missing for a given program
by Pouech Eric DMI AEI CAEN 11 Apr '03

11 Apr '03

> Would it be helpful if pedump were supported so you don't need dumpbin from Visual C++ to be able to use the scripts? winedump (in the tools directory) has some of the features of pedump A+

2 1

WineHQ: updated Fun Projects
by Dimitrie O. Paun 11 Apr '03

11 Apr '03

ChangeLog Remove the links from the title sections (visited links were invisible due to the color scheme). Small cleanups. Move the cross referencing tasks from the Contributing page. Index: templates/en/fun_projects.template =================================================================== RCS file: /home/wine/lostwages/templates/en/fun_projects.template,v retrieving revision 1.3 diff -u -r1.3 fun_projects.template --- templates/en/fun_projects.template 30 Mar 2003 16:23:41 -0000 1.3 +++ templates/en/fun_projects.template 11 Apr 2003 17:27:03 -0000 @@ -57,7 +57,6 @@ which would be <em>uber</em>cool. <h4 class=inprogress>Cygwin under Wine in Linux</h4> - This provides an a good test case for Wine. It is tough, but we do have the Cygwin source code, and we have a good chance to understand why it does not work. @@ -67,7 +66,6 @@ <li>status: runs <tt>bash -l -i</tt> and logs out <li>updated: Dec 4, 2002 </ul> - <h4 class=inprogress>Wine under Cygwin in Windows</h4> This will provide a good test case for Cygwin, but will help Wine's @@ -88,20 +86,18 @@ need to have a MinGW port on Windows (that is, they need to support building under MinGW). - <h4 class=todo><a name="jvm" href="http://java.sun.com">Java Virtual Machine</a></h4> + <a name="jvm"></a><h4 class=todo>Java Virtual Machine</h4> There are three noteworthy Java implementations: <dl> <dt><a href="http://java.sun.com/j2se/">Sun's JVM</a></dt> <dd>Unfortunately, the Windows port requires MSVC to build. How ironic.</dd> - <dt><a href="http://www.ibm.com/developerworks/java">IBM's JVM</a></dt> <dd>I can't seem to be able to find the sources for this one. Help!</dd> <dt><a href="http://www.kaffe.org">Kaffe</a></dt> <dd>This one seems to have ports to Cygwin and MinGW. Good candidate for a port.</dd> </dl> - <h4 class=todo><a name="perl" href="http://www.perl.com">Perl</a></h4> - + <a name="perl"></a><h4 class=todo>Perl</h4> Any Perl monger up for this? <ul> <li>worker: wanted @@ -112,10 +108,9 @@ <strong>Update:</strong> The ActivePerl branch support building under both Cygwin and MinGW. This is a very good test for <tt>winegcc</tt>. Unfortunately, the MinGW makefile uses backslashes as fileseparator, so it will take a bit of work to get working under Linux. - Why do people use backslash, when the forward slash works on both Windows and Linux? Eh... - - <h4 class=todo><a name="python" href="http://www.python.org">Python</a></h4> + Why do people use backslash, when the forward slash works on both Windows and Linux? + <a name="python"></a><h4 class=todo>Python</h4> Not very exciting, but still interesting port. It's a good test for the non graphic APIs, such as threading, files, etc. <ul> @@ -126,7 +121,6 @@ </ul> <strong>Update:</strong> Configure the packages like so: <pre> - CC=winegcc CXX=wineg++ configure --with-suffix --without-threads </pre> Unfortunately, configure gets confused about the executable extension, @@ -141,8 +135,7 @@ to create portable UI toolkits. Due to the large UI component of the Win32 API, these are a perfect test for Wine. - <h4 class=todo><a name="qt" href="http://www.trolltech.com/products/qt/windows.html">QT</a></h4> - + <a name="qt"></a><h4 class=todo>QT</h4> Imagine we compile QT under Wine, and then we get the entire <a href="http://www.kde.org">KDE</a> compiled and running under Wine! How cool would that be? <ul> @@ -150,7 +143,6 @@ <li>status: initial investigation <li>updated: Jan 6, 2003 <li>homepage: <a href="http://www.trolltech.com/products/qt/windows.html">www.trolltech.com/products/qt/windows.html</a> - </ul> <strong>Update:</strong> Unfortunately, QT/Windows is not free software. Moreover, it requires MSVC or the Borland toolchain to build. Before we can start thinking about @@ -159,7 +151,7 @@ <a href="http://www.troll.no">Troll's</a> part to support such an effort. If you think you can make a case for it, please let us now. - <h4 class=todo><a name="gtk" href="http://www.gtk.org">Gtk+</a></h4> + <a name="gtk"></a><h4 class=todo>Gtk+</h4> This is maybe a little less interesting than the others, as Gtk+ does not use the native widgets when ported to Windows. Instead, it uses it's very thin abstraction layer (gdk) to do the drawing, all else is build 'in house'. @@ -168,17 +160,15 @@ <li>status: todo <li>updated: Jan 6, 2003 <li>homepage: <a href="http://wingtk.sourceforge.net/">wingtk.sourceforge.net</a> - </ul> - <h4 class=done><a name="wxwindows" href="http://www.wxwindows.org">wxWindows</a></h4> + <a name="wxwindows"></a><h4 class=done>wxWindows</h4> A perfect test case for Wine's headers, and MinGW emulation! Wouldn't it be cool to have the Windows controls available on Linux too? <duck/> :-) <ul> <li>worker: <a href="mailto:dpaun@rogers.com">Dimitrie O. Paun</a> - <li>status: compiles, links, and runs! + <li class=modified>status: compiles, links, and runs! The <a href="http://www.winehq.com/hypermail/wine-devel/2003/01/0153.html">patch</a> - has been accepted in the official wxWindows tree! <li>updated: Jan 7, 2003 <li>homepage: <a href="http://www.wxwindows.org">www.wxwindows.org</a> @@ -215,7 +205,6 @@ free version available, but apparently you can buy one for around $100US. <ul> <li>worker: <a href="mailto:ps@leissner.se">Patrik Stridvall</a> - <li>status: most tests work, DLLs are pretty bad though <li>updated: Nov 29, 2002 </ul> @@ -228,7 +217,6 @@ <li>status: todo <li>updated: Jan 6, 2003 <li>homepage: <a href="http://www.borland.com/bcppbuilder/freecompiler/">www.borland.com/bcppbuilder/freecompiler</a> - </ul> <h3 class=todo>Watcom's cc</h3> @@ -252,12 +240,49 @@ <h2>Miscellaneous Projects</h2> This is a catch-all category for all sort of strange (and sometimes cute) ideas. + <a name="cross"></a><h3 class=inprogress>Cross referencing the Windows executables and libraries</h3> + <p>The idea is to write a Perl script that analyzes the Windows dlls and executables of a + regular Windows installation and cross references them. This would generate Web pages + telling you which API is used by which program/library and reciprocally. + Analyzing the import/export section of PE executables is quite simple: it's just a matter + of running dumpbin (part of Visual C++) or pedump (open source) on them and then parsing + the resulting text file. This already being done with the wpbtk toolkit. + <ul> + <li>worker: <a href="mailto:compsol@ptd.net">Dave Miller</a> + <li>status: Prototype ready + <li>updated: Apr 11, 2003 + </ul> + <strong>Update:</strong> + Currently the script can make HTML maps of the dll imports. I've been too + lazy to integrate the program that processed that into a table so + far. :) Right now it requires dumpbin (Visual C++) I plan to add pedump + or winedump support so more people are able to use it. It is also + analyzing the wine .spec files to determine if each API has an entry and + reports whether it's a stub, unimplemented (not in spec files), etc. + + + <a name="check_which"></a><h3 class=inprogress>Check which APIs are missing for a given program</h3> + <p>The scripts that scan a Windows environment could be modified to restrict the scan to the dependencies + of a given executable/set of executables. Then these results can be cross-referenced with the results + of the above script to tell you which APIs this program is missing, what percentage they represent, etc. + Reciprocally one can weight each API according to how often they are referenced in a given environment to + produce an approximation of the likely hood that such an API will actually be called. Note that this would + just be an approximation because we would miss all the dynamically loaded APIs and libraries + (since we only scan the statically linked dynamic libraries). This would be an even more approximate + measure of the likely hood that the program will work: even though a program references an API it may never call it, + work even though this API does not work, or really depend on this API or even some undocumented aspect of this API. + Still this may provide a better approximation of the completeness of Wine than just treating all APIs as equivalent. + <ul> + <li>worker: <a href="mailto:compsol@ptd.net">Dave Miller</a> + <li>status: Starting work <a href="http://www.winehq.com/hypermail/wine-devel/2003/04/0324.html">soon</a>. + <li>updated: Apr 11, 2003 + </ul> + <h3 class=inprogress>GDI Engine</h3> Integrate the GDI engine contributed by the <a href="http://www.transgaming.com">Transgaming</a> folks. <ul> <li>worker: <a href="mailto:johane@lysator.liu.se">Johan Gill</a> - <li>status: <i>It should be ready for submission in a few months from now.</i> <li>updated: Feb 22, 2003 </ul> @@ -270,7 +295,6 @@ <a href="http://bugs.winehq.com/show_bug.cgi?id=1304">Bug #1304</a>. <h3 class=todo>Wine Explorer</h3> - <p>A Windows Explorer replacement. People migrating from Windows would love it, and it would provide a great testbed for our <tt>shell32</tt> DLL, as well as some key controls such as the List-View Common Control. @@ -287,7 +311,6 @@ <li> A "Cancel" button (that changes to "Close" when tests are done) <li> A "Report..." button that brings up a "Save As..." dialog </ul> - Not hard to write, and quite cool to play with. Anyone familiar with the Win32 API can do it. -- Dimi.

1 0

winebuild incompatibility with binutils-2.13.90.0.20
by Piotr Pawłow 11 Apr '03

11 Apr '03

Hi, There is a change in "nm -u" output format in the new binutils, now it outputs "U " before every symbol name. It looks like this: $ nm -u d3d8.dll.tmp.o U cos U CreateDCA U DeleteDC U ExtEscape U GetClientRect U GetDC U GetDesktopWindow U GetDeviceCaps U GetModuleHandleA U GetProcAddress U GetPropA (...) Winebuild parser is not prepared for that. It does not find proper symbol names, creates spec.c files with no imports, and the result is that linking fails on unresolved symbols, as reported in "--with-nptl and glibc-2.3.2" thread. A quick fix: Index: tools/winebuild/import.c =================================================================== RCS file: /home/wine/wine/tools/winebuild/import.c,v retrieving revision 1.48 diff -r1.48 import.c 664a665,667 > if (*p == 'U') { > if (p[1] == ' ') p+=2; > } Shouldn't winebuild, however, use libbfd where available, instead of relying on nm output? -- Piotr Pawłow mailto:pp@siedziba.pl

3 5

Re: CxxFrameHandler problem
by John K. Hohm 11 Apr '03

11 Apr '03

Alexandre Julliard <julliard(a)winehq.com> wrote: > Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > > > Appended program uses CxxFrameHandler and crashes in wine with builtin > > msvcrt, but not with native. Compile as Release version and include the > MFC > > dll. Can somebody compile for Alexandre? Alexandre, is this a start or do > > you need something complete? > > That's a start, yes, thanks. I'll need a more complete example with > nested try blocks, destructors all over the place, typed exceptions, > etc. to make sure I understand all the compiler internal structures; > but I can at least try to make that simple case not crash... Although this may duplicate effort, I am familiar with several strange combinations of exception handling that I know work with Visual C++ 6.0; I will put them a test program for you. You can never have too many test programs, right?

1 1

Re: Re: wcmd, external commands, and options
by Pouech Eric DMI AEI CAEN 11 Apr '03

11 Apr '03

> I don't think we need to change CreateProcess at all. In > my tests, Wine matched Win9x's CreateProcess behavior nicely. > All the changes we need are in wcmd, I think. > - Dan that's correct (I later checked also CreateProcess) wcmd is to blame. I may have a look afterwards at wcmd (I'm currently on a two week trip, without any Linux box at hand) A+

1 0

Wine's test process
by Eduardo Augusto Bezerra 10 Apr '03

10 Apr '03

Hi I've been working on the definition of testing processes for open source projects and, so far, Open Office is one of the most organized projects I've found. The bug tracking system of Wine is quite good, but I haven't found much about the definition of Wine's test process. I was wondering whether somebody in this discussio list could send me some pointers or documents where I could learn more about Wine's test process. Basically, I've been looking for a place where I could find answers for questions such as: How has the test process been defined in the beginning of the Wine project? How was the test process performed at that time? How was the test process performed when there were no web versions for the bug reports? Are there test plans available? My research is not based only on Wine. I've been trying to find other open source projects that have an organized and documented test process, but it's quite hard. Many thanks for any help Eduardo. -- Eduardo Augusto Bezerra, PhD Space Science Centre, School of Engineering and IT The University of Sussex, Brighton, England, UK http://www.sussex.ac.uk/engg/research_groups/space/ Researcher, Software Testing Research Centre (CPTS) PUCRS/Hewlett-Packard Brazil, Porto Alegre, RS, Brazil Lecturer in Computer Science, Informatics Faculty Catholic University (PUCRS), Porto Alegre, RS, Brazil http://www.inf.pucrs.br/~gaph Phone/Fax UK: +44 (0)1273 877086 / +44 (0)1273 678399 Phone/Fax Brazil: +55 51 3320 3695 / +55 51 3320 3758 http://www.eduardo.bezerra.name PGP signature: Key ID B852E578 Public Key: http://www.keyserver.net/en/ or http://eduardo.bezerra.name

1 0

Problem actually with binutils, oops!
by Scott Carmichael 10 Apr '03

10 Apr '03

Okay, so in any event, does anyone know when this will be fixed? Downgrading from 2.13.90.0.20 to 2.13.90.0.18 seems to fix the problem... But does anyone know why? And is this a wine problem? Or binutils? Thanks, Scott

2 1

Contributing: Check which APIs are missing for a given program
by Dave Miller 10 Apr '03

10 Apr '03

I plan to be working on this soon. It should be able to share pieces of the script which cross references dlls and will create an API database (plain text file for now). Before I get started I have a couple of questions. Do we intend to gather all this information together and keep it? In a database, in the application database, in bug reports, etc. Or is it more for a developer trying to get a specific application working? What information should exist in the API database? Currently it outputs the spec file, API name, and whether it is a stub, forward, stdcall, etc. Does anyone think more information is needed? Would it be helpful if pedump were supported so you don't need dumpbin from Visual C++ to be able to use the scripts?

1 0

dos games, vesa and wine
by Enrico Horn 10 Apr '03

10 Apr '03

Hi, Another day, another round of questions concerning this topic. I tried my dos4gw games with dos32a and they "work"(except some warning dos32a prints) but you have to run these games like this to get an result: wine -- dos32a game.exe thats is because the stub which loads the dos extender doesnt work and i have no idea why. the behaviour is the following(trace of +int21): allocate 1 block of memory resize block to 65536(this fails returnnig number of available blocks) resize block to whats available allocate 1 block of memory(this fails as all is already allocated) close all files, print error message and exit the games i use all make use of vesa they want 640x480x256 ddraw traces show a primary surface that is 8bit paletted. is there any problem drawing this thing? where is this done? is there a routine that regularly updates the screen with content of this surface? i have looked in x11drv(can it be that x11drv is in need of a rewrite?) and havent found anything but i am not expert at this and just poke around randomly where i see an interest. Thanks for putting up with me Enrico

1 0

About new RH glinc issue
by Sylvain Petreolle 10 Apr '03

10 Apr '03

This is what I received today from Red Hat Network, maybe it could our issue. ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 3

0408 w/ glibc 2.3.2 still broken
by Scott Carmichael 10 Apr '03

10 Apr '03

> WHAT'S NEW with Wine-20030408: (see ChangeLog for details) > - Support for all variants of glibc 2.3. I'm still getting errors with glibc 2.3.2. The same ones I was getting with -20030318. Anyone know why this is? :) Unfortunately, the LD_ASSUME_KERNEL fix doesn't seem to work, as it seems to break everything else on my system needed to run the actual build. =\ Thanks, and the log of the fail follows... make[2]: Entering directory `/home/jobe/wine-20030408/dlls/d3d8' gcc -shared -Wl,-Bsymbolic,-z,defs d3d8.spec.o basetexture.o cubetexture.o d3d8_main.o device.o directx.o indexbuffer.o resource.o shader.o stateblock.o surface.o swapchain.o texture.o vertexbuffer.o volume.o volumetexture.o vshaderdeclaration.o d3d8.dll.dbg.o -o d3d8.dll.so -L../../dlls -L../../libs/wine -lwine -L../../libs/uuid -lwine_uuid -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf86vm -lXv -lXext -lX11 -lGL -lGLU -L../../libs/port -lwine_port -lm -lc basetexture.o(.text+0x281): In function `IDirect3DBaseTexture8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' cubetexture.o(.text+0x2d2): In function `IDirect3DCubeTexture8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' d3d8_main.o(.text+0xf4): In function `Direct3DCreate8': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' d3d8_main.o(.text+0x1ba): In function `DllMain': /home/jobe/wine-20030408/dlls/d3d8/d3d8_main.c:64: undefined reference to `GetModuleHandleA' d3d8_main.o(.text+0x1d5):/home/jobe/wine-20030408/dlls/d3d8/d3d8_main.c:67: undefined reference to `GetProcAddress' d3d8_main.o(.text+0x1f2):/home/jobe/wine-20030408/dlls/d3d8/d3d8_main.c:68: undefined reference to `GetProcAddress' device.o(.text+0x35c1): In function `IDirect3DDevice8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x385c): In function `IDirect3DDevice8Impl_GetDisplayMode': /home/jobe/wine-20030408/dlls/d3d8/device.c:1081: undefined reference to `GetSystemMetrics' device.o(.text+0x3870):/home/jobe/wine-20030408/dlls/d3d8/device.c:1082: undefined reference to `GetSystemMetrics' device.o(.text+0x38a6):/home/jobe/wine-20030408/dlls/d3d8/device.c:1085: undefined reference to `CreateDCA' device.o(.text+0x38bb):/home/jobe/wine-20030408/dlls/d3d8/device.c:1086: undefined reference to `GetDeviceCaps' device.o(.text+0x38c8):/home/jobe/wine-20030408/dlls/d3d8/device.c:1087: undefined reference to `DeleteDC' device.o(.text+0x3f77): In function `IDirect3DDevice8Impl_CreateTexture': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x41d7): In function `IDirect3DDevice8Impl_CreateVolumeTexture': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x42ed):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x4385):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x453a): In function `IDirect3DDevice8Impl_CreateCubeTexture': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x47c4):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: more undefined references to `HeapAlloc' follow device.o(.text+0x110ac): In function `IDirect3DDevice8Impl_DeleteVertexShader': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x110cc):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x11117):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x11139):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x111a9):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' device.o(.text+0x116e2): In function `IDirect3DDevice8Impl_CreatePixelShader': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' device.o(.text+0x1195b): In function `IDirect3DDevice8Impl_DeletePixelShader': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' directx.o(.text+0x231): In function `IDirect3D8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' directx.o(.text+0x549): In function `IDirect3D8Impl_GetAdapterModeCount': /home/jobe/wine-20030408/dlls/d3d8/directx.c:150: undefined reference to `GetSystemMetrics' directx.o(.text+0x55b):/home/jobe/wine-20030408/dlls/d3d8/directx.c:151: undefined reference to `GetSystemMetrics' directx.o(.text+0x687): In function `IDirect3D8Impl_EnumAdapterModes': /home/jobe/wine-20030408/dlls/d3d8/directx.c:194: undefined reference to `CreateDCA' directx.o(.text+0x69c):/home/jobe/wine-20030408/dlls/d3d8/directx.c:195: undefined reference to `GetDeviceCaps' directx.o(.text+0x6a9):/home/jobe/wine-20030408/dlls/d3d8/directx.c:196: undefined reference to `DeleteDC' directx.o(.text+0x7bd):/home/jobe/wine-20030408/dlls/d3d8/directx.c:182: undefined reference to `GetSystemMetrics' directx.o(.text+0x7d1):/home/jobe/wine-20030408/dlls/d3d8/directx.c:183: undefined reference to `GetSystemMetrics' directx.o(.text+0x958): In function `IDirect3D8Impl_GetAdapterDisplayMode': /home/jobe/wine-20030408/dlls/d3d8/directx.c:228: undefined reference to `GetSystemMetrics' directx.o(.text+0x96c):/home/jobe/wine-20030408/dlls/d3d8/directx.c:229: undefined reference to `GetSystemMetrics' directx.o(.text+0x9a2):/home/jobe/wine-20030408/dlls/d3d8/directx.c:232: undefined reference to `CreateDCA' directx.o(.text+0x9b7):/home/jobe/wine-20030408/dlls/d3d8/directx.c:233: undefined reference to `GetDeviceCaps' directx.o(.text+0x9c4):/home/jobe/wine-20030408/dlls/d3d8/directx.c:234: undefined reference to `DeleteDC' directx.o(.text+0x109d): In function `IDirect3D8Impl_CreateDevice': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' directx.o(.text+0x11a7): In function `IDirect3D8Impl_CreateDevice': /home/jobe/wine-20030408/dlls/d3d8/directx.c:459: undefined reference to `GetPropA' directx.o(.text+0x11be):/home/jobe/wine-20030408/dlls/d3d8/directx.c:468: undefined reference to `GetDC' directx.o(.text+0x11ff):/home/jobe/wine-20030408/dlls/d3d8/directx.c:56: undefined reference to `ExtEscape' directx.o(.text+0x127f):/home/jobe/wine-20030408/dlls/d3d8/directx.c:480: undefined reference to `GetDesktopWindow' directx.o(.text+0x1291):/home/jobe/wine-20030408/dlls/d3d8/directx.c:480: undefined reference to `GetPropA' directx.o(.text+0x13a0):/home/jobe/wine-20030408/dlls/d3d8/directx.c:496: undefined reference to `ReleaseDC' directx.o(.text+0x143e):/home/jobe/wine-20030408/dlls/d3d8/directx.c:515: undefined reference to `GetClientRect' indexbuffer.o(.text+0x244): In function `IDirect3DIndexBuffer8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' indexbuffer.o(.text+0x264):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' resource.o(.text+0x231): In function `IDirect3DResource8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' shader.o(.text+0xc0a): In function `IDirect3DDeviceImpl_CreateVertexShader': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' shader.o(.text+0xc46):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' shader.o(.text+0x19f8): In function `IDirect3DVertexShaderImpl_ParseProgram': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1064): In function `IDirect3DDeviceImpl_CreateStateBlock': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1402): In function `IDirect3DDeviceImpl_DeleteStateBlock': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' stateblock.o(.text+0x14ed): In function `IDirect3DDeviceImpl_BeginStateBlock': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' surface.o(.text+0x234): In function `IDirect3DSurface8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' surface.o(.text+0x254):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' swapchain.o(.text+0x231): In function `IDirect3DSwapChain8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' texture.o(.text+0x2c3): In function `IDirect3DTexture8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' vertexbuffer.o(.text+0x237): In function `IDirect3DVertexBuffer8Impl_Release': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' vertexbuffer.o(.text+0x269):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: more undefined references to `HeapFree' follow vshaderdeclaration.o(.text+0x6d): In function `IDirect3DDeviceImpl_CreateVertexShaderDeclaration8': /home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' vshaderdeclaration.o(.text+0x114):/home/jobe/wine-20030408/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' collect2: ld returned 1 exit status make[2]: *** [d3d8.dll.so] Error 1 make[2]: Leaving directory `/home/jobe/wine-20030408/dlls/d3d8' make[1]: *** [d3d8] Error 2 make[1]: Leaving directory `/home/jobe/wine-20030408/dlls' make: *** [dlls] Error 2 Compilation failed, aborting install.

1 0

Re: Opening AVI files in Wine
by Tom Hibbert 10 Apr '03

10 Apr '03

On Wed, Apr 09, 2003 at 11:45:07AM -0500, wine-devel-request(a)winehq.com wrote: > From: Pouech Eric DMI AEI CAEN <pouech-eric(a)wanadoo.fr> > Reply-To: pouech-eric(a)wanadoo.fr > To: Tom Hibbert <cartel(a)cryptocracy.hn.org>, wine-devel(a)winehq.com > Subject: Re: Opening AVIs with wine > Date: Wed, 9 Apr 2003 18:31:03 +0200 (CEST) > > Please can someone tell me if it is possible for a wine application > > to open an avi file (or better yet use video for windows codecs). > in generic terms yes. > however, avi is an enveloppe to store video files, but the compression used can vary from file to file > so, you need the specific decompressor to handle a given type of file > normally, wine is ready (under the MCI and the msvfw32 interfaces at least) to play AVI files > however, to get further with your issue, we need to know : > 1/ which interface your program actually uses (MCI, msvfw, directx...) > 2/ which codecs are installed and configured under wine > 3/ the type of compressor used for your file > (btw, does changing the avi file to play changes also what is output - or not output in your case) Hi Pouche, thanks for your quick reply! Combustion uses the Video for Windows interface to open AVIs. The VFW interface is abstracted through a plugin in combustion's plugin system. When i use a native msvfw32.dll the overlays inside the app dissapear and some of the buttons fail to render which is a Bad Thing.. perhaps i need to use some other native supporting libraries in order to use native msvfw32, any suggestions? As for which codecs are installed and configured, I'm not sure how to tell. I've looked in the registry but cant find much. I have installed the DivX codec but thats about all I have done purposefully. The format of the files I want to open is Type 2 DVAVI. Selecting other types doesnt change my output. This is all getting confusing.. I am reading at http://www.microsoft.com/hwdev/tech/stream/vidcap/dvavi.asp that Microsoft provide interfaces for Type 2 DVAVI only, and only for direct show. This is consistent with Combustion's inability to read Type 1 files (under windows of course). Does DirectShow = vfw32? Sorry for the insanely confusing response, Tom

2 1

Re: [RFC] direct sound notify patch
by Alexandre Julliard 10 Apr '03

10 Apr '03

Robert Reif <reif(a)earthlink.net> writes: > Adding a hardware notify introduces the use a new GUID from > dsdriver.h. I had to add initguid.h to get it to compile but is this > the proper thing to do? Should this file be added to libs/uuid? Yes it should be in libuuid, initguid.h should not be used. Also your patch doesn't compile because of references to the removed notifies fields, you probably forgot some files. -- Alexandre Julliard julliard(a)winehq.com

1 0

make htmlpages does not work - regression?
by thomas.mertes＠gmx.at 10 Apr '03

10 Apr '03

Hello I noticed that "make htmlpages" does not work in Wine-20030408 but in Wine-20030318. The problem seems to be in some makefile or configure change since /dlls/Makedll.rules.in still contains the "Rules for auto documentation". but the actual Makefile does not. I have in the moment no time to fix it myself (or search the patch that made this change). Btw. the documentation system is great, but I think that only a few people know that it exists. To start it (according to Jon Griffiths): Run ./configure, make htmlpages, point your browser at documentation/html/index.html, then immediately start sending patches for documentation glitches :-) The interesting dlls (with many docomented functions) are shlwapi.dll and ntdll.dll. Greetings Thomas -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

2 1

Re: Re: wcmd, external commands, and options
by Pouech Eric DMI AEI CAEN 10 Apr '03

10 Apr '03

> On WinMe, it looks like > start/wait notepad.exe > invokes start with the /wait option, but in Wine, > it invokes start\wait.exe. you mean from command.com, keying start/wait does what you do I think we should test if CreateProcess on WinXX does the same or not I suspect CreateProcess to implement an algorithm like: n = 1 a/ take the n first chars of the command line if we can match this with an exec, then run it, and chars from command line from n+1 to end of line are arguments (which get parsed with spaces and rtabs as delimiters) otherwise, increment n and go to a/ wine current implementation is a bit more rustic in a sense that our loop is only made of using spaces as separator for implementing the a/ loop the first thing to do IMO is to add this test case to our create process list A+

2 1

Re: Re: Opening AVI files in Wine
by Pouech Eric DMI AEI CAEN 10 Apr '03

10 Apr '03

> Combustion uses the Video for Windows interface to open AVIs. The VFW > interface is abstracted through a plugin in combustion's plugin > system. When i use a native msvfw32.dll the overlays inside the app dissapear > and some of the buttons fail to render which is a Bad Thing.. perhaps > i need to use some other native supporting libraries in order to use native > msvfw32, any suggestions? > > As for which codecs are installed and configured, I'm not sure how to tell. I've looked in the registry but cant find much. I have installed the DivX codec but thats about all I have done purposefully. > > The format of the files I want to open is Type 2 DVAVI. Selecting other types > doesnt change my output. > > This is all getting confusing.. I am reading at > > http://www.microsoft.com/hwdev/tech/stream/vidcap/dvavi.asp > > that Microsoft provide interfaces for Type 2 DVAVI only, and only for direct show. This is consistent > with Combustion's inability to read Type 1 files (under windows of course). Does DirectShow = vfw32? there are several and different interfaces in windows to play AVI files : - msvfw32 - MCI - direct show the first are not so badly implemented right now, whereas the latest is close to non existent running with-debugsmg +msvfw,mciavi might help sheding some light on the matter A+

1 0

Starcraft Patch
by John Spiegel 10 Apr '03

10 Apr '03

I've done some work getting the patches from http://starcraft-wine.sourceforge.net/ working with CVS wine. Using the patch I'm including, starcraft works perfectly on my machine, run as root using DGA on a 640x480 XF86 layout. In particular the changes to event.c enable the mouse and keyboard with DGA. The changes to input.c make the mouse acceleration work the same in all directions. The changes to mouse.c enable mouse scrolling around the map. I'm using redhat 9, so the patch also has a change to wineinstall so that the configure is set up for rh9. You'll probably need to drop that if you aren't running rh9. Now, it would be great to get these changes merged into mainline wine. However, I imagine they break other stuff somewhere. I don't really know exactly what the changes mean, as I've mostly been converting an old patch over. I believe that the patch to input.c is simple and straightforward enough to be merged in, even if the others aren't. Any comments as to what needs to happen to get these into wine are greatly appreciated. John

1 0

Starcraft Patch
by John Spiegel 10 Apr '03

10 Apr '03

I've done some work getting the patches from http://starcraft-wine.sourceforge.net/ working with CVS wine. Using the patch I'm including, starcraft works perfectly on my machine, run as root using DGA on a 640x480 XF86 layout. In particular the changes to event.c enable the mouse and keyboard with DGA. The changes to input.c make the mouse acceleration work the same in all directions. The changes to mouse.c enable mouse scrolling around the map. I'm using redhat 9, so the patch also has a change to wineinstall so that the configure is set up for rh9. You'll probably need to drop that if you aren't running rh9. Now, it would be great to get these changes merged into mainline wine. However, I imagine they break other stuff somewhere. I don't really know exactly what the changes mean, as I've mostly been converting an old patch over. I believe that the patch to input.c is simple and straightforward enough to be merged in, even if the others aren't. Any comments as to what needs to happen to get these into wine are greatly appreciated. John

1 0

wcmd, external commands, and options
by Dan Kegel 10 Apr '03

10 Apr '03

I noticed tonight while looking for a different problem that wcmd doesn't handle batch file lines consisting of an external command with options but no space between the commandline and the option, e.g. start/wait foo.exe In this case it does not find start.exe. Win98 does find start.exe in this case, and wcmd clearly should, too. I had a quick look at wcmdmain.c, and did the obvious hack --- wcmdmain.c 5 Mar 2003 02:49:04 -0000 1.26 +++ wcmdmain.c 9 Apr 2003 06:05:40 -0000 @@ -558,7 +560,7 @@ int p = 0; case '\0': return; default: - while ((*s != '\0') && (*s != ' ')) { + while ((*s != '\0') && (*s != ' ') && (*s != '/')) { if (p == 0) *p1++ = *s++; else if (p == 1) *p2++ = *s++; else s++; It then realized that /wait was a qualifier, and passed the right thing to CreateProcess: F:\>start/wait xx.exe trace:exec:FindExecutableA File start, Dir - trace:exec:SHELL_FindExecutable start trace:exec:SHELL_FindExecutable SearchPathA returned non-zero trace:exec:SHELL_FindExecutable xlpFile=F:\start.exe,extension=.exe trace:exec:SHELL_FindExecutable .exe file trace:exec:SHELL_FindExecutable found F:\start.exe trace:exec:FindExecutableA returning F:\start.exe trace:process:CreateProcessA app (null) cmdline "start/wait xx.exe" but CreateProcess seems to have screwed up handling the /wait parameter: trace:process:CreateProcessA starting "F:\\start.exe" as Windows binary trace:process:PROCESS_InitWine starting process name="F:\\start.exe" file=0x4 argv[0]="start/wait" and that's the last we hear of /wait. This all works fine if we put a space before the /, in which case the log looks like: trace:process:CreateProcessA app (null) cmdline "start /wait xx.exe" trace:process:CreateProcessA starting "F:\\start.exe" as Windows binary trace:process:PROCESS_InitWine starting process name="F:\\start.exe" file=0x4 argv[0]="start" Hrmph. Guess I should add a print for argv[1] in PROCESS_InitWine. Or leave this to somebody who understands wcmd better than me :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

4 5

Problems with redhat 8 updated to glibc 2.3.2
by Mike Hearn 10 Apr '03

10 Apr '03

Hi, I've just had 3 consecutive reports of practically the same failure on redhat 8 with the latest security updates. Basically, nothing works, the wineinstall script messes up and fails to import the initial registry (it seems to get the fstab parsing wrong as well?) and when run wine reports exceptions like this: 17:36 <ChipX86> trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x4037c166 17:36 <ChipX86> trace:seh:EXC_RtlRaiseException info[0]=00000000 17:36 <ChipX86> trace:seh:EXC_RtlRaiseException info[1]=409ffc68 17:36 <ChipX86> trace:seh:EXC_CallHandler calling handler at 0x400c4a00 code=c0000005 flags=0 17:36 <ChipX86> wine: Unhandled exception, starting debugger... 17:36 <ChipX86> trace:seh:start_debugger Starting debugger "winedbg --debugmsg -all --auto 8 0x18" 17:36 <ChipX86> trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x402af648 17:37 <ChipX86> trace:seh:EXC_RtlRaiseException info[0]=00000000 17:37 <ChipX86> trace:seh:EXC_RtlRaiseException info[1]=00000000 17:37 <ChipX86> trace:seh:EXC_CallHandler calling handler at 0x400c42c8 code=c0000005 flags=0 17:37 <ChipX86> trace:seh:EXC_CallHandler handler returned 2 17:37 <ChipX86> trace:seh:EXC_CallHandler calling handler at 0x400c4a00 code=c0000005 flags=10 17:37 <ChipX86> trace:seh:EXC_CallHandler handler returned 1 17:37 <ChipX86> err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x402af648 (pasted from irc) Can somebody with an up to date redhat box who doesn't mind being a sacrificial lamb look into this? I thought compiling with --with-nptl would fix these problems. BTW all these people were using CVS as of about 10 minutes ago. thanks -mike

3 3

Update
by Dustin Navea 10 Apr '03

10 Apr '03

Hey guys just got finished reading all of your emails from my sbc email, this is my email again, and Im doing better than I was.. I have changed jobs again but this time at my choice. Im now a direct marketing person, making 25-35% commission off the stuff I sell, so I'm making a lot better money than I was as a telemarketer... Got a roommate that's actually paying his rent on time and helping out with the bills... have a cell phone now prepaid, but better than nothing, my number is 1+ 281-610-1680 if anyone wants to give me a call after 9pm CST weekdays or anytime on Sundays (work all day saturdays) hopefully once I get my car I can start saving up for a new computer... Peace out guys -Dustin __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

1 0

Wine on Slashdot
by Dimitrie O. Paun 09 Apr '03

09 Apr '03

Hi folks, Wine's on Slashdot: http://developers.slashdot.org/developers/03/04/08/2125228.shtml?tid=125 Jer, it looks some people are having problem with the new site (read the comments). Anything we can do about that? -- Dimi.

3 2

Stacking of in place OLE objects
by Mike Hearn 09 Apr '03

09 Apr '03

Hi, I'm trying to embed IE into a java app, and although it mostly works fine, there is an annoying painting problem that means sometimes the containing JPanel (a swing component) overdraws what IE drew - ie the clipping doesn't seem to be working correctly. I have a few questions on this: 1) I was under the impression that OLE in place objects are contained within their own child window, and that therefore anything drawn underneath that window should be clipped - is this right? 2) The windows are definately being sent WM_PAINT in the right order, but somewhere along the line the first window is incorrectly allowed to draw on top of the second. Is painting asynchronous when using OLE embedding? If so, is there any way to disable this? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 1

Re: Opening AVIs with wine
by Pouech Eric DMI AEI CAEN 09 Apr '03

09 Apr '03

> However when I try and open or play back an AVI file, I get no output. > I have searched the Web and found on winehq that video for windows is at a 30% > complete state. Is this true? > > Changing msvfw32 to native in the config did not help. > > Please can someone tell me if it is possible for a wine application > to open an avi file (or better yet use video for windows codecs). in generic terms yes. however, avi is an enveloppe to store video files, but the compression used can vary from file to file so, you need the specific decompressor to handle a given type of file normally, wine is ready (under the MCI and the msvfw32 interfaces at least) to play AVI files however, to get further with your issue, we need to know : 1/ which interface your program actually uses (MCI, msvfw, directx...) 2/ which codecs are installed and configured under wine 3/ the type of compressor used for your file (btw, does changing the avi file to play changes also what is output - or not output in your case) A+

1 0

Opening AVIs with wine
by Tom Hibbert 09 Apr '03

09 Apr '03

Hello All, I have successfully gotten Discreet Combustion to start under Wine/Winex CVS. However when I try and open or play back an AVI file, I get no output. I have searched the Web and found on winehq that video for windows is at a 30% complete state. Is this true? Changing msvfw32 to native in the config did not help. Please can someone tell me if it is possible for a wine application to open an avi file (or better yet use video for windows codecs). Thanks, Tom Hibbert Work: someday Home: +649 815 1838 Obtain my GPG Key from: http://cryptocracy.hn.org/pubkey.txt

1 0

Re: Janitorial status?
by Rolf Kalbermatter 09 Apr '03

09 Apr '03

Hans Leidekker <hans(a)it.vu.nl> wrote: >> BTW, if you feel like working on something, programs/winecfg is a good >> start. All you need is C and Win32 programming an you're all set. Besides, >> it blocks a big chuck of the 0.9 TODO: >> http://www.dssd.ca/wine/Wine-0.9-TODO.html#winecfg > >Well, thanks for the hint, but I think I'll go back to that regression >test I started for file change notifications then. Is this about SHChangeNotify() or do you mean low level file system events? The first has currently a serious problem with notifications for files which don't exist anymore. I'm working currently on it, to make this work. Rolf Kalbermatter

2 1

Janitorial status?
by Hans Leidekker 09 Apr '03

09 Apr '03

Hi, I was looking for a way to kill some time when I ended up on (WineHQ's version of) Dimi's janitorial page. It seems the page could use an update since as of this moment some of the items seem to have been finished, or nearly so: tools/winapi_check/winapi_check --none --progress --cross-call-win32-win16 [...] loader/module.c: kernel32: WIN32_GetProcAddress16: illegal call to GetProcAddress16 (Win32 -> Win16) scheduler/syslevel.c: kernel32: _KERNEL32_86: illegal call to _LeaveSysLevel (Win32 -> Win16) [...] There must have been some problem converting these? Or were they introduced after the cleanup maybe? I decided to look further: tools/winapi_check/winapi_check --none --progress --cross-call-unicode-ascii [...] dlls/winmm/driver.c: winmm & winmm: OpenDriverW: illegal call to HEAP_strdupWtoA (Unicode -> ASCII) dlls/winmm/driver.c: winmm & winmm: OpenDriverW: illegal call to OpenDriverA (Unicode -> ASCII) [...] What's the story here? I decided to take on the 'Include statements should use <> instead of ""' item, as it seems nobody else is working on that (except Patrick Stridvall who created that useful patch to winapi_cleanup of course). My plan is to supply one patch for each directory in $WINE_SRC/* and $WINE_SRC/dlls/*, in 'ls' sorting order, to keep the patch size down. Is that OK with you? -Hans ----------------------------------------------- Hans Leidekker Vrije Universiteit Dienst IT Systeembeheer Campusnetwerk De Boelelaan 1105 1081 HV Amsterdam +31 (0) 20 444 5385 The Netherlands -----------------------------------------------

2 4

Fw: Wine release 20030408
by BiGgUn 09 Apr '03

09 Apr '03

Extracted from http://source.winehq.org/source/README 4. COMPILATION (...) To upgrade to a new release by using a patch file, first cd to the top-level directory of the release (the one containing this README file). Then do a "make clean", and patch the release with: gunzip -c patch-file | patch -p1 where "patch-file" is the name of the patch file (something likeWine-yymmdd.diff.gz). You can then re-run "./configure", and then run "make depend && make". 5. SETUP (...) Don't forget to uninstall any conflicting previous Wine installation first. Try either "dpkg -r wine" or "rpm -e wine" or "make uninstall" before installing. (...) You should read the entire the useful README to get more details. HTH, Stephan

1 0

warnings in dmusic_segment.c and dmusic_synth.c
by Gerald Pfeifer 09 Apr '03

09 Apr '03

I'm getting the following warnings with the new code in dlls/dmusic: dmusic_segment.c:475: warning: initialization from incompatible pointer type dmusic_segment.c:477: warning: initialization from incompatible pointer type dmusic_synth.c:179: warning: initialization from incompatible pointer type dmusic_synth.c:373: warning: initialization from incompatible pointer type dmusic_synth.c:388: warning: initialization from incompatible pointer type This is both on SuSE Linux 8.1 and FreeBSD 4.8, so it seems like a generic issue; would you mind having a look? Thanks, Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

1 0

Re: Wine release 20030408
by Oliver Ob [o.b./RSi/TRSi/NSD] 09 Apr '03

09 Apr '03

Alexandre Julliard schrieb: > > This is release 20030408 of Wine, a free implementation of Windows on > Unix. This is still a developers only release. There are many bugs > and unimplemented features. Most applications still do not work > correctly. > > WHAT'S NEW with Wine-20030408: (see ChangeLog for details) > - Some reorganizations of the source tree. > - File change notifications. > - Support for all variants of glibc 2.3. > - Many documentation updates. > - Lots of bug fixes. > > See the README file in the distribution for installation instructions. > > Because of lags created by using mirror, this message may reach you before > the release is available at the ftp sites. The sources will be available > from the following locations: > > http://www.ibiblio.org/pub/Linux/ALPHA/wine/development/Wine-20030408.tar.gz > http://prdownloads.sourceforge.net/wine/Wine-20030408.tar.gz > > It should also be available from any other site that mirrors ibiblio.org. > These locations also hold pre-built documentation packages in various > formats: wine-doc-html.tar.gz, wine-doc-txt.tar.gz, > wine-doc-pdf.tar.gz and wine-doc-ps.tar.gz. > > You can also get the current source directly from the CVS tree. Check > http://www.winehq.com/cvs for details. > > Patches should be submitted to "wine-patches(a)winehq.com". Please > don't forget to include a ChangeLog entry. If you submitted a patch, > please check to make sure it has been included in the new release. > > If you want to receive by mail a patch against the previous release > when a new one is released, you can subscribe to the mailing list at > http://www.winehq.com/mailman/listinfo/wine-releases . > > Wine is available thanks to the work of many people. See the file > AUTHORS in the distribution for the complete list. > > -- > Alexandre Julliard > julliard(a)winehq.com Hi Alexandre. I am new to Linux. Where can I read about how the wine is updated? Deinstall the old one and then put the new one on? Or is there a better way? -- *º¤.,___,.¤º*¨¨¨*¤ =Oliver@home= *º¤.,¸¸¸,.¤º*¨¨*¤ I / __|__ http://www.bmw-roadster.de/Friends/Olli/olli.html I I / / |_/ http://www.bmw-roadster.de/Friends/friends.html I I \ \__|_\ http://groups.yahoo.com/group/VGAP-93 I I \___| mailto:VGAP-93-subscribe@yahoogroups.com I >>> Telek0ma iBBMS - moving house, but online! +49....TRSi1 <<<

1 0

Re: Re: Re: Re: Stuck on threading
by Pouech Eric DMI AEI CAEN 09 Apr '03

09 Apr '03

> Yeah, what I meant was, how do you alter the current thread so you can > move up and down the stack frame as seen in the backtrace of that > thread? current thread is not altered, it's just stopped as long as you don't enter step/cont... commands then up/dn are just indexes to current thread's stack (which doesn't change since it doesn't execute) the up/dn commands are not available on other threads than current A+

1 0

Re: MaskBlt implementation.
by Dan Kegel 09 Apr '03

09 Apr '03

> BYTE SwapROP3_SrcDst(BYTE bRop3) > { > /* swap 1,2 bit and 5,6 bit */ > BYTE bit1 = (bRop3 & 0x04) ? 0x02 : 0; > BYTE bit2 = (bRop3 & 0x02) ? 0x04 : 0; > BYTE bit5 = (bRop3 & 0x40) ? 0x20 : 0; > BYTE bit6 = (bRop3 & 0x20) ? 0x40 : 0; > return (bRop3 & 0x99) | bit1 | bit2 | bit5 | bit6; > } How 'bout BYTE SwapROP3_SrcDst(BYTE bRop3) { /* swap 1,2 bit and 5,6 bit */ BYTE bits44 = (bRop3 & 0x44) >> 1; BYTE bits22 = (bRop3 & 0x22) << 1; return (bRop3 & 0x99) | bits22 | bits44; } -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 1

Re: MaskBlt implementation.
by Dimitrie O. Paun 09 Apr '03

09 Apr '03

On April 8, 2003 05:42 pm, Jaekil Lee wrote: > Now, I'm implementing MaskBlt using BitBlt. > I posted same code in www.codeproject.com as MaskBlt in Windows 9x. Suggestions: -- get rid of the C++ stuff (the ::) -- provide a patch (see http://www.winehq.org/?page=sending_patches) Small nits (IMHO): -- get rid of ROP3FromIndex(), just use ROP3Table directly -- rewrite SwapROP3_SrcDst() (see below) -- this is really picky, but I'd rename {FORE,BACK}_ROP3 to something a little more common like {FOREGND,BKGND}_ROP3 I found BACK a little confusing here. Possible SwapROP3_SrcDst() replacement: BYTE SwapROP3_SrcDst(BYTE bRop3) { /* swap 1,2 bit and 5,6 bit */ BYTE bit1 = (bRop3 & 0x04) ? 0x02 : 0; BYTE bit2 = (bRop3 & 0x02) ? 0x04 : 0; BYTE bit5 = (bRop3 & 0x40) ? 0x20 : 0; BYTE bit6 = (bRop3 & 0x20) ? 0x40 : 0; return (bRop3 & 0x99) | bit1 | bit2 | bit5 | bit6; } -- Dimi.

1 0

Re: PuTTY: server infinite loop
by Dimitrie O. Paun 09 Apr '03

09 Apr '03

Alexandre, Did you get a chance to look at this? http://www.winehq.com/hypermail/wine-devel/2003/04/0109.html Is it a server bug, or my setup busted? I think it's been there for the longest time, since PuTTY freezed like so for at least 2-3 months. Unfortunately, I can't do regression testing since my cvsup is broken. Unfortunately, no one seems to know how to fix it, and I can find only RedHat 6 binaries. Damn Modula 3! :) -- Dimi.

2 2

hi wine team
by Yu Neil 09 Apr '03

09 Apr '03

hello: did the wine team consider construct the win32 support (wine) within a micro-kernel architecture, just like the microsoft`s interix ? Neil Yu _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

2 1

Re: Wine start.exe
by Dan Kegel 08 Apr '03

08 Apr '03

Vilppa Salt wrote: > I posted earlier to the wine-devel about the launching files with params. Now my Wine should be ok. > > In the start.exe the /wait switch doesn't work. If you try to run from wcmd somebatfile.bat file which includes following lines: > > start /wait some-exefile.exe > del some-exefile.exe > > and you have some-exefile.exe in the same directory it fails. This is because the file gets deleted, the wait switch doesn't work. Maybe you could fix it? I would but my c-skills aren't that good. Thanks for the bug report. I'll try to have a look tonight. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Re: Resend: Implements languagegroups functions
by Alexandre Julliard 08 Apr '03

08 Apr '03

Maxime Bellengé <maxime.bellenge(a)laposte.net> writes: > This patch implements the languagegroups functions. > As I have access to a French and English windows 2k+, I set > the resources accordingly for the kernel32 resources. However, as > I don't know the resources for other languages, I have put English > resources in the other nls files. People will have to change them to the > correct values. You should really implement the A functions by calling the W ones instead of duplicating the code. Also I'm not sure there's much point in looking up the info in the registry, we don't support installing locales dynamically anyway so we might as well have a static table in the code. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Re: Re: Stuck on threading
by Pouech Eric DMI AEI CAEN 08 Apr '03

08 Apr '03

> See section 2.6.4 in the wine hackers guide, the command reference: > > bt print calling stack of current thread > bt N print calling stack of thread of ID N (note: this > doesn't change the position of the current frame as > manipulated by the up & dn commands) > up goes up one frame in current thread's stack > up N goes up N frames in current thread's stack it doesn't mean (at least it doesn't implement it) that current thread is changed bt N just 1/ stops thread of ID N (if it isn't stopped already) 2/ prints its backtrace but current thread doesn't change in the process (ie, the cont/step... commands still apply to current thread) Mike, BTW, I don't know why, but my ISP seems to have blacklisted the qinetic domain, so I can't reply to you directly (always thru wine-devel) A+

2 1

Re: Re: Stuck on threading
by Pouech Eric DMI AEI CAEN 08 Apr '03

08 Apr '03

> tid as a parameter for instance, and I can't see any way to switch the > current thread, despite the docs mentioning such a concept. which docs... this isn't implemented in winedbg another solution for this would be using gdb thru winedbg (run winedbg -- --gdb) you'll get gdb as a front end, but communicating thru winedbg to the wineserver using gdb commands, you might be able to control a bit more the threads A+

2 1

Re: IP Multicast
by Mike Hearn 08 Apr '03

08 Apr '03

Anything wrong with this one? FYI it uses a different structure to the original (rejected) patch from Marcus. thanks -mike On Tue, 2003-04-01 at 13:54, Mike Hearn wrote: > Hi, > > This patch adds support for IP multicast sockets to winsock. I stole > liberally from a patch from the summer of 2001 from Marcus, so thanks to > him for that: > > http://www.winehq.com/hypermail/wine-patches/2001/07/0009.html > > ChangeLog: > - Map winsock sockopts to the POSIX equivalents for IP multicast > - Remap winsock1 constant values to winsock2 using a forwarder function > - Change a FIXME to a TRACE, it appeared to be simply reporting progress > > thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

3 2

Stuck on threading
by Mike Hearn 08 Apr '03

08 Apr '03

Hi, I'm a bit stuck. I have a DLL that does a FindWindow on DLL attach, and as part of that it does a GetWindowText which tries to send a message to another thread, using send_inter_thread_message. Other threads then attempt to load a DLL and the loader section prompty deadlocks. In gdb, if I attach at this point I can see a nice backtrace of the thread waiting for the reply to its WM_GETTEXT message, along with the thread ID. I'd quite like to see what the thread it sent the message to is doing, but for some reason in gdb "info threads" doesn't do anything and "thread 18" says, thread ID not known, despite it clearly being there in the backtrace: #5 0x40abd0cf in send_inter_thread_message (dest_tid=18, info=0x4072187c, res_ptr=0x40721874) at message.c:1719 So, I'm wondering if this is due to the funny games Wine plays with threads, I'm on a standard glibc 2.2 system by the way. For some reason I can't use winedbg because it stops with a load of exceptions inside the DLL that seem to be red herrings. Is there any way of switching to a wine thread using gdb to get a backtrace? Is there a sneakier approach I can use to find out why thread 18 has apparently deadlocked? There is probably a race condition here - this program will start some times but not others :( Has anybody got any tips on how to debug this sort of thing? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

3 2

Building WINE with other headers
by Steven Edwards 08 Apr '03

08 Apr '03

Hello, I know we have discussed this before and Dimi put it on the Janitorial site but I dont think we ever came a conclusion on it and I could not find a easy fix. Last time I tried to change the include path manualy I ran in to lots of problems. I would like to attempt to build parts of WINE with only the mingw headers and exclude the winehq headers so I can: 1. Find out where the mingw w32api package is broken. 2. Impove the Wine headers if they are wrong. 3. Not use the winehq headers for the ReactOS (We wont try this untill 1 and 2 are in sync) BTW thanks for the winsock.h patch, it is nice to not have to have a simple command line now. Sorry for the head-ache <g> Steven

2 1

Visual FoxPro 8 / Wine20030318 crash
by Paul McNett 08 Apr '03

08 Apr '03

I crash when building an EXE in the new version of Visual Foxpro. Any ideas? "windows" = "nt351", all dlls built-in. Here's the output leading up to the crash: fixme:hook:NotifyWinEvent (32769,0x50032,1,0)-stub! fixme:pidl:SHLogILFromFSIL (pidl=0x4032b090) fixme:dc:LockWindowUpdate (0x50033), partial stub! fixme:shell:ISVBgCm_fnGetCommandString unknown command string fixme:shell:ISVBgCm_fnGetCommandString unknown command string fixme:shell:ISVBgCm_fnGetCommandString unknown command string fixme:dc:LockWindowUpdate ((nil)), partial stub! fixme:shell:ReadCabinetState 0x4071e2e0 0x000c stub fixme:hook:NotifyWinEvent (32773,0x30031,7,1)-stub! fixme:hook:NotifyWinEvent (32768,0x90032,1,0)-stub! fixme:hook:NotifyWinEvent (32769,0x90032,256,0)-stub! fixme:hook:NotifyWinEvent (32769,0x90032,1,0)-stub! fixme:ole:DispCallFunc Do not know how to handle pvargResult 0x4071e5cc. Expect crash ... fixme:ole:DispCallFunc Method returned 0 err:ole:TLB_ReadTypeLib Loading of typelib L"E:\\src\\vfp\\sbs\\sbs.exe" failed with error 0 fixme:seh:EXC_RtlRaiseException call to unimplemented function kernel32.dll.BeginUpdateResourceA fixme:process:CreateProcessA (E:\prg\vfp8\dw15.exe,...): NORMAL_PRIORITY_CLASS ignored fixme:process:CreateProcessA (E:\prg\vfp8\dw15.exe,...): CREATE_DEFAULT_ERROR_MODE ignored fixme:win32:PE_CreateModule Security directory ignored fixme:ntdll:NtQuerySystemInformation (0x00000005,0x4028d858,0x00010000,(nil)) stub fixme:win32:PE_CreateModule Security directory ignored fixme:advapi:RegisterEventSourceW ((null),L"Microsoft Visual FoxPro"): stub fixme:advapi:ReportEventA stub fixme:advapi:DeregisterEventSource (0x1): stub fixme:wininet:InternetGetConnectedState always returning LAN connection. -- Paul McNett Liberal Earthling

4 5

NTPL & pthreads locks
by Dimitrie O. Paun 08 Apr '03

08 Apr '03

Alexandre, If I understand correctly, we currently implement the pthreads locks on top on Wine locks because the standard pthreads locks are not powerful enough to support all Win32 locking primitives. Integrating these locks is necessary for integrating Wine with the pthreads Universe. Now, given the new NTPL work, would it be possible/feasible/desirable to implement the Win32 locks on top of NTPL primitives (such as futexes)? At the very least it makes the setup a lot more intuitive, and less likely to break. If we are to follow this path, there are portability problems. But do we support this sort of libc integration of Solaris and *BSD? And it seems to me that it shouldn't be too hard for these systems to provide something that would allow us to implement all Win32 locking primitives, and the end result would be a lot less brittle. -- Dimi.

3 3

Re: Re: cleaning the source tree when compiling outside the source tree
by Pouech Eric DMI AEI CAEN 08 Apr '03

08 Apr '03

> I don't think we should do that. IMO we must not modify the source > tree in any way when building in a separate dir. It depends which files we're talking about I think that *~ (and any editor backup files), *rej* *orig* (patch leftovers), .#* (cvs update leftovers) should be removed from the source tree perhaps we need to seperate the semantics from clean and distclean. but at least, from a distclean point of view, I do think it would be great to remove the hereabove mentionned files from the source tree A+

2 1

re: hi wine team
by Dan Kegel 08 Apr '03

08 Apr '03

> did the wine team consider construct the win32 support (wine) within a > micro-kernel architecture, just like the microsoft`s interix ? "Just like microsoft's Interix"? We have no idea how Microsoft implemented that stuff; it's not bundled with Windows, so not many people see it, and it's closed source, so it's a bit hard to distinguish a microkernel from a regular kernel. Please post some code so we know you're not a troll :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

--with-nptl and RH 8 : unhappy
by Sylvain Petreolle 08 Apr '03

08 Apr '03

Having RH 8.0 with glibc-2.3.2, I tried to compile Wine wiht --with-nptl. Wine compiles fine but doesnt run at all. Every application I try to run calls the debugger in a loop. [syl@snoop c]$ wine --debugmsg +relay notepad trace:relay:RELAY_InitDebugLists RelayInclude = L"user32.CreateWindowA" trace:relay:RELAY_InitDebugLists RelayExclude = L"RtlEnterCriticalSection;RtlLeaveCriticalSection;_LeaveSysLevel;_EnterSysLevel" wine: Unhandled exception, starting debugger... trace:relay:RELAY_InitDebugLists RelayInclude = L"user32.CreateWindowA" trace:relay:RELAY_InitDebugLists RelayExclude = L"RtlEnterCriticalSection;RtlLeaveCriticalSection;_LeaveSysLevel;_EnterSysLevel" wine: Unhandled exception, starting debugger... trace:relay:RELAY_InitDebugLists RelayInclude = L"user32.CreateWindowA" trace:relay:RELAY_InitDebugLists RelayExclude = L"RtlEnterCriticalSection;RtlLeaveCriticalSection;_LeaveSysLevel;_EnterSysLevel" wine: Unhandled exception, starting debugger... trace:relay:RELAY_InitDebugLists RelayInclude = L"user32.CreateWindowA" trace:relay:RELAY_InitDebugLists RelayExclude = L"RtlEnterCriticalSection;RtlLeaveCriticalSection;_LeaveSysLevel;_EnterSysLevel" wine: Unhandled exception, starting debugger... trace:relay:RELAY_InitDebugLists RelayInclude = L"user32.CreateWindowA" trace:relay:RELAY_InitDebugLists RelayExclude = L"RtlEnterCriticalSection;RtlLeaveCriticalSection;_LeaveSysLevel;_EnterSysLevel" wine: Unhandled exception, starting debugger... err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0x402fec16 err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0x402fec16 [syl@snoop c]$ err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0x402fec16 err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0x402fec16 err:seh:EXC_DefaultHandling Unhandled exception code c000013a flags 0 addr 0x402fec98 ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

3 3

winelib/mfc queries
by KK singh 08 Apr '03

08 Apr '03

I am using 20030318 build of wine ... 1. WINE_UNICODE_TEXT is no longer defined anywhere in any of the header files ? What should i do now with OLESTR ? 2. Should i define _AFXDLL while compiling mfc ? Regards kks __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com

2 1

Who is the expert on named_pipe.c
by Bill Medland 08 Apr '03

08 Apr '03

I've found a problem with the named_pipe.c in the server. Is there anyone out there who purports to be an expert or is it up to me to fix it? (Basically the server is creating a named pipe, reading from it, writing back to it, flushing and closing, all before the client has read the reply; the wineserver crashes as the client tries to read because it's copy no longer has an fd) -- Bill Medland ACCPAC International, Inc. medbi01(a)accpac.com Corporate: www.accpac.com Hosted Services: www.accpaconline.com

2 2

why the wine not use the dll binary?
by Yu Neil 08 Apr '03

08 Apr '03

hello: why the wine not use the dll binary? but to rewrite the windows interface? Neil Yu _________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn

2 1

Re: PATCH: client side SuspendThread() handling when using valgrind
by Dimitrie O. Paun 08 Apr '03

08 Apr '03

On April 7, 2003 10:41 am, Adam Gundy wrote: > the attached patch is a reworking of the previous valgrind patch's > SuspendThread() changes so that the client only suspends threads locally > when running under valgrind. What about: +#ifdef HAVE_VALGRIND_MEMCHECK_H +#include <valgrind/memcheck.h> +#else +#define RUNNING_ON_VALGRIND 0 +#endif so we can eliminate the ugly ifdefs? -- Dimi.

2 1

Re: Re: --with-nptl and glibc-2.3.2
by fenix＠club-internet.fr 08 Apr '03

08 Apr '03

Hi, can you try with preloading? LD_PRELOAD="/usr/local/wine/lib/kernel32.dll.so /usr/local/wine/lib/ntdll.dll.so" wine regedit Regards, Raphael ----Message d'origine---- >De: James Pellow <james(a)alentdesignsolutions.com> >A: wine-devel(a)winehq.com >Sujet: Re: --with-nptl and glibc-2.3.2 >Date: Mon, 7 Apr 2003 17:37:02 +0000 > >On Sunday 06 April 2003 05:48 am, Gregory M. Turner wrote: >> On Saturday 05 April 2003 02:52 pm, James Pellow wrote: >> > Thanks Gregory and Raphael for your answers. So far, I have been using >> > "~x86" for two months now, with only minor glitchs. This is the biggest >> > hangup I have found. >> >> yes, it tends to work just fine, although from time to time it goes south >> :) >> >> It all depends on what the developers are working on, I guess. Typically >> all goes well until glibc upgrades start looming, and then gcc breaks and >> it's time to re-read the gentoo install guide ;) If you are a developer, >> it's a meaningful excercise; it's truly a bleeding edge system and any >> dependencies likely to affect your users in the coming months may hit you >> first. It's also fun to see the very latest efforts from the OSS world and >> beyond... but personally, for desktop use, it's a bit too demanding, I need >> to save my mental energy ;) My only advice would be: habitually use the -b >> flag to emerge so that when and if you kill your system you can revive it >> by untarring old emerges. >> >> > I would be happy to look into the problem myself and >> > provide a fix, but it seems work and taxes are taking up most of my time >> > right now :( so I am curious how far out a fix might be. Is this being >> > worked on? Thank you all for an incredible tool! >> > - James >> >> Tried Piotr Pawlow's recently posted fix? >> >> > Try this: >> > >> > $ sed -e 's/-z,defs/-z=defs/g' <configure.ac >tmp && aclocal && autoconf >> > tmp >configure >> > >> > and then as usual: >> > >> > $ ./configure && make depend && make > >Ok, I have done the first round of testing on my new wine with the above fix. >The above fix does allow wine to compile, but there do seem to be some >runtime problems that remain. > >I have a stand alone installation of wine. First I tried to install an app >and ran into the following message: > >err:module:BUILTIN32_dlopen failed to load .so lib for builtin advapi32.dll: >/usr/local/wine/lib/wine/advapi32.dll.so: undefined symbol: GetComputerNameW >err:module:import_dll Loading module (file) ADVAPI32.dll (which is needed by >D:\setup.exe) failed (error -1073741702). > >I did the following in lib/wine: > >for FILE in `ls *.so`; do objdump -t $FILE | grep GetComputerNameW && ls -l >$FILE; done > >and see that all files that that define this symbol are links to >kernel32.dll.so. > >The problem seems obvious when I do: > >ldd advapi32.dll.so > > libwine.so.1 => /usr/local/wine/lib/libwine.so.1 (0x40042000) > libwine_unicode.so.1 => /usr/local/wine/lib/libwine_unicode.so.1 >(0x4005a000) > libm.so.6 => /lib/libm.so.6 (0x4013b000) > libc.so.6 => /lib/libc.so.6 (0x4015d000) > libdl.so.2 => /lib/libdl.so.2 (0x40285000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > >It appears that advapi32.dll.so does not claim to need kernel32.dll.so, but it >does! Any ideas on what went wrong? Regedit did not run for a similar >reason. Thanks for your help. > >James Pellow > >

2 1

RH9 & cvsup
by Dimitrie O. Paun 08 Apr '03

08 Apr '03

Hi folks, I've just upgraded to RedHat 9, and I run into my first problem. cvsup segfaults: [dimi@dimi wine.src]$ cvsup ~/cvsup.sup *** *** runtime error: *** Segmentation violation - possible attempt to dereference NIL0 *** use option @M3stackdump to get a stack trace Aborted Now, this is a big problem for me, any other cvsup user out there with this problem (and hopefully a workaround?) -- Dimi.

1 0

Re: cleaning the source tree when compiling outside the source tree
by Alexandre Julliard 08 Apr '03

08 Apr '03

Eric Pouech <pouech-eric(a)wanadoo.fr> writes: > ChangeLog: when compiling out of source tree, insure that make clean actually cleans also inside the source tree I don't think we should do that. IMO we must not modify the source tree in any way when building in a separate dir. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winedos / Small bug fixes
by Jukka Heinonen 07 Apr '03

07 Apr '03

Enrico Horn wrote: > With this patch I get an unhandled exception > while trying to run callahans crosstime saloon, > an dos adventure that makes use of vesa. > without the patch the program runs, just with a black picture :-) This problem is likely caused by one of the following reasons: - The program calls int10 from protected mode and expects to get selector based far pointers instead of segment based ones. - The program previously failed to initialize VESA and now, when it initializes VESA correctly, it starts to crash in previously unused code. Separating these two cases would make fixing this crash easier. Do you have some traces that show int10 usage before/after patch or can the game be downloaded for free from some site? -- Jukka Heinonen <http://www.iki.fi/jhei/>

2 1

--with-nptl and glibc-2.3.2
by James Pellow 07 Apr '03

07 Apr '03

Hi all, After reading the comments on the list reguarding glibc-2.3.2, it appears all I need to do is ./configure --with-nptl. Today, gave this a try and am having the following error messages repeated many times when trying to link d3d8: shader.o(.text+0x19f8): In function `IDirect3DVertexShaderImpl_ParseProgram': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1064): In function `IDirect3DDeviceImpl_CreateStateBlock': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapAlloc' stateblock.o(.text+0x1402): In function `IDirect3DDeviceImpl_DeleteStateBlock': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined reference to `HeapFree' stateblock.o(.text+0x14ed): In function `IDirect3DDeviceImpl_BeginStateBlock': /home/pellja/cvs/wine/dlls/d3d8/../../include/winbase.h:1932: undefined --snip-- I have had this problem for the last couple of releases... My setup is an up to date gentoo, todays wine-cvs, glibc-2.3.2 and gcc-3.2.2. on an AMD thunderbird. Any ideas? On the gentoo formums, they all say downgrade to glibc-2.3.1, and hear I read use --with-nptl, but it doesn't work... I would rather not downgrade my glibc... Thanks for your help. Sorry if this is becomming a FAQ, but it still didn't seem clear to me. James

4 7

[announce] QEMU x86 emulator version 0.1
by Fabrice Bellard 07 Apr '03

07 Apr '03

Hi, The first release of the QEMU x86 emulator is available at http://bellard.org/qemu/. QEMU achieves a fast user space Linux x86 emulation on x86 and PowerPC Linux hosts by using dynamic translation. Its main goal is to be able to run the Wine project on non-x86 architectures. Fabrice.

3 5

Re: valgrind for WINE
by Adam Gundy 07 Apr '03

07 Apr '03

At 10:15 03/04/03 -0800, Alexandre Julliard wrote: >Adam Gundy <arg(a)cyberscience.com> writes: > >> anything that uses SuspendThread is inherently racy and unpleasant. Even the Microsoft >> documentation says "don't use this!". Of course, they ignore themselves and do it (twice) >> during MFC thread creation, but... >> >> We aren't currently adding _any_ race condition that isn't already there - the wineserver >> sends a signal to the client process in the current code - who knows when that will be delivered? >> there could be a big gap between the server sending the signal, and the signal being processed. > >There may be a delay, but the thread is still effectively suspended >since it's not running any user-mode code. The signal will get >delivered on the next switch to that thread, so we still get the >correct behavior. If the signal is sent in the client the suspended >thread can still run arbitrary amounts of code while the server >believes it is already suspended. you can't reason like this - it all falls apart with SMP. Both threads can happily be running at the same time - we are using clone() after all. I can currently produce this race (without my patch applied) by adding a "Sleep( 1000 )" to the USR1 signal handler in ntdll/signal_i386.c. The wineserver is convinced that the thread is suspended, but it isn't (sleeping is a bad example - assume that a context switch occurred, or heavy processing happened before the signal was delivered). this 'race' doesn't have ANY effect, because suspending a thread is not a precise operation - it doesn't matter whether 1 or 1000 instructions are executed by the thread before it stops. Windows threads don't give guarantees about thread suspension (unlike pthreads). to summarize: a) there is already a race condition in the current code - it _probably_ only triggers on SMP or heavily loaded UP. b) my patch won't make things any worse c) the race doesn't matter because Windows threads don't guarantee what happens when a thread is suspended (read Microsoft's docs - they practically say "don't use this call" for this very reason). Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.

2 4

Re : Improve error message for RAS not being supported
by Sylvain Petreolle 07 Apr '03

07 Apr '03

In the patch http://cvs.winehq.com/patch.py?id=7793 you set only : - FIXME("RAS support is not implemented ! Configure program to use LAN connection/winsock instead !\n"); + FIXME("RAS support is not implemented! Configure program to use LAN connection/winsock instead!\n"); <snip> - FIXME("RAS support is not implemented ! Configure program to use LAN connection/winsock instead !\n"); + FIXME("RAS support is not implemented! Configure program to use LAN connection/winsock instead!\n"); Could you say where the improvement is ? ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

Re: [REDUNDANT/ARCHIVAL] Ntdll atom tests.
by Dmitry Timoshkov 07 Apr '03

07 Apr '03

"GyЖrgy 'Nog' Jeney" <nog(a)sdf.lonestar.org> wrote: > Here are some test for the ntdll atom api, mabe the reactos folks shal > find them usefull This is just a confirmation that now your test runs without errors. atom: 163932 tests executed, 0 marked as todo, 0 failures. -- Dmitry.

1 0

dlls/msvcrtd/msvcrtd.spec breaks portability
by Gerald Pfeifer 07 Apr '03

07 Apr '03

The following unfortunately breaks FreeBSD 4.8 (and probably other systems as well): /home/wine/wine/dlls/msvcrtd/msvcrtd.spec revision 1.1 date: 2003/04/04 19:37:57; author: julliard; state: Exp; Adam Gundy <arg(a)cyberscience.com> Added an implementation of the MSVCRTD.DLL debugging C runtime DLL. Here is the actual failure mode: /usr/bin/gcc -shared -Wl,-Bsymbolic,-z,defs msvcrtd.spec.o debug.o msvcrtd.dll.dbg.o -o msvcrtd.dll.so -L../../dlls -L../../libs/wine -lwine -L../../libs/port -lwine_port -lm -lc msvcrtd.spec.o: In function `__wine_spec_exports_funcs': msvcrtd.spec.o(.data+0x3a8): undefined reference to `ecvt' msvcrtd.spec.o(.data+0x3f8): undefined reference to `fcvt' msvcrtd.spec.o(.data+0x474): undefined reference to `gcvt' msvcrtd.spec.o: In function `__wine_spec_forwards': msvcrtd.spec.o(.data+0x52cc): undefined reference to `ecvt' msvcrtd.spec.o(.data+0x540c): undefined reference to `fcvt' msvcrtd.spec.o(.data+0x55fc): undefined reference to `gcvt' msvcrtd.spec.o(.data+0x52c5): undefined reference to `ecvt' msvcrtd.spec.o(.data+0x5405): undefined reference to `fcvt' msvcrtd.spec.o(.data+0x55f5): undefined reference to `gcvt' gmake[2]: *** [msvcrtd.dll.so] Error 1 gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/msvcrtd' gmake[1]: *** [msvcrtd] Error 2 According to /usr/include/stdlib.h on my GNU/Linux boxes and the man pages, I'm quite sure that these three functions are not ISO C: #if defined __USE_SVID || defined __USE_XOPEN_EXTENDED NOTES These functions are obsolete. Instead, sprintf() is recommended. Linux libc4 and libc5 specified the type of ndigits as size_t. Not all locales use a point as the radix character (`decimal point'). CONFORMING TO SysVR2, XPG2 Can we simply remove them? Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

2 2

Re: RtlAtom tests further improved
by Dmitry Timoshkov 07 Apr '03

07 Apr '03

"GyЖrgy 'Nog' Jeney" <nog(a)sdf.lonestar.org> wrote: > Here's the latest version of my RtlAtom test, these should now succeed on > an nt system. Thanks to Dmitry for running the initial test. There are failures yet. atom.c:186: Test failed: We found wrong atom atom.c:232: Test failed: Able to find previously deleted atom in table, retval: c0000034 atom.c:248: Test failed: Able to find deleted atom in table atom.c:381: Test failed: Expected pincount 1 but got 3 atom.c:382: Test failed: Expected refcount 3 but got 0 atom.c:395: Test failed: Expected pincount 3 but got 3 atom: 163923 tests executed, 0 marked as todo, 6 failures. You can send further versions to me directly until it's finished to avoid spamming the list. Looking at the ReactOS implementations of RtlAtom* APIs, I've found that they conform to the results I get under win2k. Did you try to ask a permission to use their implementation in Wine? Steven? -- Dmitry.

4 7

SQL and wine.
by Carlo Pelini 07 Apr '03

07 Apr '03

Hy. I am a italian student of computer science. I asking to make wine to open a application which open a connection ODBC with database SQL. For the moment i have succeed to open a connection with a VisualFoxPro Table, even if it not run very well. My problem however is that to succeed to create a Data Source Name SQL server, starting from the driver SQL, which appear on the ODBC panel of wine. Anyone Has experienced to run SQL with wine? Anyone could it help me? Bye. Pelini Carlo.

1 0

EM_REPLACESTR not respecting EM_SETLIMITTEXT
by Brad Campbell 07 Apr '03

07 Apr '03

G'day all, Found the cause of my problems with Delphi programs and MaskEdit fields. In an edit component which has a length set with EM_LIMITTEXT, any text added with EM_REPLACESTR was not respecting the text length value. This patch fixes it for me, can I have some feeback from someone in the know please before I submit it to win-patches.. Watch the wrapping.. Mozilla is set to desecrate patches :p) Index: controls/edit.c =================================================================== RCS file: /home/wine/wine/controls/edit.c,v retrieving revision 1.110 diff -u -r1.110 edit.c --- controls/edit.c 27 Feb 2003 21:09:46 -0000 1.110 +++ controls/edit.c 6 Apr 2003 16:04:41 -0000 @@ -2945,6 +2945,10 @@ } else EDIT_EM_EmptyUndoBuffer(es); + /* respect buffer_limit */ + if ((s+strl) > es->buffer_limit) + strl = (es->buffer_limit-s); + /* now insert */ tl = strlenW(es->text); TRACE("inserting stuff (tl %d, strl %d, selstart %d ('%s'), text '%s')\n", tl, strl, s, debugstr_w(es->text + s), debugstr_w(es->text)); -- Brad.... /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \

2 1

Using WIN32 DLL from Unix library
by Vittorio Ballestra 07 Apr '03

07 Apr '03

Hello, I'd like create a unix shared library that will make some call to a WIN32 DLL using wine. Is this possible, and if it is so, where may I find some documentation pointers on how to achieve this ? Tnx, Vittorio

2 2

Re: [msimg32] Implements GradientFill
by Roderick Colenbrander 06 Apr '03

06 Apr '03

I think this patch shouldn't be applied. Today I was playing with some winxp apps that spit out a lot of unimplemented stuff. I found the following undocumented function: GdiGradientFill. After some searching on google I found some info about a function that looks a lot like it (brother or sister). This is the prototype as it can be used from good old VB: Declare Function GdiGradientFillRect Lib "gdi32" Alias "GdiGradientFill" (ByVal hdc As Long, pVertex As TRIVERTEX, ByVal dwNumVertex As Long, pMesh As GRADIENT_RECT, ByVal dwNumMesh As Long, ByVal dwMode As Long) As Long compare with: BOOL WINAPI GradientFill( HDC hdc, TRIVERTEX *vert_array, ULONG nvert, void * grad_array, ULONG ngrad, ULONG mode ) Mike Hearn and I assume that GdiGradientFill and GradientFill are the same. The one redirects to the other. Creating circular dependecies isn't a good problem I think. So I think this code should be moved to gdi32 and that msimg32 forwards it. Roderick Colenbrander On Saturday 05 April 2003 23:27, Maxime Bellengé wrote: > This patch implements the GRADIENT_FILL_RECT_{H|V} cases > of GradientFill. > > This makes the eMule menu looks much better. > > a+ > > Max

2 1

Re: winedos / Small bug fixes
by Enrico Horn 06 Apr '03

06 Apr '03

Hi, On Sunday 06 April 2003 15:40, Jukka Heinonen wrote: > This patch fixes a few bugs in winedos. > > > > > Changelog: > Return correct segment for VESA information. > Check oem number/version flag first and after that overwrite > condition code. > With this patch I get an unhandled exception while trying to run callahans crosstime saloon, an dos adventure that makes use of vesa. without the patch the program runs, just with a black picture :-) Here is a backtrace: =>0 0x504f4344 (_end+0xc29dc08) (ebp=448c2d14) 1 0x41be436c (VGA_Poll_Graphics+0x5c [vga.c:854] in winedos.dll.so) (ebp=448c2d50) 2 0x41be4717 (VGA_Poll+0x37(arg=0x0, low=0x4e6700d6, high=0x1c2fc80) [vga.c:940] in winedos.dll.so) (ebp=448c2d64) 3 0x400de5ea (.L130+0x4a [sync.c] in libntdll.dll.so) (ebp=448c2e14) 4 0x400de742 (NTDLL.DLL.NtWaitForMultipleObjects+0x122 in libntdll.dll.so) (ebp=448c2eb8) 5 0x400c163f (WaitForMultipleObjectsEx+0x5f(count=0x0, handles=0x0, wait_all=0x0, timeout=0xffffffff, alertable=0x1) [synchro.c:94] in libntdll.dll.so) (ebp=448c2ee8) 6 0x41be2cec (VGA_TimerThread+0x4c(dummy=0x0) [vga.c:279] in winedos.dll.so) (ebp=448c2f08) 7 0x400c2b3d (THREAD_Start+0x7d [thread.c:1619] in libntdll.dll.so) (ebp=448c2f28) 8 0x400c19c9 (SYSDEPS_StartThread+0xa9(teb=0x448d3000) [sysdeps.c:171] in libntdll.dll.so) (ebp=448c2ff4) 9 0x4031e8d4 (clone+0x44 in libc.so.6) (ebp=00000000) Ciao Enrico farmboy1(a)web.de

1 0

Re: the rest of dmusic stubs
by Lionel Ulmer 06 Apr '03

06 Apr '03

> BTW: were there any attempts to write a script which would create ICOM > Interfaces automatically? ;=) Well, 99 % of the stubs / architecture of the 'new' D3D code was done automagically using a Python script which took the header files and generated the ICOM macro stuff, the interfaces and the VTables (it even did the factorisation of code and generated the stubs for 'easy' stubs). Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: Launching files with params
by Vilppa Salt 06 Apr '03

06 Apr '03

> From that log, it looks like wine didn't find start.exe. > What version of Wine are you using? You are right. start.exe is not found. I thought that the program that start.exe is trying to run is not found. :) What should I do to get the wine to find start.exe? I noticed that Wine looks for some registry entries for start location. Maybe I'm missing those reg entries? Wine is compiled from CVS. It's two days old. > Where is your start.exe located? Here? /usr/local/lib/wine/start.exe.so Vilppa --- Vilppa- Sunpoint.net ilmoittaa: Sunpoint.net tarjoaa kaikille rekisteröityneille käyttäjilleen kuukausimaksuttoman Internet -yhteyden (pvm). http://www.sunpoint.net/SunAds/click.htm?mode=footer&id=71&jump=http%3A%2F%…

2 1

WineHQ page
by Michal Janusz Miroslaw 06 Apr '03

06 Apr '03

The new WineHW site looks great. But the dashes appearing in elinks make it soooo ugly. When you remove alt="-" parameter from <img> tag they ... disappear! :) -- Michal Miroslaw PS. Why don't you use ' ' instead of '<img src=blank.gif ...>' ?

3 2

re: Transient registry entries?
by Dan Kegel 06 Apr '03

06 Apr '03

> My app reads the registry to figure out network information, in > particular it queries the [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows > NT\CurrentVersion\NetworkCards\] key to discover network cards, then > [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services] to figure out the > IP address of each one (this program can bind to multiple adaptors). > ... > a) In initial setup, ie when you install Wine > b) At Wine startup > c) On demand, ie by writing special cases into the registry access code. Clearly c) because that will work properly even when doing hotplugging of pcmcia cards and doing interactive dialup to an isp. Might want to cache it for 10 seconds or something, and you might need to worry about what happens when programs are reading the reg entries *while* an interface is changing. (heh.) BTW there is a system call getifaddrs on many flavors of Unix that does this kind of query, and there's a library implementation of it for linux. See http://www.kegel.com/dkftpbench/dkftpbench-0.45/getifaddrs.c http://www.kegel.com/dkftpbench/dkftpbench-0.45/getifaddrs.h The registry code should probably just call this function. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

5 7

Re: Patch - Fix building rpcrt4 on mingw
by Steven Edwards 06 Apr '03

06 Apr '03

Regression tests still seem to work after this but I have no idea about any of the inner workings of rpcrt4. Thanks Steven Steven Edwards wrote: > I have no idea if this will work on windows at all but it can at least > be built now. This is going to throw 3 warnings now when building on > mingw but I dont really understand anything about this code. > > Changelog: Porting fix >

1 0

Re: Launching files with params
by Dan Kegel 06 Apr '03

06 Apr '03

From that log, it looks like wine didn't find start.exe. What version of Wine are you using? Where is your start.exe located? - Dan (author of our lovely little start.exe) -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

Wine and Glibc 2.3.2
by Roderick Colenbrander 05 Apr '03

05 Apr '03

Hi, I know there are/were glibc 2.3x problems and wine. My system is running Debian Unstable. I'm trying to help the mono guys a bit with Windows.Forms. Because of some bugs in the glibc 2.3.1-16 version debian is using, the winelib based app needed by mono didn't work. (dlopen related problems) I upgraded my glibc to 2.3.2-1 using the packages that will move into Debian soon. I recompiled my wine (latest from cvs) and wine itself runs. (still the /tmp problems ..) Compared to other distributions which use 2.3.2 debian isn't using nptl. Monostub (the winelib app from mono) and winedbg are not working fine. Is it correct that Wine still isn't compatible with glibc2.3.2 version that are not using nptl? For example I'm getting errors like this when trying to use monostub but winedbg isn't being launched: wine: Unhandled exception, starting debugger... err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x4029486b Thanks, Roderick Colenbrander

1 0

Re: Launching files with params
by Vilppa Salt 05 Apr '03

05 Apr '03

> You forgot to attach the file - could you open a bug in bugzilla about > this and attach it there? I've seen it too and it's extremely > annoying, > good to see somebody has been debugging this. > > thanks -mike The log is now attached, I hope. I'll file a bug later. --- Vilppa - Sunpoint.net ilmoittaa: Sunpoint.net tarjoaa kaikille rekisteröityneille käyttäjilleen kuukausimaksuttoman Internet -yhteyden (pvm). http://www.sunpoint.net/SunAds/click.htm?mode=footer&id=71&jump=http%3A%2F%…

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel