Re: Why is EXW Win 3.1 application ?
This is a multi-part message in MIME format.
------=_NextPart_000_0007_01C196C5.08F3BE80
charset="iso-8859-2"
Rob Craig writes:
> Martin Stachon writes:
> > I changed the version
> > by changing offsets #000000C8 to #000000CA :
> > from #03000A (3.10) to #040000 (4.0)
> > (In unpacked exw) Now Windows treat exw as
> > 4.0 application. I don't know about WATCOM,
> > but I guess you can tell it to set the version.
>
> Thanks. I'll experiment with that to see if it causes
> any problems. I have version 10.6 (pretty old) of Watcom installed.
> Maybe that's why the version number is old. I don't think
> there's a linker option for it.
I've done a short observation with my 4.0 exw,
and the differences are the same as between
interpreted/borland compiled code.
A few of them I found :
- ComboBox has 3D look
- some windows also now have 3D look (see wstyles.exw)
- also some windows invoked by eu program are 3D
(Dialup networking etc.)
- some combination of style flags for window
results in quite different window look (see IDE - Form Design window)
- SizePointer (=IDC_SIZE) doesn't work (easy fix - change it to IDC_SIZEALL)
Some other thing may also stop work in programs which wrongly
uses some Win 3.1 feature. When interpreter has 3.1 flag,
Windows tolarate it, but with 4.0 flag, they don't accept it.
But I'am not aware of any such programs, and it is always
easy to fix - the differences are documented and there
is always nearly the same function or constant in WIN32 API
for 4.0. The authors could experience the difference
already when translating to C.
For all interesded, I attached a txt file containing
part of MS docs describing all the differences.
Martin
------=_NextPart_000_0007_01C196C5.08F3BE80
Content-Type: text/plain;
name="16-32 diff.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="16-32 diff.txt"
Taken from Programmer's Guide to Microsoft=AE Windows=AE 95
=A9 1995 - 1996 Microsoft Corporation. All rights reserved.
Window Management Differences
-----------------------------
When a version 4.0 application uses the SetWindowLong function (with =
GWL_STYLE) to change a window's style, Windows 95 sends the window a =
WM_STYLECHANGING message before changing the style. The message's lParam =
parameter is the address of a STYLESTRUCT structure. The styleOld and =
styleNew members of the structure specify the old and new styles. By =
processing WM_STYLECHANGING, an application can inspect the styles and =
perhaps change them.=20
Windows 95 sends the WM_STYLECHANGED message after changing the style. =
Again, the lParam parameter is the address of a STYLESTRUCT structure =
that specifies the new styles. The application can use WM_STYLECHANGED =
to update any style-dependent information stored in the application's =
internal data structures.
Windows 95, however, does not send the WM_STYLECHANGING and =
WM_STYLECHANGED messages to a version 3.x application.=20
A version 4.0 application cannot use the SetWindowLong function to set =
the WS_EX_TOPMOST style for a window or to remove the style from a =
window. The application must use the SetWindowPos function to set or =
remove the WS_EX_TOPMOST style.
Windows 95 automatically adds and removes the WS_EX_WINDOWEDGE style for =
windows in both version 3.x and 4.0 applications. In a version 3.x =
application, Windows 95 adds the WS_EX_WINDOWEDGE style to a window if, =
in version 3.1, the window would have a dialog border or a sizable =
border. Windows 95 removes the WS_EX_WINDOWEDGE style if the window's =
style changes so that it would no longer have a dialog border or sizable =
border in version 3.1. Windows 95 uses similar criteria for adding and =
removing the WS_EX_WINDOWEDGE style for a Windows version 4.0 =
application, except that any window that has a title bar receives the =
WS_EX_WINDOWEDGE style, regardless of the window's other border styles.=20
When the user drags the icon of a minimized window created by a version =
3.x application, Windows 95 sends the window a WM_QUERYDRAGICON message =
to retrieve the cursor to use while dragging. Windows 95 also sends =
WM_QUERYDRAGICON to retrieve the icon to display in the task-switch =
window that appears when the user presses the ALT+TAB key combination. =
Windows 95 does not send WM_QUERYDRAGICON to a window created by a =
version 4.0 application. Instead, the application is expected either to =
use the WM_SETICON and WM_GETICON messages or to set the big and small =
icons when registering the window class.=20
When a window in a version 4.0 application loses the mouse capture as a =
result of a call to the SetCapture function, the window receives a =
WM_CAPTURECHANGED message, but Windows 95 sends the message =
asynchronously. In other words, the window receives the message, but =
possibly not right away. Some of the ways in which a window can lose the =
mouse capture include:=20
=B7 The user activated a different application by clicking one of its =
windows.
=B7 The DefWindowProc function changed the capture in response to a =
WM_CANCELMODE message.
=B7 Another window using the same message queue called the SetCapture =
function. (All 16-bit applications share the same queue, but each 32-bit =
thread has its own queue.)
=20
If a child window in a version 3.x application has the =
WS_EX_NOPARENTNOTIFY style, Windows 95 disregards the style when the =
user clicks the child window. That is, Windows 95 sends the =
WM_PARENTNOTIFY message to all windows in the parent chain regardless of =
whether the child window has the WS_EX_NOPARENTNOTIFY style. If a child =
window in a version 4.0 application has this style, Windows 95 does not =
send WM_PARENTNOTIFY messages when the user clicks the child window.
In a version 3.x application, it is possible for the horizontal =
coordinate on the left side of a window's client area to be greater than =
that on the right side. This happens because version 3.x sometimes =
incorrectly handles an empty client rectangle that contains a vertical =
scroll bar. (Fixing the problem would cause some applications to =
generate general protection faults.) In a version 4.0 application, it is =
not possible for the horizontal coordinate of the left side of a client =
area to be greater than that of the right side.=20
Dialog Box Differences
-----------------------------
A dialog box created by a version 4.0 application automatically receives =
the DS_3DLOOK style. This style gives three-dimensional borders to child =
controls in the dialog box and draws the entire dialog box using the =
three-dimensional color scheme. The DS_3DLOOK style is available to a =
dialog box created by a version 3.x application, but you must explicitly =
add the style to the dialog box template. The application that creates =
the dialog box determines the version number of the dialog box.
Windows 95 performs a strict validation check on the DS_ styles =
specified in a dialog box template. If the template contains any styles =
that Windows 95 does not recognize and a version 4.0 application is =
creating the dialog box, the creation fails. If a version 3.x =
application is creating the dialog box, the system debugger generates a =
warning, but Windows 95 creates the dialog box anyway.=20
Button Differences
-----------------------------
The parent window of a button (except push buttons) in a version 3.x =
application receives a WM_CTLCOLORBTN message when the button is about =
to be drawn. In a version 4.0 application, however, the parent window of =
a button receives the WM_CTLCOLORSTATIC message, which retrieves a color =
appropriate for drawing text on the background of the dialog box. =
Windows 95 sends WM_CTLCOLORSTATIC to retrieve the background and text =
colors for the text area of check boxes, radio buttons, and group =
buttons. An application should process WM_CTLCOLORSTATIC in order to =
correctly set the colors of any dialog box item that contains text and =
appears directly on the dialog area.=20
Windows 95 performs default handling of the WM_CTLCOLORBTN message =
differently depending on an application's version. For a version 3.x =
application, the default handling for button colors is to use the =
COLOR_WINDOW value for the background color and the COLOR_WINDOWTEXT =
value for the foreground color. For a version 4.0 application, Windows =
95 uses the COLOR_3DFACE value for the background and the COLOR_BTNTEXT =
value for the foreground.
In a version 3.x application, a push button's outer top left corner is =
nonwhite because the button is typically drawn on a white background. If =
the border was white, the background would appear to bleed into the =
button. In a version 4.0 application, a push button's outer top left =
corner is white (COLOR_3DHILIGHT) because the button is typically drawn =
on a nonwhite background (COLOR_3DFACE).=20
Edit Control Differences
-----------------------------
In a version 3.x application, an edit control that is the descendant of =
an inactive window takes the input focus when the user clicks the =
control; an edit control in a version 4.0 application does not. Not =
taking the input focus prevents the situation where the user can enter =
text into what appears to be an inactive window.=20
An edit control in a version 3.x application retrieves its text and =
background colors by sending the WM_CTLCOLOREDIT message to its parent =
window. In a version 4.0 application, an edit control sends the =
WM_CTLCOLOREDIT or WM_CTLCOLORSTATIC message. The edit control sends =
WM_CTLCOLORSTATIC if it is disabled or read-only; otherwise, it sends =
WM_CTLCOLOREDIT. In addition, a disabled multiline edit control in a =
version 4.0 application uses the COLOR_GRAYTEXT value as its text color. =
A multiline edit control in a version 4.0 application has a proportional =
scroll box (thumb), but a multiline edit control in a version 3.x =
application does not.=20
In a version 3.x application, the wParam parameter of the EM_REPLACESEL =
message is not used. In a version 4.0 application, the wParam parameter =
is a flag that specifies whether the replacement operation can be =
undone.
List Box Differences
-----------------------------
In a version 4.0 application, a list box that is part of a combo box =
uses the WM_CAPTURECHANGED notification message to hide its drop-down =
list if it is open. For more information, see "Combo Boxes" later in =
this topic.
The DDL_EXCLUSIVE flag of the DlgDirList function does not have the =
expected result in a version 3.x application. Specifically, the flag =
does not exclude read-write files from the list. In a version 4.0 =
application, the DDL_EXCLUSIVE flag excludes read-write files.=20
If a list box in a version 3.x application has either the WS_HSCROLL or =
WS_VSCROLL style, the list box receives both horizontal and vertical =
scroll bars. Although one of the scroll bars is typically hidden, =
Windows 95 displays the hidden scroll bar if its scrolling range becomes =
greater than zero. In a version 4.0 application, a list box does not =
receive a horizontal scroll bar, unless it has the WS_HSCROLL style. =
Likewise, it does not receive a vertical scroll bar unless it has the =
WS_VSCROLL style.
When creating a list box in a version 3.x application, Windows 95 always =
increases the size of the list box by adding the border width to each =
side. This is done because Windows 95 assumes that the dimensions =
specified by the application or the dialog template are for the client =
area of the list box. Unfortunately, increasing the size in this way =
makes aligning a list box rather difficult. Windows 95 does not increase =
the size when creating a list box in a version 4.0 application; Windows =
95 assumes that the specified size includes the borders.=20
Combo Box Differences
-----------------------------
A combo box in a version 4.0 application passes the control color =
messages (WM_CTLCOLOR*) from its child components (edit control and list =
box) to the parent window of the combo box. In a version 3.x =
application, a combo box passes those messages to the DefWindowProc =
function.
A combo box in a version 4.0 application uses the WM_CAPTURECHANGED =
message to hide its drop-down list box if it is open. Windows 95 sends =
the message when another window takes the mouse capture, which typically =
happens when the user clicks another window. In a version 3.x =
application, a combo box does not use WM_CAPTURECHANGED to hide the =
drop-down list.=20
A combo box in a version 3.x application uses the WM_CTLCOLORLISTBOX =
message to retrieve the text and background colors. In a version 4.0 =
application, a combo box uses the WM_CTLCOLOREDIT or WM_CTLCOLORSTATIC =
message instead. The combo box uses WM_CTLCOLORSTATIC if it is disabled =
or contains a read-only selection field (in an edit control); otherwise, =
it uses WM_CTLCOLOREDIT.=20
In a version 3.x application, the background of the static text area in =
read-only combo boxes is filled with the system highlight color =
(COLOR_HILIGHT). In a version 4.0 application, Windows 95 fills the =
background of the static text area only for a combo box that is not =
owner drawn.
In a version 4.0 application, Windows 95 adds the ODS_COMBOBOXEDIT value =
to the itemState member of the DRAWITEMSTRUCT structure when Windows 95 =
sends the WM_DRAWITEM message to the parent window of an owner-drawn =
combo box to draw an item in the selection field. The ODS_COMBOBOXEDIT =
value tells the parent window that the drawing takes place in the =
selection field of the combo box rather than in the list box.=20
Menu Differences
-----------------------------
A 16-bit version 3.x application that creates or loads a menu is =
considered to be the owner of the menu. However, when the application =
exits, the menu is "orphaned" until no 16-bit version components for =
Windows version 3.x remain. For 16-bit version 4.0 applications and all =
32-bit applications, the application that creates the menu is the owner, =
and the menu is destroyed as soon as the application exits. Unlike =
graphics device interface (GDI) objects, there is no way to change the =
ownership of a menu.
In a version 3.x application, the Close command cannot be deleted from =
the System menu of an multiple document interface (MDI) child window. In =
a version 4.0 application, the Close command can be deleted.
Windows 95 increases the width of hierarchical, owner-drawn menu items =
in a version 3.x application. Some applications rely on this increased =
width and use it to include icons that simulate toolbars. In a version =
4.0 application, Windows 95 does not automatically increase the width of =
hierarchical, owner-drawn menu items.
The wParam parameter of the WM_MENUSELECT message is interpreted =
differently depending on the subsystem version number of the application =
and whether the application is written for 16 or 32 bits:
=B7 In a 16-bit version 3.x application, the wParam parameter is the =
handle of the pop-up menu if the selected item activates a pop-up menu.
=B7 In a 16-bit version 4.0 application, wParam is the identifier of the =
menu item, regardless of whether the item activates a pop-up menu.=20
=B7 In a 32-bit application (both subsystem versions), the low-order =
word of wParam is the identifier of the menu item or, if the item =
activates a pop-up menu, the index of the pop-up menu. This high-order =
word contains the menu flags.
System Bitmap and Color Differences
-----------------------------
In 16-bit version 3.x applications, purpose windows, such as dialog =
boxes, message boxes, and system-defined control windows, receive =
WM_CTLCOLOR messages when they are about to be drawn. The high-order =
word of the lParam parameter indicates the type of special purpose =
window about to be drawn (CTLCOLOR_BTN, CTLCOLOR_EDIT, and so on). By =
default, a special purpose window passes the WM_CTLCOLOR message to the =
parent or owner window (for both subsystem versions), allowing the =
parent or owner to set the foreground and background colors of the =
special purpose window. The same is true for 32-bit applications, except =
that the special purpose window receives one or more of the following =
messages instead of WM_CTLCOLOR.
WM_CTLCOLORBTN
WM_CTLCOLORDLG
WM_CTLCOLOREDIT
WM_CTLCOLORLISTBOX WM_CTLCOLORMSGBOX
WM_CTLCOLORSCROLLBAR
WM_CTLCOLORSTATIC
=20
In 32-bit applications, the message itself indicates the type of special =
purpose window about to be drawn. The lParam parameter contains the =
window's 32-bit handle.=20
Display drivers for Windows version 3.x provide the bitmaps, icons, and =
cursors used by previous versions of Windows. Because Windows 95 renders =
and scales the system bitmaps, icons, and cursors itself, its display =
drivers do not (and should not) contain any OBM_, OIC_, or OCR_ =
resources.=20
For a version 3.x application, the default handling of the =
WM_CTLCOLORSTATIC and WM_CTLCOLORDLG messages is to use the COLOR_WINDOW =
value for the background and the COLOR_WINDOWTEXT value for the =
foreground. For a version 4.0 application, Windows 95 uses the =
COLOR_3DFACE value for the background and the COLOR_WINDOWTEXT value for =
the foreground.
When an application calls the GetClientRect function to retrieve the =
client rectangle of a minimized window created by a version 3.x =
application, Windows 95 retrieves the old dimensions for a minimized =
window (0, 0, 36, 36). For a minimized window in a version 3.1 or 4.0 =
application, Windows 95 retrieves 0, 0, =
GetSystemMetrics(SM_CXMINIMIZED), GetSystemMetrics(SM_CYMINIMIZED). =
These metrics change if the user changes the title bar height or =
minimized window width by using Control Panel. In other words, the =
GetClientRect function returns the dimensions of the entire minimized =
window, preventing an application from causing a general protection (GP) =
fault because of an unexpectedly empty client rectangle.
System Metrics Differences
-----------------------------
When a version 3.x application calls the GetSystemMetrics function to =
retrieve the SM_CYVSCROLL or SM_CYHSCROLL metric value, the function =
returns a value that is one pixel more than the actual height of the =
corresponding type of standard scroll bar. Windows 95 adds a pixel =
because applications written for previous versions of windows routinely =
subtract one pixel from the return value. Subtracting one pixel accounts =
for the way a standard scroll bar in a version 3.x application overlaps =
the border of the window in which it resides. A version 4.0 application =
receives the actual height of the scroll bar.
When a version 3.x application retrieves the SM_CXDLGFRAME and =
SM_CYDLGFRAME system metric values, GetSystemMetrics returns a value =
that is one pixel less that the actual frame width or height. A version =
4.0 application receives the actual width or height.
GetSystemMetrics returns one pixel more than the actual height of a =
title bar when a version 3.x application requests the SM_CYCAPTION =
system metric value. A version 4.0 application receives the actual =
height of the title bar.=20
GetSystemMetrics returns one pixel less than the actual height of a menu =
bar when a version 3.x application requests the SM_CYMENU system metric =
value. A version 4.0 application receives the actual height of the menu =
bar.
When a version 3.x application calls GetSystemMetrics to retrieve the =
SM_CYFULLSCREEN value (height of a maximized window's client area), the =
function returns a value that is one pixel less than the actual height. =
This is because GetSystemMetrics returns one pixel more than the actual =
title bar height when an application retrieves the SM_CYCAPTION value. =
(The sum of the height of a maximized window's client area and the =
height of a title bar must equal the height of the working area of the =
screen.) A version 4.0 application receives the actual height of the =
maximized window's client area when it requests the SM_CYFULLSCREEN =
value.=20
Parameter Validation Differences
-----------------------------
If a 32-bit version 3.x application specifies invalid class styles when =
calling the RegisterClass function, Windows 95 strips out the invalid =
bits and generates warnings in the system debugger, but allows =
RegisterClass to succeed anyway. If a 32-bit version 4.0 application =
passes invalid class styles to RegisterClass, the function fails.=20
In a version 3.x application, Windows 95 does not validate the length =
member of the WINDOWPLACEMENT structure that is passed to the =
GetWindowPlacement and SetWindowPlacement functions. The length member, =
however, is validated for a version 4.0 application; Windows 95 fails =
these functions if the value of length is incorrect.
Windows 95 does not validate the cbSize member of the STARTUPINFO =
structure specified in the CreateProcess and GetStartupInfo functions =
for applications written for Windows version 3.x. The cbSize member is =
validated, however, for version 4.0 applications.
In the debugging version of Windows 95, the system fills the specified =
buffer with zeros up to the length specified by the cbSize parameter =
when a version 4.0 application calls the LoadString function. The buffer =
is not filled with zeros for a version 3.x application.
------=_NextPart_000_0007_01C196C5.08F3BE80--
|
Not Categorized, Please Help
|
|
