wine-devel August 2001

wine-devel@winehq.org

62 participants
189 discussions

Re: _CheckNotSysLevel()
by Alexandre Julliard 23 Aug '01

23 Aug '01

Daniel Walker <diwalker(a)earthlink.net> writes: > It seems Wise installers break inside _CheckNotSysLevel() . I think > every Wise installer I've tried breaks .. The cuteftp package was one of > them .. How about posting a backtrace? -- Alexandre Julliard julliard(a)winehq.com

3 4

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

23 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > anyway, I'd like to get back to simple vs complex consoles if I got > you right, a simple console handle should be in fact nothing more > than a regular file handle which unix fd is set to either 0 or 1 it > means that no enhanced mode is used, nothing but the standard libc > line editing facilities of the input stream so the use would > adequate for a simple program that just uses equivalent of puts/gets > (and associated) functions Exactly yes. > however, I find this very limiting for people who want to use a CUI > exe in a pure unix console mode (either when X11 isn't started, or a > session done over IP in telnet for example) that's why I was > wondering if wineconsole shouldn't also support a (n)curse like > interface (in addition to the USER32 one) to help in this area Sure, once the architecture is in place we can have different implementations of wineconsole, including curses support. The important thing is that this is in a separate application, so that ReadConsole doesn't need to know about things like xterm escape sequences. > last but not least, recent exchanges made a simple < 1kloc patch a more > serious project of several kloc :-/ I can do the wineserver part if you like. -- Alexandre Julliard julliard(a)winehq.com

2 1

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

23 Aug '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > well, the issue here is that, even in line editing mode, ReadConsole > and ReadConsoleInput can be used. the former drops all non keyboard > events and produces a string, whereas the later returns the available > input records... > so, to implement what you propose, the wineconsole would have to know > in advance which one of the two functions will be called next: > - in case of ReadConsole, it has to keep all incoming input records, and > release just the string when it's done editing the line > - in case of ReadConsoleInput, all generated input records must be > available in the server to the calling app OK I see what you mean. Yes this implies that we must be able to tell the server to only return input events to the thread doing the ReadConsole. If I get this right, it also means line editing has to be done in ReadConsole, and that you can't see what you type when the app is not reading. Very annoying, but I guess it's more Windows-like... -- Alexandre Julliard julliard(a)winehq.com

2 1

_CheckNotSysLevel()
by Daniel Walker 23 Aug '01

23 Aug '01

It seems Wise installers break inside _CheckNotSysLevel() . I think every Wise installer I've tried breaks .. The cuteftp package was one of them .. Daniel Walker

1 0

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

← Newer
1
2
3
4
5
6
7
8
...
19
Older →

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 August 2001