On February 3, 2003 05:25 am, Tom Wickline wrote:
-- dosmod : Deleted as of Jan 2001.
-- fnt2bdf : Discussed on Wine-Devel ( practically obsolete )
Are you deleting these from the guide?
@ progman : A program Manager for WINE.
Why not: A Program Manager replacement.
@ regedit : A command-line tool to edit your registry or for important a windows registry to Wine.
What about: A Registry Editor replacement.
@ regsvr32 : A program to register/unregister .DLL's and .OCX files. Only works on those dlls that can self-register.
I'd just delete the second sentence. It does not matter for the purpose of the guide.
@ uninstaller: A program to uninstall installed Windows programs. Like the Add/Remove Program in the windows control panel.
@ wcmd : Wine's command line interpreter a cmd.exe replacement.
Maybe a comma is needed after interpreter.
@ widl : Wine IDL compiler compiles (MS-RPC and DCOM) Interface Definition Language files (into something useful for compiling Wine and Winelib apps, similar to wmc and wrc). Should also be able to generate typelibs (someday).
I'd keep just the first part, up to the (into something...
- wine : The main Wine executable. This program will load a Windows
binary and run it, relying upon the Wine shared object libraries.
# wineboot : This program is executed on startup of the first wine process of a particular user. wineboot won't automatically run when needed. Currently you have to manually run it after you install something. A list of what it currently does.
* wininit.ini processing * registry RenameFiles entries * RunServices* / RunOnce* / Run registry keys
Get rid of A list of ....
-- winebootup : Now wineboot......
I hope this goes away.
@ wineconsole : The purpose of wineconsole is to render the output of CUI programs it does so either thru a window (called the USER32 backend) or by using an existing unix shell (called the curses backend) the first backend is triggered when the app programmatically opens a console (AllocConsole) the second one is triggered on startup by using wineconsole myapp.exe instead of wine myapp.exe on the command line
This is far too long for the packager's guide. Just say: A console replacement. It is used to render the output of CUI programs.
@ winedump : Dumps the imports and exports of NE and PE (Portable Executable) files. DLL (included in wine tree).
I'd get rid of "DLL (included in wine tree)."
- winelauncher : A wine wrapper shell script that intelligently handles
wine invocation by informing the user about what's going on, among other things. To be found in tools/ directory. Use of this wrapper script instead of directly using wine is strongly encouraged, as it not only improves the user interface, but also adds important functionality to wine, such as session bootup/startup actions. If you intend to use this script, then you might want to rename the wine executable to e.g. wine.bin and winelauncher to wine. the WINECONFDIR/config file.
Way too long of a description, compared to all others. Besides, this script will go away soon (I hope). Maybe we shouldn't even document it.
@ winemaker : Winemaker is a perl script which is designed to help you bootstrap the conversion of your Windows projects to Winelib. In order to do thisit will go analyze your code, fixing the issues listed above and generate autoconf-based Makefiles.
thisit == this, it
@ winepath : A tool for converting between Windows paths and Unix paths (useful for shell scripts ans such).
ans = and
-- winesetup : This is a Tcl/Tk based front end that provides a user friendly tool to edit and configure the WINECONFDIR/config file.
Is this going away?
@ winhelp : When Windows (at least 3.0, but it may well have appeared in 2.0) was launched, a help system was designed. Help information is stored in .hlp files, and was viewed with winhelp.exe (16 bit application). When Windows 95 was launched, the same help system still existed (even it grew in complexity), and help was viewed by a 32 bit application (winhlp32.exe). Those help files (.hlp) are in fact generated by a specific build system, starting from RTF files, with some very styles to define the specific portions (pages, links...). When an application requires a specific help page to be displayed, it calls an API (WinHelp), specifying the name of the help file, and a information about what needs to be displayed (hence the context sensitive help). When the Internet wave was clear to the MS folks, they moved the help system architecture to HTML files (replacing the RTF sources). That are the .CHM files (basically, compressed HTML files and their embedded information - images, metafiles...), which are normally displayed by an OCX (which basically decompress the right files and ask IWebBrowser to display them).hh.exe (which is now the .CHM viewer) is just a wrapper to that OCX.
Why soooo long?
Why not: A Windows Help replacement.
Just like progman, winemine, etc.