Alexandre Julliard 641ee76ace Release 970804
Sun Aug  3 14:03:43 1997  Alexandre Julliard  <julliard@lrc.epfl.ch>

	* [documentation/Makefile.in]
	Create links for files included from wine.texinfo.

	* [wine.man]
	Moved to documentation dir.

	* [if1632/builtin.c]
	Made SYSTEM.DLL always loaded by default.

	* [loader/signal.c] [if1632/signal.c]
	Split signal.c in generic/emulator-specific parts.

	* [misc/system.c] [if1632/thunk.c]
	Implemented system timer functions.
	Fixed InquireSystem parameters.

	* [msdos/ioports.c]
	Defined inb/outb functions to avoid including asm/io.h.
	Use the right instruction for word and dword direct access.

	* [multimedia/mmsystem.c]
	Fixed CallTo16 usage.

Sat Aug 2 13:05:23 1997  Andreas Mohr <100.30936@germany.net>

	* [controls/edit.c]
	When text is inserted into a newly created editline, the caret
	is placed after the text. Should be placed before the text. Fixed.

	* [files/file.c]
	Removed O_TRUNC flag from OF_WRITE mode in _lopen32().
	According to doc _lopen() never truncates files.

	* [if1632/user.spec] [misc/comm.c]
	Added stub for EnableCommNotification().

	* [misc/ver.c]
	Fixed problem with VerQueryValue*() running over end of name table
	in rare cases.

	* [msdos/int21.c]
	Enhanced ioctlGetDeviceInfo() to correctly return the current drive.

	* [multimedia/joystick.c] [windows/message.c]
	Added joystick support !!!
	Needs Linux >= 2.1.45 or joystick-0.8.0.tar.gz.

Fri Aug  1 18:02:09 1997  Morten Welinder  <terra@diku.dk>

	* [if1632/user32.spec]
	Define DrawAnimatedRects32.

	* [graphics/painting.c]
	(DrawAnimatedRects32): Create stub.

	* [misc/registry.c]
	Cope with NULL class in RegQueryInfoKey32A.

	* [if1632/user32.spec]
	Add GetMenuItemInfo32[AW].

	* [controls/menu.c]
	(InsertMenu32A): Upgrade flags to 8 hex-digits.
	(MENUEX_ParseResource): First shot at implementation.
	(LoadMenuIndirect32A): Handle extended menus.
	(GetMenuItemInfo32[AW]): First shot at implementation.

	* [include/windows.h]
	Define MFT_*, MFS_*, MIIM_* macros.  Define MENUITEMINFO[AW]
 	structures and pointers.

	* [Makefile.in]
	(etags): Add TAGS as target.

	* [if1632/comctl32.spec]
	Use Windows 95's ordinals.  Add a few missing stubs.

Thu Jul 31 14:01:13 1997  Marcus Meissner <msmeissn@cip.informatik.uni-erlangen.de>

	* [objects/color.c]
	Fix for 16 color mode of XFree.

	* [if1632/kernel32.spec][win32/ordinals.c]
	Moved/added some ordinal only exported functions from kernel32.dll
	(mostly thunking preparation stuff).

Wed Jul 30 09:16:38 1997  John Harvey <john@division.co.uk>

	* [graphics/win16drv/init.c] [include/win16drv.h]
        Escape(SETABORTPROC) returns success to keep pbrush.exe happy.
        Escape(NEXTBAND) implemented to make HP PCL printer driver work in
 	word.  Stub for PATBLT added to start work on printing more than
 	text.

Mon Jul 28 13:14:28 1997  Victor Schneider <vischne@ibm.net>

	* [libtest/expand.c]
	New Winelib test program.

Wed Jul 23 09:37:13 1997  Adrian Harvey <adrian@select.com.au>

	* [tools/build.c] [tools/build-spec.txt] [if1632/kernel.spec]
	  [if1632/user.spec]
	Added ability to set filename wine considers the built-in DLLs 
	to be in  to something other than name.DLL with new "file" key
	in .spec files.
	Made kernel filename KRNL386.EXE (some programs use this name 
	explicitly - ChemOffice install now starts up).
	Made user filename USER.EXE (just to be tidy).

Sun Jul 20 23:51:02 1997  David A. Cuthbert <dacut@henry.ece.cmu.edu>

	* [controls/menu.c] [misc/tweak.c] [include/tweak.h]
	Fixed MENU_KeyLeft and MENU_KeyRight to handle multiple-column
	menus.  Misc menu drawing issues for Win95 tweaks fixed.  Misc
	warnings fixed.

	* [loader/module.c]
	Spaces are now permitted in file/path names on the command line.
	If multiple matches can be made, the preferred match is the
	path/file with fewer spaces.

Tue Jul 29 02:21:15 1997  Bruce Milner <Bruce.Milner@genetics.utah.edu>

	* [misc/compobj.c]
	Added CLSIDFromString and StringFromCLSID.
1997-08-04 16:34:36 +00:00
..
1995-12-26 15:05:24 +00:00
1997-03-05 08:22:35 +00:00
1996-12-08 19:25:27 +00:00
1997-08-04 16:34:36 +00:00
1995-12-26 15:05:24 +00:00
1997-06-16 17:43:53 +00:00
1997-01-01 17:29:55 +00:00

This is a short discussion of resources in WineLib.

Introduction
Resources are used to store dialogs, menus, bitmaps, icons, 
version information, strings, fonts, and accelerators.
In a Win3.1 programming environment, there are three file formats for 
resources:
- the RC script, which is human-readable and can be processed by a resource
compiler
- the .RES file, which is the output of the resource compiler
- the .EXE and .DLL files, which store resources as a part of the NE
file format
For WineLib, only a part of this is supported. In particular, there is no
.RES file, the executable is not a NE file (as it is a native Unix executable),
and some resource types are not implemented: icons, version information,
strings, and fonts.

Building a WineLib application
The build process assumes that the C source files and the resource script
is available. At the moment, a single resource script is recommended.
This script is processed by winerc:
1) the preprocessor is used to resolve symbolic style name (LBS_STANDARD, ...)
into numbers. This involves processing windows.h
2) the unused parts of windows.h (type definitions) are removed. This would
not be necessary if Wine's windows.h would use the RC_INVOKED macro.
3) winerc is invoked to create a binary representation of the resources.
This representation is stored as C source code (arrays).
4) gcc is used to compile the generated C code.
Now, each resource is available as a C array to the application. As the 
executable is not in the NE format, it is not possible to retrieve resource
locations in the executable via name. Instead, the resources have to be
referenced with their generated C array names. The linker then resolves
these names in the compiled resource file.
5) The program sources are compiled and linked with the output of step 4.
A sample build process is in toolkit/Makefile:hello3.

Required changes to the program sources
Because loading the resources from an instance handle is not possible,
the *Indirect functions have to be used to load a resource. The C arrays
can be directly passed to the *Indirect functions. So, instead of writing

	hMenu=LoadMenu(hInstance,"MAIN");

write

	hMenu=LoadMenuIndirect(hello3_MENU_MAIN.bytes);

Fortunately, the Windows API has the following functions available:
DialogBoxIndirect
CreateDialogIndirect
DialogBoxIndirectParam
CreateDialogIndirectParam

LoadMenuIndirect
SetDIBitsToDevice

Sample code is available in hello3.c. hello3res.c contains the corresponding
resources.

Keeping a common source
Clearly, changing the sources is not very desirable, and suggestions how
to reduce the amount of work are welcome. In the meantime, two approaches
allow at least to remain a common source between the Win3.1 code and the
WineLib code:
1) conditional compiles:
When compiling a WineLib application, WINELIB is defined. This can be used
to select Wine-specific code.
2) usage of winerc for Windows: The *Indirect functions are available on
plain Win3.1, and the resource format is fully compatible. Thus, recompiling
sources modified for WineLib on Win3.1 is possible and known to work.

Open problems
1) Icons and cursors: For these resources, there is no *Indirect function
documented. In addition, both are implemented by a set of two resources.
This is the reason why they are not supported by winerc.
2) Accelerators: Although winerc supports accelerators, there is no 
LoadAcceleratorIndirect function. A work-around would be to define one.
3) Fonts: Font resources are not supported by Wine at all.
4) String tables: Although string tables are not supported by winerc, there
is no reason not to add such support. Again, some indirect loading would
be necessary.
5) API requires loading by name: At some places, the name of a resource
is passed instead of a handle. The WNDCLASS structure contains the name
of a menu resource, and the icon in a dialog box is referenced by its name.
(Are there some more places?)
Clearly, loading the resource by name would be highly desirable. The
resource compiler currently creates a structure containing all resources
defined in an RC file. However, it is not clear how WINELIB could find the
location of this structure, especially, when there is more than one RC file.