![]() Mon Dec 11 19:08:55 1995 Alexandre Julliard <julliard@sunsite.unc.edu> * [misc/lstr.c] Replaced wine_strncpy() by a 32-bit version of lstrcpyn(), since they do the same job. * [tools/build.c] Fixed __attribute__((stdcall)) to make it compile with gcc versions under 2.7. Doesn't mean it will run OK though... Sat Dec 09 13:22:58 1995 Cameron Heide <heide@ee.ualberta.ca> * [include/kernel32.h] [include/winerror.h] Added file attribute definitions and more error codes. * [win32/error.c] Added some rudimentary errno-to-Win32 error conversion code. * [win32/file.c] Added to GetFileInformationByHandle, filled in some known error codes, and switched to dprintf_win32. * [win32/time.c] Added GetLocalTime. Fri Dec 8 14:37:39 1995 Jim Peterson <jspeter@birch.ee.vt.edu> * [controls/combo.c] Converted functions of the type LONG _(HWND,WORD,LONG) to the type LRESULT _(HWND,WPARAM,LPARAM) where needed. * [include/libres.h] Restructured libres prototypes to closer match the windows API. * [include/windows.h] Changed several API prototypes' parameter types from 'short' to INT, which is #defined as short in the emulator, but is a normal int in WINELIB32. Also changed SEGPTR from DWORD to void* when WINELIB32. (This creates a lot of warnings at library-compile time, but less warnings at app-compile time. I'll remove the warnings soon.) * [loader/resource.c] Fixed parameter mismatch in call to LIBRES_FindResource(). Changed various implementations of the LIBRES_* API functions. * [loader/signal.c] Deleted local 'i' from win_fault(), since it was unused. * [objects/bitblt.c] Mirrored changes to include/windows.h mentioned above. * [toolkit/hello3.c] Changed LoadMenuIndirect() call to LoadMenu() to test the new resource registration technique. * [toolkit/libres.c] Removed definition of 'struct resource' and fixed bugs in the resource implementation. Implemented LIBRES_FindResource. * [windows/graphics.c] Mirrored changes to include/windows.h mentioned above. Thu Dec 7 23:15:56 1995 Martin von Loewis <loewis@informatik.hu-berlin.de> * [controls/edit.c] LOCAL_HeapExists: Changed parameter to HANDLE. For WineLib, return true * [controls/listbox.c] CreateListBoxStruct: Initialize HeapSel to 0 for WineLib * [include/listbox.h] change HeapSel from WORD to HANDLE * [include/resource.h][rc/winerc.c] struct ResourceTable: removed struct resource: moved to header file autoregister resources if supported by compiler * [memory/local.h] LOCAL_GetHeap: expect HANDLE rather than WORD * [toolkit/Makefile.in] Add ALLCFLAGS to make hello3 * [toolkit/heap.c] LocalFree, HEAP_Free: handle 0 parameter gracefully Wed Dec 06 15:34:23 1995 Greg Cooper <cooper@ima-inc.com> * [misc/winsocket.c] Fixed the msgsnd and msgrcv errors that winsock programs get. Wed Dec 06 12:47:23 MET 1995 Sven Verdoolaege <skimo@dns.ufsia.ac.be> * [if1632/kernel.spec] Fixed _hread and _hwrite return type * [if1632/relay32.c] [loader/pe_image.c] Hacked loading of PE-dll's in * [win32/advapi.c] Added stubs for RegCreateKeyEx, RegSetValueEx, RegQueryValueEx * [win32/file.c] Added stubs for OpenFileMapping, CreateFileMapping, MapViewOfFileEx * [win32/process.c] Added stubs for CreateMutexA, ReleaseMutex, CreateEventA, WaitForSingleObject, DuplicateHandle, GetCurrentProcess Mon Dec 04 13:06:37 1995 Bernd Schmidt <crux@pool.informatik.rwth-aachen.de> * [include/wine.h] [misc/lstr.c] Define wine_strncpy(). This function does not pad the buffer with zeroes like GNU strncpy(), which might break some Windows programs that pass bogus size arguments. * [loader/module.c]: GetModuleFileName(), [misc/commdlg.c]: GetFileTitle(), [misc/keyboard.c], [misc/lstr.c]: lstrcpyn(), [misc/ole2nls.c], [misc/profile.c], [multimedia/mcistring.c], [multimedia/mmsystem.c], [objects/font.c]: Use wine_strncpy() where strings are returned to Windows programs. * [objects/metafile.c] PlayMetafile(): Clear the handle table before using it. * [misc/shell.c] [misc/main.c] Rename SHELL_RegCheckForRoot() to SHELL_Init() and call it from main(). * [misc/profile.c] load(): Need to handle comments. * [toolkit/libres.c] Make it compile. * [windows/nonclient.c] Use MAKE_SEGPTR macro in two places where a user heap block used to be allocated instead. Sat Dec 02 16:43:43 1995 Ramon Garcia <ramon@ie3.clubs.etsit.upm.es> * [windows/winpos.c] In function SetWindowPos: do not redraw the parent of a window if the specified window is placed on the top. This avoids that ShowWindow(hwnd,1) hides hwnd instead of showing it. Sat Dec 02 11:00:00 1995 Alex Korobka <alex@phm30.pharm.sunysb.edu> * [windows/scroll.c] Now it can scroll children along with the client region of parent window. Tried to optimize update region calculation. * [windows/mdi.c] ScrollChildren function, more other features added. Basically a rewrite. * [windows/winpos.c] [windows/focus.c] Reimplemented window activation and focus handling. * [windows/nonclient.c] Added new flag WIN_NCACTIVATED. * [windows/message.c] [loader/task.c] Small changes (to maintain linked list of message queues). Wed Nov 29 15:51:48 1995 Daniel Schepler <daniel@shep13.wustl.edu> * [include/options.h] [misc/main.c] [windows/defwnd.c] [windows/event.c] [windows/nonclient.c] [windows/win.c] [Wine.man] Implemented a -managed option to replace the standard Windows frame of top-level windows with the window manager's decorations. If a top-level window makes its own frame, this will still show up, inside the window manager decorations (I believe ctl3dv2.dll would do this, although I can't test this). |
||
---|---|---|
.. | ||
Makefile.in | ||
README.libres | ||
README.resources | ||
arch.c | ||
atom.c | ||
heap.c | ||
hello.c | ||
hello2.c | ||
hello3.c | ||
hello3res.rc | ||
libres.c | ||
miscstubs.c | ||
sup.c | ||
winmain.c |
README.resources
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.