June 2004 - Wine-Devel - list.winehq.org

Re: Wine bug with delphi Menus

by Robert van Herk

Dan Kegel wrote: > Please do put the source and executable of your demo > app online at some web page, and post the URL on wine-devel. Okay, please feel free to grab it from http://www.students.cs.uu.nl/people/rherk/DelphiMenuTest.tar.gz . Greetings, Robert P.S. Hope I got the bonus :-P

June 1, 2004

Re: broken mingw build

by Mike Hearn

On Tue, 2004-06-01 at 09:50 +0200, Hans Leidekker wrote: > I suspect .previous is ELF specific? Yes, .previous is ELF specific. It reverts the assembler to generating output in whatever the previous section was, so if you write: .text blah blah blah .previous then you are now back in the section you were before .text - PE doesn't really have the same idea of sections as ELF does. thanks -mike

June 1, 2004

Re: [OLEAUT32] Resend: Typelibs, Better handling of References

by Mike Hearn

On Tue, 2004-06-01 at 09:33 +0200, Raphael wrote: > Now we go further on many InstallShields (i'm using Prince Of Persia and > SplinterCell Demo) but InstallShield seems to freeze after creating the > "desktop/background" window (i only see Window messaging traces). > Any expert to help me ? > helpppp, i want a lot to use SplinterCell Demo :( Are you sure it's frozen, or is it actually that the big blue window was created as override-redirect so is placed always-on-top by your window manager? What happens if you use desktop mode? thanks -mike

June 1, 2004

Re: broken mingw build

by Hans Leidekker

On Sunday 30 May 2004 02:59, Kevin Koltzau wrote: > This patch > http://cvs.winehq.org/patch.py?id=12495 > seems to have broken the mingw build, currently getting Are you saying you could build Wine with MinGW before this patch? > i386-mingw32msvc-gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o interlocked.o interlocked.c > {standard input}: Assembler messages: > {standard input}:124: Error: unknown pseudo-op: `.previous' > {standard input}:135: Error: unknown pseudo-op: `.previous' > {standard input}:145: Error: unknown pseudo-op: `.previous' > {standard input}:155: Error: unknown pseudo-op: `.previous' > {standard input}:165: Error: unknown pseudo-op: `.previous' > make[2]: *** [interlocked.o] Error 1 I suspect .previous is ELF specific? Don't know if it's worth fixing this since AFAICS this code is about portability toward Unix platforms and now we're trying to build PE executables from it with MinGW. Cygwin might be an interesting target in this respect though. -Hans Changelog: MinGW portability fix.

June 1, 2004

Re: Use TRACE rather than FIXME for check_resource_write

by Dmitry Timoshkov

[forgot to cc wine-devel] "Mike Hearn" <mh(a)codeweavers.com> wrote: > No need for this to be a fixme, we can't fix broken apps anyway and it > just confuses people. > > Mike Hearn <mh(a)codeweavers.com> > Use TRACE rather than FIXME for check_resource_write I have found and fixed at least one bug in Wine itself thanks to this fixme message. -- Dmitry.

June 1, 2004

Re: General serial communications issues

by James Courtier-Dutton

I have looked into the wine code now, and async reads from the COM port are just broken. The app calls read, wine sets off the FILE_AsyncReadService, and then returns to the app. FILE_AsyncReadService is called each time a character is received from the COM port, and it buffers up the received characters in the 1024 bytes buffer. The next time the app calls read, wine sets off a new (now making it two) FILE_AsyncReadService, but clears the buffer first, so all the characters received from the previous FILE_AsyncReadService get lost. This is where the input characters are getting lost. James

June 1, 2004