Wine Definitions take #3 -final ?

[Dimitrie O. Paun]

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.