77b9918e0e
Thu Sep 11 18:24:56 1997 Philippe De Muyter <phdm@info.ucl.ac.be> * [objects/dc.c] In DC_SetupGCForPatBlt, replace R2_NOT by GXxor with (black xor white). Tue Sep 9 23:04:02 1997 U. Bonnes <bon@elektron.ikp.physik.th-darmstadt.de> * [memory/virtual.c] Do not write debugging info unconditionally to stderr. * [files/profile.c] Call PROFILE_GetSection in PROFILE_GetString for key_name "" too. * [misc/crtdll.c] Many new functions. * [include/windows.h] [windows/winpos.c] ClientToScreen16 doesn't have a return value. Sun Sep 7 10:06:39 1997 Alexandre Julliard <julliard@lrc.epfl.ch> * [misc/main.c] [AUTHORS] Update the list of contributors. Please let me know if I forgot someone. * [if1632/*.spec] [if1632/builtin.c] [tools/build.c] Ordinal base for Win32 DLLs is now computed automatically from the lowest ordinal found. * [include/wintypes.h] WINAPI is now defined as attribute((stdcall)). This will require gcc to compile. * [if1632/thunk.c] Removed Win32 thunks (no longer needed with stdcall). * [if1632/crtdll.spec] [misc/crtdll.c] Make sure we only reference cdecl functions in the spec file. * [objects/dc.c] Use CapNotLast drawing style for 1-pixel wide lines. * [tools/build.c] Added 'double' argument type. Added 'varargs' function type for Win32. Made CallTo16_xxx functions stdcall. Fri Sep 5 14:50:49 1997 Alex Korobka <alex@trantor.pharm.sunysb.edu> * [tools/build.c] [windows/win.c] [windows/event.c] [windows/message.c] More fixes to get message exchange closer to the original. * [misc/spy.c] Message logs now contain window names. * [loader/resource.c] [loader/ne_resource.c] [loader/task.c] [objects/cursoricon.c] [windows/user.c] Added some obscure features to fix memory leaks. Fri Sep 5 00:46:28 1997 Jan Willamowius <jan@janhh.shnet.org> * [if1632/kernel32.spec] [win32/newfns.c] Added stub for UTRegister() and UTUnRegister(). Thu Sep 4 12:03:12 1997 Frans van Dorsselaer <dorssel@rulhmpc49.LeidenUniv.nl> * [controls/edit.c] Allow ASCII codes > 127 in WM_CHAR. Mon Sep 1 17:23:24 1997 Dimitrie O. Paun <dimi@mail.cs.toronto.edu> * [controls/widgets.c] In InitCommonControls, remember the name of the class because lpszClassName was made to point to a local array Added the ProgressBar to the list of implemented controls. Call InitCommonControls from WIDGETS_Init to register all implemented Common Controls. * [include/commctrl.h] Added misc decl for the Progress Bar. * [controls/progress.c] [include/progress.h] First attempt at implementiong the Progress Bar class. * [objects/brush.h] Implementation for GetSysColorBrush[16|32] * [controls/status.c] Use DrawEdge to draw the borders and fill the background * [controls/uitools.c] Added DrawDiagEdge32 and DrawRectEdge32 * [graphics/painting.c] Implement DrawEdge[16|32] Started DrawFrameControl32 Mon Sep 1 10:07:09 1997 Lawson Whitney <lawson_whitney@juno.com> * [misc/comm.c] [include/windows.h] SetCommEventMask returns a SEGPTR. Sun Aug 31 23:28:32 1997 Marcus Meissner <msmeissn@cip.informatik.uni-erlangen.de> * [loader/pe_image.c][loader/module.c][include/pe_image.h] [include/module.h] Cleaned up the whole Win32 library mess (a bit). * [debugger/stabs.c] If 'wine' has no absolute path and isn't found, check $PATH too. * [misc/ole2nls.c] Some fixes. * [misc/ver.c] Added support for PE style version resources. * [memory/string.c] Check for NULL pointers to _lstr* functions, just as Windows95 does. * [multimedia/time.c] Made list of timers a simple linked list. * [loader/resource.c] Netscape 3 seems to pass NEGATIVE resource Ids (in an unsigned int, yes). Don't know why, fixed it anyway. * [objects/bitmap.c] LoadImageW added. * [include/win.h][windows/win.c] Change wIDmenu from UINT16 to UINT32 and changed the SetWindow(Long|Word) accordingly. Thu Aug 28 19:30:08 1997 Morten Welinder <terra@diku.dk> * [include/windows.h] Add a few more colors defined for Win95. Add a few more brush styles. * [windows/syscolor.c] Add error checks for SYSCOLOR_SetColor, SYSCOLOR_Init, GetSysColor16, GetSysColor32. Add support for above colors. Sun Aug 24 16:22:57 1997 Andrew Taylor <andrew@riscan.com> * [multimedia/mmsystem.c] Changed mmioDescend to use mmio functions for file I/O, neccessary for memory files.
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.