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

Re: compiling wineserver under cygwin - thread context

by David Fraser

Dimitrie O. Paun wrote: >On November 28, 2002 09:51 am, David Fraser wrote: > > >>So part of the question is, in order to get Wine to function properly on >>Cygwin, what is the right >>threading approach to take? Am I right in thinking that the current code >>wouldn't work on Cygwin? >> >> > >I say, let's get the compiling and linking working, and then worry about >actually running it... :) > > > >>As far as I can see the only places get_thread_context and >>set_thread_context are used is in >>scheduler/thread.c, to implement WINAPI GetThreadContext and >>SetThreadContext >> >> > >So actually a first approximation for [sg]et_thread_context for >Cygwin would be one that does nothing. Then we can try submitting >patches to Cygwin (Approach 2), so that other apps can make use >of ptrace, if necessary. > > > OK, done that. So now wineserver.exe actually links :-) And it runs too! However can't yet see whether its going to do anything as in order to actually run programs it looks like we need tolink miscemu/main.c Problem here being that it wants to link with ntdll, which doesn't build yet. That still needs a lot more work... In the mean time a very simple patch that does nothing for context_i386.c is below in case anyone else wants to try... David Index: server/context_i386.c =================================================================== RCS file: /home/wine/wine/server/context_i386.c,v retrieving revision 1.24 diff -u -r1.24 context_i386.c --- server/context_i386.c 8 Nov 2002 18:55:31 -0000 1.24 +++ server/context_i386.c 28 Nov 2002 15:48:01 -0000 @@ -76,7 +76,24 @@ #define PTRACE_SETDBREGS PT_SETDBREGS #endif -#ifdef linux +#if defined(__CYGWIN__) + +/* retrieve a thread context */ +static void get_thread_context( struct thread *thread, unsigned int flags, CONTEXT *context ) +{ + /* FIXME: implement this */ + file_set_error(); +} + + +/* set a thread context */ +static void set_thread_context( struct thread *thread, unsigned int flags, const CONTEXT *context ) +{ + /* FIXME: implement this */ + file_set_error(); +} + +#elif defined(linux) #ifdef HAVE_SYS_USER_H # include <sys/user.h> #endif

Nov. 28, 2002

Re: compiling wineserver under cygwin - thread context

by Dimitrie O. Paun

On November 28, 2002 09:51 am, David Fraser wrote: > So part of the question is, in order to get Wine to function properly on > Cygwin, what is the right > threading approach to take? Am I right in thinking that the current code > wouldn't work on Cygwin? I say, let's get the compiling and linking working, and then worry about actually running it... :) > As far as I can see the only places get_thread_context and > set_thread_context are used is in > scheduler/thread.c, to implement WINAPI GetThreadContext and > SetThreadContext So actually a first approximation for [sg]et_thread_context for Cygwin would be one that does nothing. Then we can try submitting patches to Cygwin (Approach 2), so that other apps can make use of ptrace, if necessary. -- Dimi.

Nov. 28, 2002

Re: compiling wineserver under cygwin - thread context

by David Fraser

David Fraser wrote: > The significant compilation problem is in server/context_i386.c: You > must implement get/set_thread_context for your platform. > Basically there's some code that does the threading stuff which is > platform-specific. There are Linux and BSD and Sun variants, none of > which work under cygwin ... Basically sys/ptrace.h is what's missing. > This lets the process interrupt a child process and get/set its > registers. Does anyone have any idea what the best way to write a > replacement for cygwin would be? Maybe I need to ask the cygwin list. After some more investigating ... Dimi added a request for ptrace support in cygwin in November 2000: http://cygwin.com//cgi-bin/cygwin-todo.cgi?20001120.094813 But I can't see anything that's been done about it. So I thought I would clarify here exactly what should be done before trying to do it... The platform-specific bits define the functions get_thread_context and set_thread_context which each use ptrace (in the existing platforms) to get / set registers for that thread. The requests given to ptrace are: PTRACE_PEEKUSER / PTRACE_POKEUSER (for getting / setting debugging registers) PTRACE_GETREGS / PTRACE_SETREGS (for getting / setting general registers) PTRACE_GETFPREGS (for getting / setting floating point registers) so it's fairly simple... As far as I can see the only places get_thread_context and set_thread_context are used is in scheduler/thread.c, to implement WINAPI GetThreadContext and SetThreadContext Now from reading through the sources Wine uses clone() to create threads, using its own implementation of clone for linux if not available that looks like it wouldn't work with cygwin... Cygwin has a pthreads implementation that maps onto the Windows Thread functions. So part of the question is, in order to get Wine to function properly on Cygwin, what is the right threading approach to take? Am I right in thinking that the current code wouldn't work on Cygwin? Approach 1 would be to simply call the Windows Thread functions from Wine if compiled on Cygwin That would involve the nastiness of including the w32api headers... Approach 2 would be to just use the Windows GetThreadContext/SetThreadContext functions, since they're just looking at registers etc. These could then be wrapped up in an (incomplete) ptrace implementation for cygwin, which we would call. Approach 3 would be to reimplement the appropriate parts of ptrace for cygwin in some other way. I'm guessing Approach 2 is right. Anyway any advice would be appreciated David

Nov. 28, 2002

RE: Missing SignalObjectAndWait

by Sean Mitchell

> I think that the first problem is that if foo.exe.so links with > libpthread.so, then libpthread.so gets loaded and initialized before > ntdll.dll.so is loaded and overrides the pthread functions in the C > library -> big trouble. > > This migh conceivable be worked around using a wrapper like I > described > for libmfc.so except this time the wrapper would just load libntdll.so > and the wrapped executable would link with libpthread.so. > > Then I guess it should work since threaded opengl libraries > are supposed > to work. > > But is there really an advantage to using pthread rather than > the Win32 > threading functions when porting a Windows application? After all one > should not have to change the code when porting with Winelib... Without SignalObjectAndWait() I imagine that many medium sized to large apps would have to consider alternative threading libraries... the app I'm trying to port uses it quite a bit to prevent race conditions. As an interested party rather than a developer I'd suggest that the effort would be best spent implementing SignalObjectAndWait() before worrying about pthread compatibility, but I don't know the extent of the work involved. For my own porting project I'm now considering at a "clean" port without any Windows calls - fortunately we only use the thread calls and some file system calls from the Win32 API - but I suspect that this might present a roadblock to other projects hoping for a painless port. In any case, you folks have done a great job with Wine and winelib, and I thank you for it. Cheers, Sean

Nov. 28, 2002

Re: [RFC] Winelib enhancements

by Dimitrie O. Paun

On November 28, 2002 04:23 am, Martin Wilck wrote: I've addressed both of these on the web page :) > I can't follow you here. You seem to have been porting Applications > using Unix-Style Makefiles. I'd guess the vast majority of Applications > comes with Windows VC++ "project files" (.dsp) and "workspaces" (.dsw). >From the page: "Fortunately, most OSS applications have a build system based around the MinGW tool chain. Sometimes they have alternative build systems for the Borland and/or Microsoft tools, but more often than not they have to support the MinGW tools out of necessity. I will cover this class of applications for the rest of this section." I should have been more clear: this message address this class of apps. The closed source ones have a VC++ build system, as you say, and are covered by winemaker. Not the focus of my efforts, though. > In any case, IMO this is what's winemaker is all about. Your idea of > introducing compatibility tools is nice but somewhat limited in scope. > What we really need is a much more intelligent winemaker. >From the page: "Before I begin, I think I need to explain why we have to treat these applications any differently. Why don't we just run winemaker, and get it over with? The reason is quite simple: people are attached to their build process, and for good reason. If we are to have our modifications included in their tree, we can not simply submit a new build system. Such a patch would never be accepted. Needless to say, having these modifications included in their build process is important." If we are to just generate a parallel build system, we'd be wasting out time. We have to make it simple so we have a chance of the app maintainers doing the porting themselves. There are thousand of apps, all we can do is port a few. But if we want them to recognize Wine as a platform, and port to it, we can not expect them to simply accept a parallel set of makefiles which are just a bit different from what they have. -- Dimi.

Nov. 28, 2002

Access Database

by Fabian Cenedese

Hi My app works with an Access mdb. Opening and reading goes fine. The problem comes with writing. There is a table called "Nodes". I delete it and then create a new one to fill in my data. For some strange reason the table gets created but with a name "Node", the s was munched. Even more strange that it works with other tables after this one. I already stepped through the MFC.dll and checked critical places (strlen, SysAllocString etc) but it always looked fine. Did anyone ever had something similar? Or can work with mdbs without problems? Thanks bye Fabi

Nov. 28, 2002

Re: [RFC] Winelib enhancements

by Martin Wilck

Am Don, 2002-11-28 um 11.37 schrieb David Fraser: > means people won't have to keep on using VC++. Or does winemaker do this > already? Yes. Actually, it produces "configure" and "Makefile.in". Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Nov. 28, 2002

Re: [RFC] Winelib enhancements

by David Fraser

Martin Wilck wrote: >Am Don, 2002-11-28 um 07.35 schrieb Dimitrie O. Paun: > > > >>-CC=gcc >>+CC=wcc >> >>-RC=windres >>+RC=wrc >> >> >> > >I can't follow you here. You seem to have been porting Applications >using Unix-Style Makefiles. I'd guess the vast majority of Applications >comes with Windows VC++ "project files" (.dsp) and "workspaces" (.dsw). > This is probably true, although a lot of the already-portable open source applications like Mozilla that Dimi's thinking of can use Unix-Style Makefiles as well. > >In any case, IMO this is what's winemaker is all about. Your idea of >introducing compatibility tools is nice but somewhat limited in scope. >What we really need is a much more intelligent winemaker. > > What would be really nice is if the new intelligent winemaker produced a Makefile, rather than doing the actual build. That way it would be less opaque to debug any problems as you could see exactly what the make was doing, and alter it if necessary. It also means people won't have to keep on using VC++. Or does winemaker do this already? David

Nov. 28, 2002

Re: [RFC] Winelib enhancements

by Martin Wilck

Am Don, 2002-11-28 um 07.35 schrieb Dimitrie O. Paun: > -CC=gcc > +CC=wcc > > -RC=windres > +RC=wrc > I can't follow you here. You seem to have been porting Applications using Unix-Style Makefiles. I'd guess the vast majority of Applications comes with Windows VC++ "project files" (.dsp) and "workspaces" (.dsw). In any case, IMO this is what's winemaker is all about. Your idea of introducing compatibility tools is nice but somewhat limited in scope. What we really need is a much more intelligent winemaker. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

Nov. 28, 2002

Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)

by Ove Kaaven

On Thu, 28 Nov 2002, Christian Costa wrote: > Does ICOM_USE_INTERFACE_ATTRIBUTE prevent g++ to add the 8 bytes offset? Yeah. > From which g++ version this can be used? Not sure, but I'm pretty sure it's been supported in Debian's 2.95.4 stuff (which grabbed lots of stuff from cvs, I think). So I'd guess that it probably works in 3.0.

Nov. 28, 2002