Text mode programs are program which output is only made out of text (surprise!). In Windows terminology, they are called CUI (Console User Interface) executables, by opposition to GUI (Graphical User Interface) executables. Win32 API provide a complete set of APIs to handle this situation, which goes from basic features like text printing, up to high level functionalities (like full screen editing, color support, cursor motion, mouse support), going through features like line editing or raw/cooked input stream support
Given the wide scope of features above, and the current usage in Un*x world, Wine comes out with three different ways for running a console program (aka a CUI executable):
wineconsole with user backend
wineconsole with curses backend
The names here are a bit obscure. "bare streams" means that no extra support of wine is provide to map between the unix console access and Windows console access. The two other ways require the use of a specific Wine program (wineconsole) which provide extended facilities. The following table describes what you can do (and cannot do) with those three ways.
Table 3-1. Basic differences in consoles
|Function||Bare streams||Wineconsole & user backend||Wineconsole & curses backend|
|How to run (assuming executable is called foo.exe)|
$ wine foo.exe
$ wineconsole -- --backend=user foo.exe
$ wineconsole foo.exeYou can also use --backend=curses as an option
|Good support for line oriented CUI applications (which print information line after line)||Yes||Yes||Yes|
|Good support for full screen CUI applications (including but not limited to color support, mouse support...)||No||Yes||Yes|
|Can be run even if X11 is not running||Yes||No||Yes|
|Implementation||Maps the standard Windows streams to the standard Unix streams (stdin/stdout/stderr)||Wineconsole will create a new Window (hence requiring the USER32 DLL is available) where all information will be displayed||Wineconsole will use existing unix console (from which the program is run) and with the help of the (n)curses library take control of all the terminal surface for interacting with the user|
|Known limitations||Will produce strange behavior if two (or more) Windows consoles are used on the same Un*x terminal.|
When wineconsole is used, several configuration options are available. Wine (as Windows do) stores, on a per application basis, several options in the registry. This let a user, for example, define the default screen-buffer size he would like to have for a given application.
As of today, only the USER backend allows you to edit those options (we don't recommend editing by hand the registry contents). This edition is fired when a user right click in the console (this popups a menu), where you can either choose from:
Default: this will edit the settings shared by all applications which haven't been configured yet. So, when an application is first run (on your machine, under your account) in wineconsole, wineconsole will inherit this default settings for the application. Afterwards, the application will have its own settings, that you'll be able to modify at your will.
Properties: this will edit the application's settings. When you're done, with the edition, you'll be prompted whether you want to:
Keep these modified settings only for this session (next time you run the application, you will not see the modification you've just made).
Use the settings for this session and save them as well, so that next you run your application, you'll use these new settings again.
Here's the list of the items you can configure, and their meanings:
Table 3-2. Wineconsole configuration options
|Cursor's size||Defines the size of the cursor. Three options are available: small (33% of character height), medium (66%) and large (100%)|
|Popup menu||It's been said earlier that wineconsole configuration popup was triggered using a right click in the console's window. However, this can be an issue when the application you run inside wineconsole expects the right click events to be sent to it. By ticking control or shift you select additional modifiers on the right click for opening the popup. For example, ticking shift will send events to the application when you right click the window without shift being hold down, and open the window when you right-click while shift being hold down.|
|Quick edit||This tick box lets you decide whether left-click mouse events shall be interpreted as events to be sent to the underlying application (tick off) or as a selection of rectangular part of the screen to be later on copied onto the clipboard (tick on).|
|History||This lets you pick up how many commands you want the console to recall. You can also drive whether you want, when entering several times the same command - potentially intertwined with others - whether you want to store all of them (tick off) or only the last one (tick on).|
|Police||The Police property sheet allows you to pick the default font for the console (font file, size, background and foreground color).|
|Screenbuffer & window size||The console as you see it is made of two different parts. On one hand there's the screenbuffer which contains all the information your application puts on the screen, and the window which displays a given area of this screen buffer. Note that the window is always smaller or of the same size than the screen buffer. Having a strictly smaller window size will put on scrollbars on the window so that you can see the whole screenbuffer's content.|
|Close on exit||If it's ticked, then the wineconsole will exit when the application within terminates. Otherwise, it'll remain opened until the user manually closes it: this allows seeing the latest information of a program after it has terminated.|
|Edition mode|| |
When the user enter commands, he or she can choose between several edition modes: