Re: Modifying registers
Generally, is there a way to modify registers? Must be obvious but I'm blind. set $eip = 0x42424242 Dito for the other registers. Thanks, worked fine. Should this be added to the docs? Even knowing now what to look for I couldn't find it. I guess this was taken from gdb's interface. Are there other 'unofficial' :) features in winedbg? bye Fabi
Re: COM vtable inconsistencies with g++ (was SIGSEGV inIDirectDrawImpl_EnumDisplayModes)
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.
compiling wine under cygwin - status
Hi all This is a brief indicator on what parts of wine compile successfully under cygwin and what give errors. Almost all the source code compiles successfully, but lots of things have linking problems. Note that I haven't yet tested the resulting parts that did link successfully. 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. My plan is to go through each one that doesn't link, look at all the errors, and categorize them (many are the same problem spread accross various dlls), so that we can tackle the more widespread problems first... Any help with this appreciated :-) David dlls/ advapi32 has errors avicap32 has errors avifil32 has errors cabinet has errors comcat links comctl32 links commdlg has errors crtdll has errors crypt32 links d3d8 has errors dciman32 links ddraw has errors devenum links dinput links dinput8 links dplay links dplayx links dsound has errors gdi has errors glu32 links icmp links imagehlp links imm32 links kernel has errors lzexpand has errors mapi32 links mpr links msacm has errors msdmo links msimg32 links msisys has errors msnet32 links msvcrt has errors msvcrt20 has errors msvideo has errors netapi32 links ntdll has errors odbc32 links ole32 has errors oleaut32 has errors olecli has errors oledlg links olepro32 links olesvr has errors opengl32 has errors psapi has errors qcap links quartz links rasapi32 links richedit has errors rpcrt4 links serialui links setupapi has errors shdocvw links shell32 has errors shfolder links shlwapi links snmpapi links sti links tapi32 links ttydrv has errors twain has errors url links urlmon has errors user has errors version has errors win32s has errors winaspi has errors winedos has errors wineps has errors wininet has errors winmm has errors winnls has errors winsock has errors winspool has errors wintrust links wow32 links wsock32 links x11drv has errors library/ libwine.dll links successfully miscemu/ requires ntdll.dll ole/ libwine_uuid.a links successfully programs/ avitools/aviinfo.exe links avitools/aviplay.exe links clock/clock.exe links cmdlgtst/cmdlgtst.exe links control/control.exe links expand/expand.exe links osversioncheck/osversioncheck.exe links progman/progman.exe links regapi.exe/regapi.exe links regsvr32/regsvr32.exe links regtest/regtest.exe links uninstaller/uninstaller.exe links view/view.exe links wcmd/wcmd.exe links winefile/winefile.exe links winemine/winemine.exe links winepath/winepath.exe links winhelp/winhelp.exe links winhelp/hlp2sgml.exe links winver/winver.exe links winhelp.exe links server/ context_i386.c has compile error (You must implement get/set_thread_context for your platform) tools/ bin2res.exe links fnt2bdf.exe links makedep.exe links widl/widl.exe links winebuild/winebuild.exe links winedump/winedump.exe links wmc/wmc.exe links wpp/libwpp.a links wrc/wrc.exe links unicode/ libwine_unicode.dll links libwine_unicode.a links
Re: Doc building update, finally
- Original Message - From: Vincent Béron [EMAIL PROTECTED] To: Dustin Navea [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 27, 2002 11:54 PM Subject: Re: Doc building update, finally Dustin Navea wrote: Vincent, I finally got SGMLtools installed and went to build the doc. Only problem is that instead of it outputting to files it prints the output on screen. Is there a flag that I may be missing or what? I'm using SGMLTools pre-compiled and built.. Downloaded from ftp://ftp.slackware.com/pub/slackware/slackware-current/extra/sgml-tools-1.0 .9-i386.tgz and installed using pkgtool which comes with slackware.. -Dustin P.S. Any outputs you need say from man or --help on docbook2html? I'll download the package and check what's inside. It'll be less things sent by email ;) Don't expect an answer tomorrow though, it may take a few days because of Real Lide(tm). But I'll definetly look into it (could be the same problem as Joerg, which is that the options to specify a dsl file are different). I dont think its that, in fact I checked, -d specifies the dsl file, so Im not sure what it is, as soon as I get around to configuring Lin to use my new DSL I will check more into it.. Right now im on windows getting everything working there.. -Dustin
Re: Doc building update, finally
- Original Message - From: Vincent Béron [EMAIL PROTECTED] To: Dustin Navea [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, November 27, 2002 11:54 PM Subject: Re: Doc building update, finally Dustin Navea wrote: Vincent, I finally got SGMLtools installed and went to build the doc. Only problem is that instead of it outputting to files it prints the output on screen. Is there a flag that I may be missing or what? I'm using SGMLTools pre-compiled and built.. Downloaded from ftp://ftp.slackware.com/pub/slackware/slackware-current/extra/sgml-tools-1.0 .9-i386.tgz and installed using pkgtool which comes with slackware.. -Dustin P.S. Any outputs you need say from man or --help on docbook2html? I'll download the package and check what's inside. It'll be less things sent by email ;) Don't expect an answer tomorrow though, it may take a few days because of Real Lide(tm). But I'll definetly look into it (could be the same problem as Joerg, which is that the options to specify a dsl file are different). I dont think its that, in fact I checked, -d specifies the dsl file, so Im not sure what it is, as soon as I get around to configuring Lin to use my new DSL I will check more into it.. Right now im on windows getting everything working there.. -Dustin
Re: [RFC] Winelib enhancements
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
Re: [RFC] Winelib enhancements
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 WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Access Database
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
Re: [RFC] Winelib enhancements
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.
RE: Missing SignalObjectAndWait
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
Re: compiling wineserver under cygwin - thread context
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
Re: compiling wineserver under cygwin - thread context
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.
Re: compiling wineserver under cygwin - thread context
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 - 1.24
+++ server/context_i386.c 28 Nov 2002 15:48:01 -
@@ -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
Re: [RFC] Winelib enhancements
Am Don, 2002-11-28 um 15.24 schrieb Dimitrie O. Paun: I've addressed both of these on the web page :) Well, I should have read it more thoroughly, I guess :-/ 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. I understand your reasoning now. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: How to debug wineserver
Rajesh Akkineni wrote: hi, is there any way we can debug the wineserver? thanks Rajesh I am not sure this is the right answer since I am not a wine guru. However when you start wineserver you can start it with debug levels i.e., wineserver -d1. Setting d0 turns winserver debugging off. I'm not sure what you are asking this for. -- Tony Lambregts
Chronic crash on Photoshop
Can someone look at the bug I raised about Photoshop crashing wine, (and potentially the whole of X11 and Linux) http://bugs.winehq.com/show_bug.cgi?id=1165 It's probably the most extreme bug I've seen on Linux ever. I wasn't sure if this was the appropriate place to post this request, so feel free to correct me. Cheers -Rob.
Re: Modifying registers
Fabian Cenedese wrote: Generally, is there a way to modify registers? Must be obvious but I'm blind. set $eip = 0x42424242 Dito for the other registers. Thanks, worked fine. Should this be added to the docs? Even knowing now what to look for I couldn't find it. I guess this was taken from gdb's interface. Are there other 'unofficial' :) features in winedbg? I will add this as part of the Advanced Debuging Techniques section of the Developers Guide. (working on it.) -- Tony Lambregts
Re: How to debug wineserver
Am Don, 2002-11-28 um 17.16 schrieb Tony Lambregts: is there any way we can debug the wineserver? I am not sure this is the right answer since I am not a wine guru. However when you start wineserver you can start it with debug levels i.e., wineserver -d1. Setting d0 turns winserver debugging off. Starting wine with -debugmsg trace+server works quite well. Furthermore, wineserver is a true Unix program. You can run in through gdb. I often run wine normally, then start gdb and simply attach to the running wineserver process. Martin -- Martin WilckPhone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Re: [PD-announce] Announce: Vstserver, vstlib, vstladspa and k_vst~
On Wed, 27 Nov 2002, Kjetil S. Matheussen wrote: vst ladspa plugin v0.0.1 - alpha - Oops, uploaded a totally wrong file for this one. The correct one is now http://www.notam02.no/arkiv/src/ladspavst.tar.gz --
Announce: Vstserver, vstlib, vstladspa and k_vst~
VSTServer V0.0.1. - First release. Beta, but usable. ABOUT Vstserver is a wine program that must be running when using programs using vstlib. Vstlib is a library that can be used by programs to run windows vst audio plugins under linux/freebsd/i386solaris/etc. RUNNING Vstserver is started like this: wine vstserver.so. You probably want to set the VST_PATH environment variable pointing to your plugins first. DEVELOPMENT Vstserver is released under the GPL, and vstlib under LGPL. If there comes many source-contributions, I will probably make it a sourceforge project. To use vstlib in a program, look at the tests/exampleclient program, and various vst plug-in documentation. The interface to the vstlib consists only of two functions (new/delete), the rest is like you would do when programming for windows, macos(X), beos, irix, etc. CURRENT STATUS Vstserver seems to be very stable. I have not found any plug-ins that wont run, and I am not able to hear any latency. And plug-ins does not seem to cause more cpu-power than under windows. No GUI or graphics-support yet. BUGS 1. When running the ladspa listplugins program many times in a row, I get the following errors before the server freeze: err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:region:CombineRgn Invalid rgn= err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:region:CombineRgn Invalid rgn= err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:region:CombineRgn Invalid rgn= err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this. I dont know what this is. Its not errors coming from the vstserver program. It seems to be related to X, allthough no graphics is used in the vstserver. I hope its just the buggy libXrender.so library that wine shouts about each time it starts. 2. Shared memory handlig might be faulty. I suspect that it doesnt free resources. (see server/shmhandler.c) 3. I havent read the vst plug-in documentation yet, and dont know everything about it. This especially goes for the AudioMasterCallback function, which for now just returns 1. I guess some more work needs to be done in this area, and for the various dispatch opcodes too. 4. The processReplacing function in vstlib should perhaps be made just by calling the process fuction. But I dont understand the difference between processReplacing and processing. FUTURE Add GUI and graphics support to the server (help wanted). And maybe make a DX-plugin server. (would be fun running pi-warp under linux). CREDITS vstserver and vstlib are made by Kjetil S. Matheussen / Notam. [EMAIL PROTECTED] Some programming hints is gathered by looking at the pd vst-object plugin~ source and the jack soundserver source. vst ladspa plugin v0.0.1 - alpha - Makes vst plugins located in $VST_PATH appear as ladspa plugins. I'm not sure how well this one actually works. The northpole plugin seems to work, but others don't. Oh well, its alpha for now. k_vst~, a Pd tilde object for hosting VST plug-ins. --- This is really just the plugin~ source made by Jarno Seppänen, but with a few lines changed (very few that is) to make it work with vst-plugins using the vstlib. The name was changed from plugin~ to k_vst~ to avoid nameclash with the plugin~ object running ladspa plugins. This object is for i386 non-windows (ie. linux/freebsd) only. This one works very well! - vstserver, ladspavst and k_vst~ are open-source programs made at Notam / Oslo, and can be downloaded from from http://www.notam02.no/arkiv/src/ --
Re: [RFC] Winelib enhancements
Dimitrie O. Paun [EMAIL PROTECTED] writes: However, these tweaks are really annoying in the initial stages of the port, and would be so nice if we had a nice compiler wrapper (call it wcc) that would do that behind the scenes, so that the only modification to the makefile would be: -CC=gcc +CC=wcc Q: Alexandre, would you accept such a utility in the tree? I don't know, I don't think you can write a one-size-fits-all script, different apps will require different options, and then it will get even more confusing IMO if you have two different ways of doing it depending on your options. Maybe we should simply have a script example in the documentation that people can adapt and ship with their app if the makefile really makes it hard to set options. -RC=windres +RC=wrc This would mean moving the resources out of the .spec.c file, and exporting the resources variable so we can link it into the .spec.c file. Q: Alexandre, is this acceptable? Does it warrant discussion? I don't think that's necessary. Using .o files has a number of problems, and it's really cleaner to use .res IMO. It's also more along the lines of how Windows does it, and allows you to keep using windres if you want, instead of being forced to switch to wrc. 2. Our linking process is quite different from the standard one which uses gcc/ld to do the linking. We generate intermediate files (.spec.c files), and use different flags. Again, the solution for this (to at least help initial porting efforts) would be a wrapper script that does this, that can be used instead of ld. And so the question comes back again, to haunt us: is this needed/wanted/acceptable? Yes, I think we want a wrapper like dllwrap to do all that. I'm not sure a script would be enough, we may want a full-fledged C program. The idea would be that you do something like: winewrap *.o *.res -o foo -lwhatever and it builds the .spec.c, compiles it, links everything into foo.exe.so, and builds a foo executable (which may be a wrapper script or a real ELF binary). This also (mostly) solves the Running issues: you still have a .exe.so file, but you don't really need to worry about it. You simply run foo and everything works. -- Alexandre Julliard [EMAIL PROTECTED]
Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)
Ove Kaaven wrote: 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. Thanks! It works fine with the version 2.96 I use.
Re: [RFC] Winelib enhancements (Compiler)
On November 28, 2002 01:35 pm, Alexandre Julliard wrote: -CC=gcc +CC=wcc Q: Alexandre, would you accept such a utility in the tree? I don't know, I don't think you can write a one-size-fits-all script, different apps will require different options, and then it will get even more confusing IMO if you have two different ways of doing it depending on your options. Maybe we should simply have a script example in the documentation that people can adapt and ship with their app if the makefile really makes it hard to set options. Sorry, maybe I was unclear. This wrapper will probably be a small C program that understands gcc's options. It needs to do the following: -- add the include dirs first -- add -fshort-wchar -- add -D__int8=char -D__int16=short -D__int32=int -D__int64=long long -- remove cygwin options not recognized by the Linux gcc If you think about them, it kindda makes sense, as under a Windowish environment these options are _implied_ in the invocation of gcc, just like -I /usr/include is implied when you invoke gcc under Linux. So to be honest, I don't see why it would be confusing, and second, why we can not have a one-size-fits-all wrapper. As I said, this is more a porting tool, to help you with the initial port. If the app has a configure script, you would want to instrument it to generate the correct flags for the compiler, and use gcc directly. But this is time consuming, and you have to worry about so many things at the beginning, I find it so much easier to have something working, and tweak only one thing at a time. -- Dimi.
Re: [RFC] Winelib enhancements (Linking)
On November 28, 2002 01:35 pm, Alexandre Julliard wrote: Yes, I think we want a wrapper like dllwrap to do all that. I'm not sure a script would be enough, we may want a full-fledged C program. The idea would be that you do something like: winewrap *.o *.res -o foo -lwhatever Excellent, exactly what I had in mind too. And you are right, it will take care of the running business as well. I'll add to the pages. -- Dimi.
Re: [RFC] Winelib enhancements (wrc)
On November 28, 2002 01:35 pm, Alexandre Julliard wrote: I don't think that's necessary. Using .o files has a number of problems, and it's really cleaner to use .res IMO. It's also more along the lines of how Windows does it, and allows you to keep using windres if you want, instead of being forced to switch to wrc. I did not mean to say that we should chance the way wrc works. Just enhance it to support a direct to .o compilation mode. As for more along the lines of how Windows does it is an academic issue: all OSS projects coding for Win32 use windres, and they compile directly to .o. Keep in mind that windres can be used just like wrc (.rc - .res), but nobody uses it like that. The problem with that of course is that the makefiles have the resource.o file in all sorts of variables, etc. You can go and get rid of it from there manually for the initial porting effort, but it's actually not trivial to come up with solution that's acceptable to the app maintainer. Keep in mind that due to these thing working only on Windows, most of the apps don't have (and don't need) a configure script. Tweaking build processes is nasty, nasty business. Even the nice and clean ones are hard to understand, let alone the fact that most are ... weak. :) For a big project, you're in for a lot of pain. Most people will no go through with it if they know they don't have a chance of integrating their changes upstream. Or maybe that's just me... -- Dimi.
Re: [RFC] Winelib enhancements (wrc)
On November 28, 2002 02:26 pm, Alexandre Julliard wrote: That was my point. If you replace the .rc.o rule by .rc.res and .res.o then windres happily builds the .res for you, and it still works on Windows too. This is simple, I agree. Adding a .rc - .res is simple, and portable. Yes you need to change the link command-line but I don't think it's that bad. What about having to deal with the .o file that is present all over the place? That is the problem. And without a configure script, it becomes nasty. Generating .o files in the proper format for linking directly is fairly hard to do cleanly in ELF; wrc actually supports generating C files, and we used to do it that way, but you need all kinds of tricks to make them integrate properly in the PE header. In fact, I had something a lot simpler in mind. Currently, we define a variable called resources in the .spec.c file, which is later used in the nt_header structure. The idea was to simply generate the resources tree in a separate .c file, rename it to something like __wine_spec file name_resources, and make it non-static. Later, we can use it in the nt_header structure, just like we do right now. We still need to transfer the size of the resources... -- Dimi.
Re: [RFC] Winelib enhancements (wrc)
Dimitrie O. Paun [EMAIL PROTECTED] writes: In fact, I had something a lot simpler in mind. Currently, we define a variable called resources in the .spec.c file, which is later used in the nt_header structure. The idea was to simply generate the resources tree in a separate .c file, rename it to something like __wine_spec file name_resources, and make it non-static. Later, we can use it in the nt_header structure, just like we do right now. We still need to transfer the size of the resources... The biggest problem is if you want to support multiple resource files. But as long as you don't break the current .res support that wouldn't matter too much I guess. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wglCreateLayerContext?
This OpenGL method is currently a stub, looking at the MSDN documentation I can't see why this is the case given the fairly complete GL implementation Wine has. Is it that we cannot handle layering properly in X or something? Well, the case 'iLayerPlane == 0' would be easy as it's the main plane.. But do tell me how you plan to do OpenGL underlay and overlay planes using GLX ? Maybe there is a GLX extension to that effect, but I am not aware of it. Moreover, do you actually have an application using this ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Last one for today :-)
Le jeu 28/11/2002 à 17:24, Lionel Ulmer a écrit : re-reHi... This patch implements the 'GetRenderTarget' method for the IDirect3DDevice COM object. It is independant from all previously submitted patches (but to prevent 'fudging', it is better to commit after the GetDirect3D AddRef fix). With this series of patch, the Boids demo from the DX6 SDK is now running (it's not working because we are lacking some D3D code, but at least it does not crash :-) ). Changelog: - implement GetRenderTarget A bit too much work on your part I bet, as you forgot to attach the patch ;-) Vincent
wine preempt patch (fwd)
Hi, is there are known issue with the preempt patch for the kernel? When I apply that patch, non-open-gl games doesn't run smooth, without the patch they run nearly smooth (especially StarCraft BaldursGate). OpenGL games are alway fine. matthias
Re: [RFC] Winelib enhancements (wrc)
On November 28, 2002 04:19 pm, Alexandre Julliard wrote: The biggest problem is if you want to support multiple resource files. But as long as you don't break the current .res support that wouldn't matter too much I guess. Yeah, but it's very limitted. I forgot about the multi-file part. Hmmm... Me don't like this. What else can we do? What about this: -- currently, makefiles have such a rule: %.o: %.rc $(WINDRES) $ $@ -- it's easy enough to split it like so: %.res: %.rc $(WINDRES) $ $@ %.o: %.res $(RC) $@ $ And the WINDRES and RC variables will be defined as such: in MingW: WINDRES = windres RC = windres in Winelib: WINDRES = wrc RC = utility_that_creates_dummy_empty_object_file Which leaves just the linking a bit different... Even better, we can just remember the .res file in the dummy object file, and have the link wrapper recover it from there, so we just have to redefine LD, instead of modifying the link target. This way you should be able to compile a Win32 app under Winelib with a few changed definitions in the Makefile: CC, WINDRES, RC, LD and split the .rc.o rule into .rc.res, and .res.o. Now that's easy. How about it? -- Dimi.
[RFC] Wine headers
Alexandre,
Patrik brought up the header location sometime ago, in this thread:
http://www.winehq.com/hypermail/wine-devel/2002/10/index.html#540
At the time, I thought it is a bit premature, that we have other
things to do. Now I realize that this is one of those highly visible
external things, that would be a _lot_ better to fix before people
start using Winelib. Otherwise will piss people off when we change,
or we will not change because people are already using the headers.
Both versions are not good, and I think we can fix them now without
too much pain.
Here is my proposal:
${prefix}/include/win32 -- standard Win32 headers
${prefix}/include/msvcrt -- MS Visual C Runtime library
${prefix}/include/wine -- Wine specific headers
It is simple (to understand implement), clean, and pretty.
And I think it solved Patrik's problem (even if I can't quite
understand what the problem is from the first message :)),
plus a bunch of other things (like making it easy to use other
headers for the Win32 API, etc). And best of all, it seems to
be easily implementable, no?
--
Dimi.
Re: COM vtable inconsistencies with g++ (was SIGSEGV in IDirectDrawImpl_EnumDisplayModes)
Do you know RedHat's gcc 2.96 has SERIOUS bugs and that its support has been totally dropped ? It's update time. Thanks! It works fine with the version 2.96 I use. = Sylvain Petreolle [EMAIL PROTECTED] Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 Don't think you are. Know you are. Morpheus in Matrix, chapter 15. ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Doc Build, Diablo II Regression Test, and TreeView Patch Test Updates
Vincent, Alexandre, and Dimi Grrr, Im really starting to not like Linux'sPPPoE support... I have tried every version of pppd and pppoe that is available besides CVS (and thats because I cant get online in Linux to get it) in order to get my DSL workin in Linux and I am giving up until I can afford to get a DSL Router (hopefully next week). So until then, I will be unable to do any regression testing on Diablo II and will be unable to test out any of the most recent patches to verify that they fix problems with my setup...so until nextWednesday I will probably just lurk on the lists -Dustin
Re: Doc Build, Diablo II Regression Test, and TreeView Patch Test Updates
- Original Message - From: Dimitrie O. Paun [EMAIL PROTECTED] To: Dustin Navea [EMAIL PROTECTED]; Wine Developers [EMAIL PROTECTED] Sent: Friday, November 29, 2002 5:41 AM Subject: Re: Doc Build, Diablo II Regression Test, and TreeView Patch Test Updates On November 29, 2002 12:31 am, Dustin Navea wrote: Grrr, Im really starting to not like Linux's PPPoE support... I know, PPPoE can blow chunks sometimes. I've switched to cable, and I'm not going back! :) A long time ago in an apartment complex not too far away ;) I had cable and got evicted and had to cancel it. If I had Time Warner in this complex instead of US Online I would have gotten cable, but this was all that I could get and plus it _lowered_ my total phone bill by about $15 a month, long story I will tell later.. so until next Wednesday I will probably just lurk on the lists Don't worry -- the treeview patch I've submitted is not supposed to fix anything just yet. Oh man, sooo many things to do, so little time... lol, I hear ya, it looks like it is a step in the right direction at least, I will have to admit that at first glance I had thought you removed some essential stuff, but then I looked more carefully, so I should shut up now ;) -Dustin
Re: Doc Build, Diablo II Regression Test, and TreeView Patch Test Updates
On November 29, 2002 12:31 am, Dustin Navea wrote: Grrr, Im really starting to not like Linux's PPPoE support... I know, PPPoE can blow chunks sometimes. I've switched to cable, and I'm not going back! :) so until next Wednesday I will probably just lurk on the lists Don't worry -- the treeview patch I've submitted is not supposed to fix anything just yet. Oh man, sooo many things to do, so little time... -- Dimi.
small updates to debugger.sgml
Before I could feel right about adding Advanced Debugging Techniques to the documnetation I needed to update the documentation on the debugger. There is still one section that is out of date (that I am aware of). The section that I am refering to is as follows Program hangs, nothing happens Switch to UNIX shell, get the process-ID using ps -a | grep wine, and do a kill -HUP pid (without the and ). Wine will then enter its internal debugger and you can proceed as explained above. Also, you can use --debug switch and then you can get into internal debugger by pressing Ctrl-C in the terminal where you run Wine. This is _wrong_ since neither work. I have added a fix me message in front of this since I am unable to come up with anything usefull to replace it. If anyone has a usefull suggestion I would appreciate it. Change log: Update the debugger documentation for current usage. Files: /documnetation/debugger.sgml -- Tony Lambregts Index: debugger.sgml === RCS file: /home/wine/wine/documentation/debugger.sgml,v retrieving revision 1.13 diff -u -r1.13 debugger.sgml --- debugger.sgml 1 Oct 2002 18:13:09 - 1.13 +++ debugger.sgml 29 Nov 2002 06:08:53 - @@ -271,8 +271,9 @@ para This file describes where to start debugging Wine. If at any point you get stuck and want to ask for help, please read the -file filenamedocumentation/bugreports/filename for -information on how to write useful bug reports. +emphasisHow to Report A Bug/emphasis section of the +emphasisWine Users Guide/emphasis for information on how to write +useful bug reports. /para sect2 @@ -311,8 +312,7 @@ para Steps to debug a crash. You may stop at any step, but please report the bug and provide as much of the information - gathered to the newsgroup or the relevant developer as - feasible. + gathered to the bug report as feasible. /para orderedlist @@ -362,17 +362,26 @@ If you have found a misbehaving function, try to find out why it misbehaves. Find the function in the source code. Try to make sense of the arguments passed. Usually there is - a functionTRACE(lt;channel,(...)\n);/function at - the beginning of the function. Rerun wine with + a functionWINE_DEFAULT_DEBUG_CHANNEL(lt;channel);/function + at the beginning of the file. Rerun wine with parameter-debugmsg +xyz,+relay/parameter added to the commandline. /para +para + Occasionally there are additional debug channels defined at the + begining of the file in the form. + functionWINE_DECLARE_DEBUG_CHANNEL(lt;channel);/function + If so the offending fuction may also uses one of these alternate + channels. Look through the the function for + functionTRACE_(lt;channel)( ... /n);/function and add any + additional channels to the commandline. +/para /listitem listitem para Additional information on how to debug using the internal debugger can be found in - filenamedebugger/README/filename. + filenameprograms/winedbg/README/filename. /para /listitem listitem @@ -386,29 +395,25 @@ /listitem listitem para - If even that isn't enough, add more debug output for - yourself into the functions you find relevant. See - filenamedocumentation/debug-msgs/filename. You might + If even that isn't enough, add more debug output for yourself + into the functions you find relevant. See The section on Debug + Logging in this guide for more information. You might also try to run the program in commandgdb/command instead of using the WINE-debugger. If you do that, use parameterhandle SIGSEGV nostop noprint/parameter to disable the handling of seg faults inside - commandgdb/command (needed for Win16). If you don't use - the parameter--desktop/parameter or - parameter--managed/parameter option, start the WINE - process with parameter--sync/parameter, or chances are - good to get X into an unusable state. + commandgdb/command (needed for Win16). /para /listitem listitem para - You can also set a breakpoint for that function. Start wine - with the parameter--debug/parameter option added to the - commandline. After loading the executable wine will
