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

Re: dos console apps question

by Eric Pouech

> Having the process use the current term window is exactly what I'm looking for. How far along is the patch you have and would you be in need of any assistance? the point I need to think of is how to switch between the different backends (taking into account all possible cases) I may look into that in the next days > I'm not sure what you mean by not being able to have the parent process communicate with the child process and how this affects things. Alexandre's idea (for the evolution of process creation is as follows) - for processes created from the UNIX command line (and possibly with both Wine and programs arguments) do as follows - a wine launcher would read all wine arguments (either command line, environment strings, registry) and create the requested child process (the one from the command line), setting all necessary arguments, options... - it would be this program which would be in charge of 1/ creating a new console (if needed) 2/ make the child process inherit from the unix console and/or streams (if needed) A+

July 30, 2002

Re: winedbg again :-)

by Eric Pouech

> Tried your remote add-on too, but no success... maybe I did something wrong. what's wrong ? could you explain a bit more ? > A little (and maybe dummy, as usual!) question : as winedbg is a winelib app, > is it possible to link it with QT, or there are some known problems ? well, as usual, the threading model may be an issue. to my knowledge noone ever tried it A+

July 30, 2002

(no subject)

by Raul Dias

David D. Hagood <wowbagger(a)sktc.net> wrote: >Andreas Mohr wrote: > >> Add to that the fact that CUPS gets rather completely rid of the useful >> Unix filter machanism, and you really start to wonder whether CUPS really >> is better than say lpd+printtool. Quite the other way around or so... > > >Actually, I do beleive that CUPS does use a filter mechanism internally. > But I do agree - I'm not as sure that CUPS is all that much better. >But to REALLY fix printing would mean far more than what CUPS can do - >IMHO what we need is more of a RPC style system, where the client app >communicates bidirectionally with the print server, so that the client >can ask "What can you do for me?", the server responds "I can staple, >collate, bind, and add gold leaf inlay", and the client can present that >to the user. Maybe some sort of XML/SOAP sort of thing.... (-1, Offtopic). Hmm... Cups already does this for me. :) []'s Raul Dias (yes, I broke my mailer subject support)

July 30, 2002

Re: Resubmitting patch for memory-mapping problem -- See VirtualQuery post in wine-devel

by Massimo

Tony Lambregts wrote : >Looks like Alexandre was at least thinking of this (a little) when >he wrote this patch >http://cvs.winehq.com/patch.py?id=1027987166850574216879071 >You should probably try this out and see if it fixes bug 890. Yes, I've seen it after posting.... Don't have fully tested for bug 890, but AutoCAD2000 starts good now, as with my patch. I'll test it later on and close bug 890 Regards Max

July 30, 2002

Re: dos console apps question

by dank＠kegel.com

Eric Pouech wrote: > however, what you're facing right now is running a DOS program directly > from the unix prompt (like wine mydospgm.com) > in this case, there is no way for the parent process to tell something > to its child, you it's up to you to do it by running the program with > wineconsole mydospgm.com In my favorie case, i.e. running programs like sed.exe or ss.exe from the unix commandline, what you really want is for Wine to just get out of the way, do no graphics whatsoever, not even do any X calls at all, and run the bloody commandline program hooked up to the existing unix stdin and stdout. For instance, the Wine 20020509 that comes with redhat 7.3 seems to do about the right thing when you run it on the sed.exe from http://unxutils.sourceforge.net/UnxUpdates.zip It starts up quickly and processes input from stdin right away. Running the same program in wineconsole takes forever (as it loads fonts and creates a window) and doesn't work. So wineconsole isn't the answer for any programs I run. > (1): what's currently missing is a clean way to choose in wineconsole > between the (well known) windows (GDI/USER) version and (not yet > committed) (n)curse for display I saw ncurses in a recent wine... it was horrible, there was no way to turn it off. I couldn't run any commandline programs properly anymore. Hopefully the work you're talking about would make it easy to run programs which want neither GDI nor ncurses. - Dan

July 30, 2002

Re: Toolbar redraw problem

by Guy L. Albertelli

----- Original Message ----- From: "dusanv" <dusanv(a)cadlink.com> To: "wine-devel" <wine-devel(a)winehq.com> Sent: Monday, July 29, 2002 4:27 PM Subject: Toolbar redraw problem > Hi, > > I am seeing a bunch of apps have redrawing problems when a toolbar is > dragged accross the window. Here's a screen shot: > > http://dusanv.net/files/wine-ss.png > > Does anyone have any info on this? I'd like to fix it but can't find > anyhting relevant. > Could you please create a bug in Wine's Bugzilla http://bugs.winehq.com/. And if that is a test program, that would be good to ad also. I suspect that somewhere during the drag operation, the rectangle invalidated does not contain the edges. It will be fun to find. Thanks, Guy

July 30, 2002

Re: Resubmitting patch for memory-mapping problem -- See VirtualQuery post in wine-devel

by Tony Lambregts

Massimo wrote: >Was this patch lost in space or does it have some problem ? > >Took off in executable mapping VPROT_WRITE and VPROT_WRITECOPY flags >and > added VPROT_EXEC; that looks much more close to win2k mapping. >The only difference now is in Type field, wine maps as MEM_PRIVATE and win2k >as MEM_IMAGE (I guess that's the right one, but no time now to check. > >The patch solves (partially) bug 890, and allows AutoCAD 2000 to start up (only in >win95 mode, because of another problem on fibers). > >Here the attached patch.... any comment appreciated :-) > >Regards > >Max > > > > >------------------------------------------------------------------------ > >Index: virtual.c >=================================================================== >RCS file: /home/wine/wine/memory/virtual.c,v >retrieving revision 1.80 >diff -u -r1.80 virtual.c >--- virtual.c 3 Jul 2002 21:10:44 -0000 1.80 >+++ virtual.c 19 Jul 2002 19:33:10 -0000 >@@ -94,7 +94,6 @@ > PAGE_EXECUTE_WRITECOPY /* READ | WRITE | EXEC | WRITECOPY */ > }; > >- > static FILE_VIEW *VIRTUAL_FirstView; > static CRITICAL_SECTION csVirtual = CRITICAL_SECTION_INIT("csVirtual"); > >@@ -345,6 +344,7 @@ > ) { > if (protect) { > *protect = VIRTUAL_Win32Flags[vprot & 0x0f]; >+ > /* if (vprot & VPROT_GUARD) *protect |= PAGE_GUARD;*/ > if (vprot & VPROT_NOCACHE) *protect |= PAGE_NOCACHE; > >@@ -650,7 +650,8 @@ > > if (removable) hmapping = 0; /* don't keep handle open on removable media */ > if (!(view = VIRTUAL_CreateView( ptr, total_size, 0, >- VPROT_COMMITTED|VPROT_READ|VPROT_WRITE|VPROT_WRITECOPY, > this next line is redundant and should not be in the patch >+// PATCH VPROT_COMMITTED|VPROT_READ|VPROT_WRITE|VPROT_WRITECOPY, >+/*PATCH*/ VPROT_COMMITTED|VPROT_READ|VPROT_EXEC, > hmapping ))) > the /*patch */ should not be in the patch file. > { > SetLastError( ERROR_OUTOFMEMORY ); > > > Looks like Alexandre was at least thinking of this (a little) when he wrote this patch http://cvs.winehq.com/patch.py?id=1027987166850574216879071 You should probably try this out and see if it fixes bug 890. <g> Tony Lambregts

July 30, 2002

Re: PATCH: temp fixes, again

by Alexandre Julliard

Marcus Meissner <meissner(a)suse.de> writes: > I do not see why we should not use mkstemp, it is one of the canonical > ways of creating tempfiles throughout the security community. Well, I don't like it, but since apparently everybody else does I've applied the patch anyway... -- Alexandre Julliard julliard(a)winehq.com

July 29, 2002

Re: Dinput - Keyb Bug

by Jesse Allen

> > Well, I am investigating the DInput problem... Looks strange. I may well > ask you to add some more TRACEs in the code to help me understand better > what happens (ie if it's blocking in Wine code or in application code). I've should have mentioned this. The game configures it's key bindings through their own scripting system by default. An example is attached. > But I would be interested on a +opengl trace too. > And maybe you should > try to remove all trace of glide2x.dll of your system (maybe once Tribes > manages to load the glide2x it cancels OpenGL as it supposes that a > system with Glide2x will work better with it than with OpenGL). Well, what I referred to about running in Glide was a long time ago. This was before I got my new nvidia card, and before I built linux from scratch. So this LFS system is pretty clean. Glide doesn't even show up --just software mode which I run it in now. That trace2.log included +opengl. There are no opengl calls at all (software mode still) in the game menus or even when its rendering which I did for that trace. I tried to force opengl through a script file and it didn't work. I can run more traces if necessary. Jesse

July 29, 2002

Including winnt.h

by LUSTBADER,STEVE (Non-A-hsgAndover,ex1)

I ran into a problem (syntax error) with some functions that are declared __cdecl using WineLib. Including winnt.h directly fixed the problem, but it doesn't seem like the right solution. Shouldn't winnt.h be included automatically (ie, by another header file somewhere that's included by WineLib)? I'm not really sure how to track that down, which is why I emailed the list. ****************************** Steve Lustbader

July 29, 2002