August 2003 - Wine-Devel - list.winehq.org

Wine history draft
by Brian Vincent (C) Jan. 26, 2004

Jan. 26, 2004

I put together the following: http://users.theshell.com/~vinn/wine-history.html There's two major additions I'd like to see and I don't think I'm capable of doing them: 1) Wine history from 1994 - 1999 with a specific emphasis on changes to the architecture, design decisions that got discarded, developers who've come and gone. 2) Specific quotes from over the years. I sort of put some examples of that in the document above. Humorous quotes would be especially nice. If no one has any suggestions then I'll likely just remove the existing ones and add the information to the relevant paragraphs. I'm also thinking of adding a paragraph on the tools and programs developed for Wine. Comments / suggestions / criticisms? --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com

4 3

[ANN] Conformance testing campaign
by Ferenc Wagner Sept. 30, 2003

Sept. 30, 2003

Greetings! Hereby I ask people who have access to real Windows machines to help me gather information about the behaviour of cross- compiled conformance tests on the different platforms. Please go to http://afavant.elte.hu/~wferi/wine for details. If you can build the tests in the Wine tree by MSVC, then packaging the compiled binaries would also mean a valuable addition. You will also find a packaging script on the page. Thanks for your time, Feri.

9 39

Really slow named pipes
by Duane Clark Sept. 13, 2003

Sept. 13, 2003

This is a bit old, from May, but anyhow... The patch to implement anonymous pipes on top of named pipes: http://www.winehq.com/hypermail/wine-cvs/2003/05/0305.html along with a corresponding bug fix: http://www.winehq.com/hypermail/wine-cvs/2003/06/0123.html causes Xilinx ISE to run really, really slow. It has a window to which messages are sent via a pipe, and what I see now is that one line comes out every 2/3 of a second or so, as regular as a clock at least by eye. I can revert those two patches, and it goes back to spitting out the messages very fast. Since there are a lot of messages being sent, the current version slows the app down to a crawl. It does not look like the patch itself is the problem; I am guessing that it is the underlying named pipe implementation that is the problem, which was exposed by the patch. Also, reverting to the full CVS 5/20, just after the pipe patches, has the same problem. So it appears that whatever is wrong with named pipes (if that really is the problem) was already there on 5/20, rather than it being something introduced since then. Any hints on what I could look for would be welcome.

4 10

FIXME:pthread_cond_init
by Gerald Pfeifer Sept. 12, 2003

Sept. 12, 2003

When building Wine on FreeBSD with libc_r (r for reentrant) instead of libc, I now trigger the following FIXME in scheduler/pthread.c: /***** CONDITIONS *****/ /* not implemented right now */ int __pthread_cond_init(pthread_cond_t *cond, const pthread_condattr_t *cond_attr) { P_OUTPUT("FIXME:pthread_cond_init\n"); return 0; } What's the proper way to address this? (I'm afraid, it's beyond what I'll be able to implement, though.) Gerald

1 1

FAQ update
by Tom Sept. 10, 2003

Sept. 10, 2003

Hi, Thanks for the update.. I got occupied with something and it took me a little longer than I thought. But I have the sync of lostwages to docs faq in my tree. I will now rm -rf it Regards, Tom

6 28

Relocate error
by Fabian Cenedese Sept. 10, 2003

Sept. 10, 2003

Hi I worked with wine about six months ago. Except some minor errors my app worked quite good in wine. Then I didn't have time anymore. Now I tried again with the newest wine from cvs. But now I can't even start my app anymore. Wine gives me this error: err:virtual:map_image FATAL: Need to relocate module from addr 40000000, but there are no relocation records wine: could not load 'C:\IMD\Bin\Imd.exe' as Win32 binary I looked in the archives and the only messages concerning this error were at least two years old stating that this error has been fixed long ago. I didn't change this link address in my app (VC6), it has been there even before I started with wine at all. But when I change this address to say 0x48000000 then it works. So is there something else on this address? I know six months is a long time and a lot happened this year. But does anybody know if this is a real error? What could have introduced this behaviour as it worked a few months ago? Thanks Fabi

3 5

Re: [winegcc06] Delayed import
by Dimitrie O. Paun Sept. 9, 2003

Sept. 9, 2003

On August 13, 2003 10:08 pm, Richard Cohen wrote: > --- tools.5/winegcc.c 2003-08-14 00:55:07.000000000 +0100 > +++ tools/winegcc.c 2003-08-14 01:21:41.000000000 +0100 > @@ -193,7 +193,8 @@ > } > argv[j] = 0; > break; > - case 'l': > + case 'l': /* import/static library */ > + case 'd': /* delayed import library */ This is not cool -- winegcc is supposed to be command line compatible with mingw-gcc, and -d conflicts with gcc's -d: -dletters Says to make debugging dumps during compilation at times specified by letters. This is used for debugging the compiler. The file names for most of the dumps are made by appending a pass number and a word to the dumpname. dumpname is generated from the name of the output file, if explicitly specified and it is not an executable, otherwise it is the basename of the source file. In both cases any suffix is removed (e.g. foo.00.rtl or foo.01.sibling). Here are the possible letters for use in letters, and their meanings: ..... Having the option in winewrap is OK, there we control the options. If this feature is useful in Windows, gcc must/will support it, right? If they don't already, we better get in touch with them so we end up with the same option name/syntax. -- Dimi.

2 6

Conformance tests
by Ferenc Wagner Sept. 2, 2003

Sept. 2, 2003

Hello, recent discussion on the list ignited my interest again. Francois has a very nice page <http://fgouget.free.fr/wine/tests-en.shtml>, let's try to make better use of it! 1. The precompiled binaries offered here would mean a great help, were they updated regularly. 2. Maybe better, a framework could be developed which would run all the tests, pack the results up and send it back to Francois for easy integration into his page. 3. The table on the page is too big for convenient use. I do not know about much structure to see; maybe a table is not even needed. Just version, date of test, if it is up to date with the binaries on the page, and a list of failing tests as links to the error messages would be enough. If it is not, we can still embed it into the giant API database at http://24.229.94.2 (why is it not linked from WineHQ?) and have a general SQL interface! :) Hmm, some diffing capabilities might be useful indeed... 4. We could recruit people with access to the different platforms and send them mails asking for a rerun whenever the new tests are compiled. Or advertise it on the devel list only... What do you think? I am even willing to do some of the above, except for the build, as I have no constant access to Windows machines. Feri.

7 24

Source release and download directory
by Jakob Eriksson Sept. 1, 2003

Sept. 1, 2003

Source release and download directory: http://vmlinux.org/jakov/Wine/

3 7

msi.dll broken with yacc in current cvs
by Stefan Leichter Sept. 1, 2003

Sept. 1, 2003

Hello, i can not compile msi.dll on one of my systems. make aborts with: yacc -d -t ../../../wine/dlls/msi/sql.y yacc: e - line 69 of "../../../wine/dlls/msi/sql.y", syntax error %pure-parser ^ make[2]: *** [y.tab.c] Error 1 make[2]: Leaving directory `/usr/src/wine-build/dlls/msi' make[1]: *** [msi] Error 2 make[1]: Leaving directory `/usr/src/wine-build/dlls' make: *** [dlls] Error 2 The second system compiles fine. It uses bison instead of yacc. Both systems are SuSE 7.3 > rpm -qa | grep -e bison -e yacc yacc-91.7.30-379 bison-1.28-127 I know i can install bison and it will compile, but i think this needs to be fixed. Bye Stefan

3 3