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. -- Dimi.
