wine-devel

wine-devel@winehq.org

3 participants
84399 discussions

Re: ReadFile and other issues
by Alexandre Julliard 22 Aug '01

22 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > fairly acceptable ;-) except that in line editing mode we need to lock > the input buffer on a single thread (that's the way the queue is > handled, > at least, on NT 2000 - didn't check the others) (the granularity for > getting access to the queue is not the input record, but the line (up to > '\n')) I guess line editing could be done by wineconsole, and the input records would only be sent to the server once we have a complete line. Or do we need more locking than this? > I was thinking of either a anonmymous file or an anonymous mapping for > the content of the screen buffer... with an array attribute and char > may be some additional info on each row to indicate the rendering > program about the rows which have been modified... The problem with a shared buffer is that you need to lock against simultaneous access, which means a hung thread can hang the whole console. I'd prefer to have the server simply report to wineconsole the bounding rect of the screen buffer area that has been modified, and have wineconsole use ReadConsoleOutput to retrieve the buffer contents from the server. It's only a few Kbytes to copy at most so performance should be acceptable. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: ReadFile and other issues
by Alexandre Julliard 22 Aug '01

22 Aug '01

"Eric Pouech"<eric.pouech(a)voila.fr> writes: > if we want to go into this, there are a few points to agree on first: > - since console handles can be inherited, the Wine console window should > be run in a different process than the one which uses the console (and > add communication means between the first process, and the process > rendering the console) > - how should we know a program needs either a simple or a complex > console (we could use a registry key in the per process area) We need a separate process yes. I was thinking of something like a 'wineconsole' Winelib app. Then if you want to run an app with a separate console you use wineconsole instead of wine to start it. A new wineconsole could also be launched when the app does an AllocConsole, or some other function that requires a complex console. The communication with the console can probably go through the server. Input events can simply be put in the queue by wineconsole using WriteConsoleInput. Output should probably go to a server screen buffer object, which would then signal wineconsole that its contents changed. -- Alexandre Julliard julliard(a)winehq.com

2 1

custom CFLAGS
by mdew 22 Aug '01

22 Aug '01

too my previous subject... err:module:map_image Could not map section .data, file probably truncated the problem was my custom CFLAGS, which havent caused me too many problems...till lately ...(using wine) export CFLAGS="-O3 -ffast-math -fthread-jumps -fcse-follow-jumps -mpentiumpro -march=pentiumpro -mcpu=i686 -malign-loops=2" err:module:map_image Could not map section .data, file probably truncated /usr/local/bin/wine: can't exec './xxx.exe': error=21 gcc 2.95.4-6 (Debian Sid) I havent tried gcc-3.0.1 yet, i trust gcc-2.95.4 still...give it another few versions before i'll look at gcc3. in paticular is the use of -O3 over -O2, -O2 will work, -O3 will fail..why is that? -- id: 9DF3262C key fingerprint: B556 04DA CFD9 78DD 9215 A970 8196 FB6D 9DF3 262C

2 3

Re: ReadFile and other issues
by Eric Pouech 22 Aug '01

22 Aug '01

> I'm not sure we should be converting xterm input into INPUT_RECORD. It > may be better to have two modes, a simple console that returns an fd > to ReadFile and no input records (and then ReadConsoleInput could > generate them on the fly if necessary), and a complex console that > supports all the features but that doesn't have an associated fd at > all. > > IMO the current xterm-based console support is a ugly hack; we should > do a proper Windows console using a normal Wine window with a message > loop to retrieve input events. And usage of stdin/stdout should be > limited to programs that don't need special console features, and > should only support ReadFile/WriteFile. if we want to go into this, there are a few points to agree on first: - since console handles can be inherited, the Wine console window should be run in a different process than the one which uses the console (and add communication means between the first process, and the process rendering the console) - how should we know a program needs either a simple or a complex console (we could use a registry key in the per process area) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

1 0

Re: (no subject)
by Alexandre Julliard 22 Aug '01

22 Aug '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > How about returning a function pointer instead of an id? > > When the file handle is registered with the wine-server, we would also > send function pointers for the read and write operations. This way we > could have seperate implementations of ReadFile or WriteFile for > different types of handles... You can't do that. The ReadFile can be done from another process, and the pointer won't be valid there. -- Alexandre Julliard julliard(a)winehq.com

1 0

(no subject)
by Mike McCormack 22 Aug '01

22 Aug '01

Hi Eric, How about returning a function pointer instead of an id? When the file handle is registered with the wine-server, we would also send function pointers for the read and write operations. This way we could have seperate implementations of ReadFile or WriteFile for different types of handles... Mike > - extend the get_handle_fd to also return an id corresponding > to the type fd being used. ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: documentation make fix
by Mike McCormack 21 Aug '01

21 Aug '01

Yeah, that looks better, and seems to work too. thanks, Mike Original message from: Francois Gouget <fgouget(a)free.fr> > >On Tue, 21 Aug 2001, Mike McCormack wrote: > >> >> Not that anybody uses the documentation anyway... :-) >> >> ChangeLog: >> * recurse all directories when making docs. >> Don't fail if C_SRCS is empty. > > Maybe the attached patch would be a better way to do this: > - use the regular make trick for recursing > - test whether we have targets before entering the for loop > > Note that I did not really test it. > > > Well, I have done a little testing now. And c2man is not happy if you >don't create documentation/man3w beforehand... > So I added an mkdir too, same for doc-html. > > >-- >Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > "Utilisateur" (nom commun) : > Mot utilis� par les informaticiens en lieu et place d'"idiot". ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Re: reaktivate
by Malte Starostik 21 Aug '01

21 Aug '01

Am Montag, 20. August 2001 08:59 schrieb Per Wigren: > I get this when I'm trying to load an Active-X component in konqueror: > > konqueror: /usr/lib/libreaktivate: could not load library > '/usr/lib/libreaktivate.so' as Winelib application: > /usr/X11R6/lib/libXv.so.1: undefined symbol: XGetErrorDatabaseText > > Any ideas what to do? Using cvs from today of both wine and reaktivate. Never seen that one before, but it's IMHO rather a wine problem. Has anyone seen this before? Or, did you by any chance update some but not all X libraries? -- Malte Starostik PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787]

1 0

Re: ReadFile and other issues
by Alexandre Julliard 21 Aug '01

21 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > no, reading of input_records would be sone as it is today, with > the specific console request 'read_console_input' OK, we agree then. > the only thing we'd have to have is another request to get the fd from > a console input handle (get_handle_fd would no longer work), and we > still need a (background) mechanism to convert the unix xterm characters > into INPUT_RECORD (a get_console_fd should do). Anyway, those fd are > even rather static (they only change on Alloc|Free Console and at > process startup if we inherit them from parent), so we can savely keep > them around, process wide I'm not sure we should be converting xterm input into INPUT_RECORD. It may be better to have two modes, a simple console that returns an fd to ReadFile and no input records (and then ReadConsoleInput could generate them on the fly if necessary), and a complex console that supports all the features but that doesn't have an associated fd at all. IMO the current xterm-based console support is a ugly hack; we should do a proper Windows console using a normal Wine window with a message loop to retrieve input events. And usage of stdin/stdout should be limited to programs that don't need special console features, and should only support ReadFile/WriteFile. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: ReadFile and other issues
by Alexandre Julliard 21 Aug '01

21 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > to implement properly this (mainly the ability to forward ReadFile calls > to ReadConsole for console handles), I'd like to do the following: > - extend the get_handle_fd to also return an id corresponding to the > type fd being used. As of today, handle / fd relationship mainly > assumes that we can map a Windows operation on a handle onto a similar > operation on a unix fd. The ReadFile/ReadConsoleInput doesn't fit in > this category. I'm not sure I understand you right; are you suggesting that get_handle_fd should return an fd from which you can read input records in the case of a console? It would seem preferable to have get_handle_fd simply fail with a special error code saying that the handle is a console, and then ReadFile can fall back to using ReadConsoleInput which doesn't require an fd at all. > - this type of feature would help in other areas too. For example, we > never check that Comm functions really get a Comm handle... Well, we check by the fact that we then do a serial ioctl on the fd, which will fail if it isn't serial. I'm not sure we need more checks. -- Alexandre Julliard julliard(a)winehq.com

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel