Integrally closed domain: Difference between revisions
en>TakuyaMurata →Noetherian integrally closed domain: non-noetherian case |
en>Monkbot |
||
Line 1: | Line 1: | ||
{{multiple issues|notability=December 2011|refimprove=December 2011|technical=February 2009}} | |||
'''Make Compatible''' is a program developed by [[Microsoft]] that is included with [[Windows 9x]] [[operating system]]s. It changes per-program system settings in Windows to allow [[Windows 3.1]] programs that are tailored specifically to that platform to execute under newer versions. The name of the program image file for Make Compatible is <tt>mkcompat.exe</tt>, and it is stored in the <tt>\Windows\System</tt> directory.<ref name=OReilly>{{cite book|title=Windows 98 in a Nutshell|author=Tim O'Reilly, Troy Mott, and Walter J. Glenn|chapter=Make Compatible|publisher=O'Reilly|date=1999|isbn=978-1-56592-486-4|pages=227–228}}</ref><ref>{{cite book|title=A+ Certification: (Exams 220-221, 220-222)|author=Charles J. Brooks|edition=4|publisher=Que|date=2002|isbn=978-0-7897-2844-9|pages=799}}</ref> | |||
==Options== | |||
When it is invoked, one can choose the name of the Windows 3.1 application program image file using the "Choose Program" option on the "File" menu. After the program image file is chosen, Make Compatible by default displays a list of five options that can be set to alter the behaviour of Windows for that program when it is executed:<ref name=OReilly /> | |||
*Don't spool to enhanced [[Windows Metafile|meta file]]s<ref name=OReilly /> | |||
*Give application more stack space<ref name=OReilly /> | |||
*Lie about printer device mode size<ref name=OReilly /> | |||
*Lie about Windows version number<ref name=OReilly /> | |||
*Windows 3.1-style controls<ref name=OReilly /> | |||
An advanced options mode, selectable via the "Advanced Options" selection on the "File" menu presents a longer list of options, allowing finer control of Windows 3.1 emulation if the particular application requires it.<ref name=OReilly /> | |||
==Compatibility bits== | |||
Each of the options is recorded in a system database of so-called "compatibility bits". This is a database of 1-bit flags, one for each of the options displayed by Make Compatible.<ref name=Petrusha>{{cite web|title=Where Am I Running?|author=Ron Petrusha|date=1 August 1999|publisher=O'Reilly Media, Inc.|work=windowsdevcenter.com|url=http://windowsdevcenter.com./pub/a/oreilly/windows/news/versions_0899.html}}</ref><ref name=BottLeonhard>{{cite paper|title=95 Only Undocumented Secrets|author=Ed Bott and Woody Leonhard|chapter=Running Older Apps|url=http://www.empowermentzone.com/w95undoc.txt|publisher=Ziff-Davis Publishing Company}}</ref> | |||
This database already existed in earlier versions of Windows. In Windows 3.1, the database is stored in the <tt><nowiki>[Compatibility]</nowiki><tt> section of <tt>[[win.ini]]</tt>, with entries such as:<ref name=Petrusha /><ref name=BottLeonhard /> | |||
:<source lang="INI" enclose=div> | |||
[Compatibility] | |||
ACAD=0x8000 | |||
AMIPRO=0x04000010 | |||
</source> | |||
Each line names an application program, and gives a hexadecimal numeric constant to associate with that program. The hexadecimal numeric constant encodes the compatibility bitflags for that particular application, that Windows applies when the application is executed. Make Compatible merely provides a [[graphical user interface]] for editing these flags in an easy way, rather than editing <tt>win.ini</tt> manually, with a text editor. It allows one to set and unset individual flags without having to know their numeric values.<ref name=Petrusha /><ref name=BottLeonhard /> | |||
The compatibility bitflags settable in <tt>win.ini</tt> are not documented in the <tt>WININI.WRI</tt> file that ships with Windows 3.1, or in the ''Microsoft Windows 3.1 Resource Kit'' published by Microsoft. They are listed as a simple set of defined constants (with names beginning "GACF_" for "GetAppCompatFlags"), without explanation, in the <tt>windows.h</tt> [[header file]] that is shipped with the Microsoft Windows 3.1 Device driver Development Kit. In Windows 3.1, the compatibility flags that are in effect for any given task in the kernel's Task Database are readable via the undocumented <code>GetAppCompatFlags()</code> function that is exported from the <tt>KERNEL</tt> module.<ref name=SchulmanMaxeyPietrek>{{cite book|pages=244–250|chapter=KERNEL: Windows system services|author=Andrew Schulman, David Maxey, and Matt Pietrek|isbn=0-201-60834-0|publisher=Addison-Wesley|date=1992|title=Undocumented Windows}}</ref> | |||
==Advanced mode flags== | |||
The flags are documented in Microsoft KnowledgeBase article #82860. They correspond to the "advanced mode" flags that are settable by Make Compatible's "Advanced Options" menu:<ref name=SchulmanMaxeyPietrek /> | |||
;30 average width metrics:This is bit #19 of the compatibility bits word, with hexadecimal value <code>0x80000</code>, known by the symbolic name <code>GACF_30AVGWIDTH</code> in <tt>windows.h</tt>. This flag causes Windows to re-scale all fonts by a factor of <math>7/8</math> when calculating their average character widths. The reason for this is that one particular Windows 3.0 application, [[TurboTax]], hard-coded the values that it was using for such size calculations, which failed to work correctly with the new [[TrueType]]-compatible font average width calculation method employed by Windows 3.1. This prevented people from using TurboTax to print their [[income tax]] return forms on [[PostScript]] printers.<ref name=SchulmanMaxeyPietrek /> | |||
;Always send NC_Paint:This is bit #6 of the compatibility bits word, with hexadecimal value <code>0x40</code>, known by the symbolic name <code>GACF_ALWAYSSENDNCPAINT</code> in <tt>windows.h</tt>. This flag forces any call to <code>SetWindowPos()</code> to cause the sending of <code>WM_NCPAINT</code> message to all child windows. This is the Windows 3.0 behaviour. In Windows 3.1, the behaviour was changed so that the window message is only sent to those windows that need their non-client areas to be repainted. Some Windows 3.0 applications, however, relied upon always receiving this message, to determine whether child windows needed repositioning.<ref name=SchulmanMaxeyPietrek /> | |||
;Don't enum device fonts:This is bit #14 of the compatibility bits word, with hexadecimal value <code>0x4000</code>, known by the symbolic name <code>GACF_ENUMTTNOTEDEVICE</code> in <tt>windows.h</tt>. This flag causes Windows 3.1 to turn the <code>DEVICE_FONTTYPE</code> flag off in particular circumstances when an application that is wanting to print enumerates fonts. The particular circumstances are when the target printer is not either a [[dot matrix printer]] or a PostScript printer, and the fonts are TrueType fonts that are not resident in the printer itself. In such circumstances, some applications (including [[PageMaker]] and [[MGXDraw]]) misinterpret the flag and believe the font to be device-resident. (TrueType fonts can be uploaded by Windows to printers, and need not be resident on the device itself to be usable.) They then query the printer to see what sizes of the font it supports, and when that fails (because the printer doesn't know about the font until it is uploaded), they incorrectly assume that the font cannot be resized. Setting the <code>DEVICE_FONTTYPE</code> flag to false in such situations prevents the applications from going wrong, and that is what this compatibility bitflag does.<ref name=SchulmanMaxeyPietrek /> | |||
;Don't send calcsize <code>WM_MOVE</code>:This is bit #17 of the compatibility bits word, with hexadecimal value <code>0x20000</code>, known by the symbolic name <code>GACF_NCCALCSIZEONMOVE</code> in <tt>windows.h</tt>. This flag forces the <code>WM_NCCALCSIZE</code> message to be sent to a window that is being moved or resized. This is the Windows 3.0 behaviour. In Windows 3.1, the behaviour was changed so that the window message is only sent to those windows that were being resized. It was not sent if the window was merely moved. Some Windows 3.0 applications, however, such as [[Lotus Notes]] for example, relied upon always receiving this message.<ref name=SchulmanMaxeyPietrek /> | |||
;Enum Helv and Times Roman fonts:This is bit #12 of the compatibility bits word, with hexadecimal value <code>0x1000</code>, known by the symbolic name <code>GACF_ENUMHELVTMSRMN</code> in <tt>windows.h</tt>. This flag works around a problem with applications that refused to work properly unless fonts with the exact names "Helv" and "Tms Rmn" were listed as present on the system by the Windows font enumeration API. The names are trademarks of [[Mergenthaler Linotype Company|Linotype company]] for particular fonts, [[Helvetica]] and [[Times Roman]], and since Microsoft didn't ship those Linotype fonts with Windows 3.1, it could not enumerate them as present. This flag causes Windows to enumerate the "MS Sans Serif" and "MS Serif" fonts under the names "Helv" and "Tms Rmn", for compatibility with the applications that don't work without those exact names being used.<ref name=SchulmanMaxeyPietrek /> | |||
;Force extra windows words:This is bit #8 of the compatibility bits word, with hexadecimal value <code>0x100</code>, known by the symbolic name <code>GACF_MOREEXTRAWNDWORDS</code> in <tt>windows.h</tt>. This flag works around a problem with applications that assumed the existence of window words (extra items of data associated by Windows with GUI windows) when they had not in fact informed Windows that extra window words were required. Windows 3.1, unlike Windows 3.0, [[bounds checking|bounds check]]s all uses of extra window words, and applications that assumed that they could use more space than they had asked for would thus fail. For applications run with this flag set, Windows 3.1 silently increased the total number of words requested by the application by an extra 4 bytes.<ref name=SchulmanMaxeyPietrek /> | |||
;Force printer text to new band:This is bit #1 of the compatibility bits word, with hexadecimal value <code>0x2</code>, known by the symbolic name <code>GACF_FORCETEXTBAND</code> in <tt>windows.h</tt>. This flag causes Windows 3.1 to always use two bands when printing, the first for graphics and the second for text. Normally Windows 3.1 tries to print both in a single band. But applications such as WordPerfect assumed that a second band would always exist, and would always be where the text was, as had been the case in Windows 3.0. Freelance Graphics had a similar problem.<ref name=SchulmanMaxeyPietrek /> | |||
;Force TT fonts to graphics band:This is bit #15 of the compatibility bits word, with hexadecimal value <code>0x8000</code>, known by the symbolic name <code>GACF_FORCETTGRAPHICS</code> in <tt>windows.h</tt>. This flag was to work around a problem with [[Freelance Graphics]], where it wouldn't print using TrueType fonts unless they were printed as graphics.<ref name=SchulmanMaxeyPietrek /> | |||
;Global hooks only called for Win16 apps: | |||
;Ignore discardable segment attributes:This is bit #0 of the compatibility bits word, with hexadecimal value <code>0x1</code>, known by the symbolic name <code>GACF_IGNORENODISCARD</code> in <tt>windows.h</tt>. This flag forces the <code>GEM_NODISCARD</code> flag passed to <code>GlobalAlloc()</code> by a program to be ignored. It worked around a bug in the run-time library supplied with Microsoft's own [[C (programming language)|C]] compiler, [[Microsoft C]] version 6. The run-time library would erroneously set that flag in calls to <code>GlobalAlloc()</code>, and any application compiled with that compiler would thus exhibit the behaviour.<ref name=SchulmanMaxeyPietrek /> | |||
;Ignore raster fonts:This is bit #9 of the compatibility bits word, with hexadecimal value <code>0x200</code>, known by the symbolic name <code>GACF_TTIGNORERASTERDUPE</code> in <tt>windows.h</tt>. This flag prevents fonts of the same sizes from being enumerated as both bitmap and TrueType fonts. This was because several applications, including [[WordPerfect]] and [[Visual Basic]], were not capable of handling that particular situation correctly.<ref name=SchulmanMaxeyPietrek /> | |||
;Ignore topmost windows:This is bit #3 of the compatibility bits word, with hexadecimal value <code>0x8</code>, known by the symbolic name <code>GACF_IGNORETOPMOST</code> in <tt>windows.h</tt>. This flag fixes a particular problem with [[cc:Mail]] that caused it to fail on Windows 3.1. It assumed that accessing the first window with <code>GetWindow(HWND,GW_HWND_FIRST)</code> would return it the window of the application that it had just started with <code>WinExec()</code>. But on Windows 3.1, which introduced the idea of "topmost" windows, this was no longer true. The flag caused Windows 3.1 to skip topmost windows when that particular API request was made.<ref name=SchulmanMaxeyPietrek /> | |||
;Module specific hack: | |||
;No HRGN 1:This is bit #16 of the compatibility bits word, with hexadecimal value <code>0x10000</code>, known by the symbolic name <code>GACF_NOHRGN1</code> in <tt>windows.h</tt>. This flag reinstates a bug that existed in Windows 3.0 that was fixed in Windows 3.1. It did so because several applications, such as [[Microsoft Draw]], worked around the bug themselves, and would fail to work correctly when the bug was eliminated. The bug was an error in the return value of the <code>GetUpdateRect()</code> function, whereby in certain situations (where the entire window was invalid) it would return the coördinates of the update rectangle in window coördinates, rather than in logical coördinates as it was supposed to. In Windows 3.1, it always returned the update rectangle in logical coördinates. The applications that worked around the bug would perform the coördinate transform themselves to work around the bug, and end up updating the wrong parts of their windows on Windows 3.1.<ref name=SchulmanMaxeyPietrek /> | |||
;One graphic band and use print escapes:This is bit #2 of the compatibility bits word, with hexadecimal value <code>0x4</code>, known by the symbolic name <code>GACF_ONELANDGRXBAND</code> in <tt>windows.h</tt>. This flag causes Windows 3.1 to use a single graphics band when printing in [[Landscape mode]], consuming as much memory as needed for that band, and discarding whatever content would not fit into the band.<ref name=SchulmanMaxeyPietrek /> | |||
;Subtract clip siblings:This is bit #14 of the compatibility bits word, with hexadecimal value <code>0x4000</code>, known by the symbolic name <code>GACF_SUBTRACTCLIPSIBS</code> in <tt>windows.h</tt>. This flag causes Windows 3.1 to handle window invalidation differently for top-level windows that do not have the <code>WS_CLIPSIBLINGS</code> window style set, and their chlid windows. (In other words: It affects dialogue boxes and the controls on them.) With the flag set, Windows would not invalidate sibling child windows underneath (in the [[z-order]]) other <code>WS_CLIPSIBLINGS</code> child windows. The main reason for the flag was applications such as Lotus Notes 2.1, which implemented its own [[combo box]]es as child windows, rather than as top-level windows (the system default combo box implementation). With this flag set, odd display problems with such windows would disappear.<ref name=SchulmanMaxeyPietrek /> | |||
;Support multiple printing bands:This is bit #5 of the compatibility bits word, with hexadecimal value <code>0x20</code>, known by the symbolic name <code>GACF_MULTIPLEBANDS</code> in <tt>windows.h</tt>. This flag causes Windows 3.1 to always use multiple bands for printing, even when one band would be sufficient. This was to work around a problem in Freelance Graphics, which would assume that if only one band existed, and it was the entire page, it was the text band, and would not even attempt to print graphics. On Windows 3.1, the universal printer driver would sometimes be able to handle both text and graphics with a single band. By forcing the use of multiple bands, the problems that this would cause for Freelance Graphics were avoided.<ref name=SchulmanMaxeyPietrek /> | |||
;TT fonts are device fonts:This is bit #4 of the compatibility bits word, with hexadecimal value <code>0x10</code>, known by the symbolic name <code>GACF_CALLTTDEVICE</code> in <tt>windows.h</tt>. This flag causes Windows 3.1 to always set the <code>DEVICE_FONTTYPE</code> flag on any TrueType fonts that are enumerated using the Windows <code>EnumFont()</code> API. This was to fix a problem with applications including [[AmiPro]] and WordPerfect, both of which assumed that all TrueType fonts available on a printer would be device-resident.<ref name=SchulmanMaxeyPietrek /> | |||
;Windows 3.1 palette behavior: | |||
==Additional flags== | |||
Windows 3.1 defined 20 application compatibility flags.<ref name=SchulmanMaxeyPietrek /> Windows 95 and 98 defined a further 11 flags, not documented in the KnowledgeBase article and not assigned symbolic constant names in <tt>windows.h</tt>, which are the remainder of the options accessible via the "Advanced Options" menu in Make Compatible:<ref>{{cite paper|url=http://fadedtwilight.org./Content/mkcompat.txt|title=Windows' 16-bit Program Compatibility Hacks|author=Rick Coogle|accessdate=10 February 2009}}</ref> | |||
;Disable 16 color brush cache and 55ms timer:This is bit #29 of the compatibility bits word, with hexadecimal value <code>0x20000000</code>. | |||
;Disable EMF spooling:This is bit #26 of the compatibility bits word, with hexadecimal value <code>0x4000000</code>. | |||
;Disable font associations:This is bit #24 of the compatibility bits word, with hexadecimal value <code>0x1000000</code>. | |||
;Don't attach input thread when journaling, <code>SetActiveWindow</code> == <code>SetForeGroundWindow</code>:This is bit #28 of the compatibility bits word, with hexadecimal value <code>0x10000000</code>. | |||
;Don't Shutdown/Ignore certain faults/dequote commandline:This is bit #25 of the compatibility bits word, with hexadecimal value <code>0x2000000</code>. | |||
;Enable 3.x UI features:This is bit #27 of the compatibility bits word, with hexadecimal value <code>0x8000000</code>. | |||
;Force Win31 printer dev mode size:This is bit #23 of the compatibility bits word, with hexadecimal value <code>0x800000</code>. | |||
;Increase stack size:This is bit #22 of the compatibility bits word, with hexadecimal value <code>0x400000</code>. | |||
;Lie about device caps/no <code>SetDIBits</code> validation:This is bit #20 of the compatibility bits word, with hexadecimal value <code>0x100000</code>. | |||
;Lie about windows version:This is bit #21 of the compatibility bits word, with hexadecimal value <code>0x200000</code>. | |||
;Mirror fonts in <tt>win.ini</tt>:This is bit #30 of the compatibility bits word, with hexadecimal value <code>0x40000000</code>. | |||
== References == | |||
{{reflist}} | |||
== Further reading == | |||
* {{cite book|title=Microsoft Windows 95 Resource Kit|publisher=Microsoft Press|date=1995|isbn=978-1-55615-678-6|pages=718 et seq.}} | |||
* {{cite news|title=MKCOMPAT Makes Old Programs Behave|date=July 1997|volume=8|issue=7|work=Smart Computing|publisher=Sandhills Publishing Company|url=http://smartcomputing.com./editorial/article.asp?article=articles%2F1997%2Fjul97%2F073197%2F073197.asp}} | |||
* {{cite paper|id=KBID 173086|title=How to Use Mkcompat.exe for Windows 3.1-Based Programs|date=20 January 2007|version=1.2|publisher=[[Microsoft]]|work=Microsoft KnowledgeBase|url=http://support.microsoft.com/kb/173086}} | |||
* {{cite paper|id=KBID 82860|title=The WIN.INI <nowiki>[Compatibility]</nowiki> Section|date=25 December 2000|version=1.0|publisher=[[Microsoft]]|work=Microsoft KnowledgeBase|url=http://support.microsoft.com/kb/82860}} | |||
{{Microsoft}} | |||
[[Category:Windows 95]] | |||
[[Category:Windows components]] | |||
[[Category:Computer configuration]] |
Revision as of 02:04, 22 January 2014
Template:Multiple issues Make Compatible is a program developed by Microsoft that is included with Windows 9x operating systems. It changes per-program system settings in Windows to allow Windows 3.1 programs that are tailored specifically to that platform to execute under newer versions. The name of the program image file for Make Compatible is mkcompat.exe, and it is stored in the \Windows\System directory.[1][2]
Options
When it is invoked, one can choose the name of the Windows 3.1 application program image file using the "Choose Program" option on the "File" menu. After the program image file is chosen, Make Compatible by default displays a list of five options that can be set to alter the behaviour of Windows for that program when it is executed:[1]
- Don't spool to enhanced meta files[1]
- Give application more stack space[1]
- Lie about printer device mode size[1]
- Lie about Windows version number[1]
- Windows 3.1-style controls[1]
An advanced options mode, selectable via the "Advanced Options" selection on the "File" menu presents a longer list of options, allowing finer control of Windows 3.1 emulation if the particular application requires it.[1]
Compatibility bits
Each of the options is recorded in a system database of so-called "compatibility bits". This is a database of 1-bit flags, one for each of the options displayed by Make Compatible.[3][4]
This database already existed in earlier versions of Windows. In Windows 3.1, the database is stored in the [Compatibility] section of win.ini, with entries such as:[3][4]
[Compatibility] ACAD=0x8000 AMIPRO=0x04000010
Each line names an application program, and gives a hexadecimal numeric constant to associate with that program. The hexadecimal numeric constant encodes the compatibility bitflags for that particular application, that Windows applies when the application is executed. Make Compatible merely provides a graphical user interface for editing these flags in an easy way, rather than editing win.ini manually, with a text editor. It allows one to set and unset individual flags without having to know their numeric values.[3][4]
The compatibility bitflags settable in win.ini are not documented in the WININI.WRI file that ships with Windows 3.1, or in the Microsoft Windows 3.1 Resource Kit published by Microsoft. They are listed as a simple set of defined constants (with names beginning "GACF_" for "GetAppCompatFlags"), without explanation, in the windows.h header file that is shipped with the Microsoft Windows 3.1 Device driver Development Kit. In Windows 3.1, the compatibility flags that are in effect for any given task in the kernel's Task Database are readable via the undocumented GetAppCompatFlags()
function that is exported from the KERNEL module.[5]
Advanced mode flags
The flags are documented in Microsoft KnowledgeBase article #82860. They correspond to the "advanced mode" flags that are settable by Make Compatible's "Advanced Options" menu:[5]
- 30 average width metrics
- This is bit #19 of the compatibility bits word, with hexadecimal value
0x80000
, known by the symbolic nameGACF_30AVGWIDTH
in windows.h. This flag causes Windows to re-scale all fonts by a factor of when calculating their average character widths. The reason for this is that one particular Windows 3.0 application, TurboTax, hard-coded the values that it was using for such size calculations, which failed to work correctly with the new TrueType-compatible font average width calculation method employed by Windows 3.1. This prevented people from using TurboTax to print their income tax return forms on PostScript printers.[5] - Always send NC_Paint
- This is bit #6 of the compatibility bits word, with hexadecimal value
0x40
, known by the symbolic nameGACF_ALWAYSSENDNCPAINT
in windows.h. This flag forces any call toSetWindowPos()
to cause the sending ofWM_NCPAINT
message to all child windows. This is the Windows 3.0 behaviour. In Windows 3.1, the behaviour was changed so that the window message is only sent to those windows that need their non-client areas to be repainted. Some Windows 3.0 applications, however, relied upon always receiving this message, to determine whether child windows needed repositioning.[5] - Don't enum device fonts
- This is bit #14 of the compatibility bits word, with hexadecimal value
0x4000
, known by the symbolic nameGACF_ENUMTTNOTEDEVICE
in windows.h. This flag causes Windows 3.1 to turn theDEVICE_FONTTYPE
flag off in particular circumstances when an application that is wanting to print enumerates fonts. The particular circumstances are when the target printer is not either a dot matrix printer or a PostScript printer, and the fonts are TrueType fonts that are not resident in the printer itself. In such circumstances, some applications (including PageMaker and MGXDraw) misinterpret the flag and believe the font to be device-resident. (TrueType fonts can be uploaded by Windows to printers, and need not be resident on the device itself to be usable.) They then query the printer to see what sizes of the font it supports, and when that fails (because the printer doesn't know about the font until it is uploaded), they incorrectly assume that the font cannot be resized. Setting theDEVICE_FONTTYPE
flag to false in such situations prevents the applications from going wrong, and that is what this compatibility bitflag does.[5] - Don't send calcsize
WM_MOVE
- This is bit #17 of the compatibility bits word, with hexadecimal value
0x20000
, known by the symbolic nameGACF_NCCALCSIZEONMOVE
in windows.h. This flag forces theWM_NCCALCSIZE
message to be sent to a window that is being moved or resized. This is the Windows 3.0 behaviour. In Windows 3.1, the behaviour was changed so that the window message is only sent to those windows that were being resized. It was not sent if the window was merely moved. Some Windows 3.0 applications, however, such as Lotus Notes for example, relied upon always receiving this message.[5] - Enum Helv and Times Roman fonts
- This is bit #12 of the compatibility bits word, with hexadecimal value
0x1000
, known by the symbolic nameGACF_ENUMHELVTMSRMN
in windows.h. This flag works around a problem with applications that refused to work properly unless fonts with the exact names "Helv" and "Tms Rmn" were listed as present on the system by the Windows font enumeration API. The names are trademarks of Linotype company for particular fonts, Helvetica and Times Roman, and since Microsoft didn't ship those Linotype fonts with Windows 3.1, it could not enumerate them as present. This flag causes Windows to enumerate the "MS Sans Serif" and "MS Serif" fonts under the names "Helv" and "Tms Rmn", for compatibility with the applications that don't work without those exact names being used.[5] - Force extra windows words
- This is bit #8 of the compatibility bits word, with hexadecimal value
0x100
, known by the symbolic nameGACF_MOREEXTRAWNDWORDS
in windows.h. This flag works around a problem with applications that assumed the existence of window words (extra items of data associated by Windows with GUI windows) when they had not in fact informed Windows that extra window words were required. Windows 3.1, unlike Windows 3.0, bounds checks all uses of extra window words, and applications that assumed that they could use more space than they had asked for would thus fail. For applications run with this flag set, Windows 3.1 silently increased the total number of words requested by the application by an extra 4 bytes.[5] - Force printer text to new band
- This is bit #1 of the compatibility bits word, with hexadecimal value
0x2
, known by the symbolic nameGACF_FORCETEXTBAND
in windows.h. This flag causes Windows 3.1 to always use two bands when printing, the first for graphics and the second for text. Normally Windows 3.1 tries to print both in a single band. But applications such as WordPerfect assumed that a second band would always exist, and would always be where the text was, as had been the case in Windows 3.0. Freelance Graphics had a similar problem.[5] - Force TT fonts to graphics band
- This is bit #15 of the compatibility bits word, with hexadecimal value
0x8000
, known by the symbolic nameGACF_FORCETTGRAPHICS
in windows.h. This flag was to work around a problem with Freelance Graphics, where it wouldn't print using TrueType fonts unless they were printed as graphics.[5] - Global hooks only called for Win16 apps
- Ignore discardable segment attributes
- This is bit #0 of the compatibility bits word, with hexadecimal value
0x1
, known by the symbolic nameGACF_IGNORENODISCARD
in windows.h. This flag forces theGEM_NODISCARD
flag passed toGlobalAlloc()
by a program to be ignored. It worked around a bug in the run-time library supplied with Microsoft's own C compiler, Microsoft C version 6. The run-time library would erroneously set that flag in calls toGlobalAlloc()
, and any application compiled with that compiler would thus exhibit the behaviour.[5] - Ignore raster fonts
- This is bit #9 of the compatibility bits word, with hexadecimal value
0x200
, known by the symbolic nameGACF_TTIGNORERASTERDUPE
in windows.h. This flag prevents fonts of the same sizes from being enumerated as both bitmap and TrueType fonts. This was because several applications, including WordPerfect and Visual Basic, were not capable of handling that particular situation correctly.[5] - Ignore topmost windows
- This is bit #3 of the compatibility bits word, with hexadecimal value
0x8
, known by the symbolic nameGACF_IGNORETOPMOST
in windows.h. This flag fixes a particular problem with cc:Mail that caused it to fail on Windows 3.1. It assumed that accessing the first window withGetWindow(HWND,GW_HWND_FIRST)
would return it the window of the application that it had just started withWinExec()
. But on Windows 3.1, which introduced the idea of "topmost" windows, this was no longer true. The flag caused Windows 3.1 to skip topmost windows when that particular API request was made.[5] - Module specific hack
- No HRGN 1
- This is bit #16 of the compatibility bits word, with hexadecimal value
0x10000
, known by the symbolic nameGACF_NOHRGN1
in windows.h. This flag reinstates a bug that existed in Windows 3.0 that was fixed in Windows 3.1. It did so because several applications, such as Microsoft Draw, worked around the bug themselves, and would fail to work correctly when the bug was eliminated. The bug was an error in the return value of theGetUpdateRect()
function, whereby in certain situations (where the entire window was invalid) it would return the coördinates of the update rectangle in window coördinates, rather than in logical coördinates as it was supposed to. In Windows 3.1, it always returned the update rectangle in logical coördinates. The applications that worked around the bug would perform the coördinate transform themselves to work around the bug, and end up updating the wrong parts of their windows on Windows 3.1.[5] - One graphic band and use print escapes
- This is bit #2 of the compatibility bits word, with hexadecimal value
0x4
, known by the symbolic nameGACF_ONELANDGRXBAND
in windows.h. This flag causes Windows 3.1 to use a single graphics band when printing in Landscape mode, consuming as much memory as needed for that band, and discarding whatever content would not fit into the band.[5] - Subtract clip siblings
- This is bit #14 of the compatibility bits word, with hexadecimal value
0x4000
, known by the symbolic nameGACF_SUBTRACTCLIPSIBS
in windows.h. This flag causes Windows 3.1 to handle window invalidation differently for top-level windows that do not have theWS_CLIPSIBLINGS
window style set, and their chlid windows. (In other words: It affects dialogue boxes and the controls on them.) With the flag set, Windows would not invalidate sibling child windows underneath (in the z-order) otherWS_CLIPSIBLINGS
child windows. The main reason for the flag was applications such as Lotus Notes 2.1, which implemented its own combo boxes as child windows, rather than as top-level windows (the system default combo box implementation). With this flag set, odd display problems with such windows would disappear.[5] - Support multiple printing bands
- This is bit #5 of the compatibility bits word, with hexadecimal value
0x20
, known by the symbolic nameGACF_MULTIPLEBANDS
in windows.h. This flag causes Windows 3.1 to always use multiple bands for printing, even when one band would be sufficient. This was to work around a problem in Freelance Graphics, which would assume that if only one band existed, and it was the entire page, it was the text band, and would not even attempt to print graphics. On Windows 3.1, the universal printer driver would sometimes be able to handle both text and graphics with a single band. By forcing the use of multiple bands, the problems that this would cause for Freelance Graphics were avoided.[5] - TT fonts are device fonts
- This is bit #4 of the compatibility bits word, with hexadecimal value
0x10
, known by the symbolic nameGACF_CALLTTDEVICE
in windows.h. This flag causes Windows 3.1 to always set theDEVICE_FONTTYPE
flag on any TrueType fonts that are enumerated using the WindowsEnumFont()
API. This was to fix a problem with applications including AmiPro and WordPerfect, both of which assumed that all TrueType fonts available on a printer would be device-resident.[5] - Windows 3.1 palette behavior
Additional flags
Windows 3.1 defined 20 application compatibility flags.[5] Windows 95 and 98 defined a further 11 flags, not documented in the KnowledgeBase article and not assigned symbolic constant names in windows.h, which are the remainder of the options accessible via the "Advanced Options" menu in Make Compatible:[6]
- Disable 16 color brush cache and 55ms timer
- This is bit #29 of the compatibility bits word, with hexadecimal value
0x20000000
. - Disable EMF spooling
- This is bit #26 of the compatibility bits word, with hexadecimal value
0x4000000
. - Disable font associations
- This is bit #24 of the compatibility bits word, with hexadecimal value
0x1000000
. - Don't attach input thread when journaling,
SetActiveWindow
==SetForeGroundWindow
- This is bit #28 of the compatibility bits word, with hexadecimal value
0x10000000
. - Don't Shutdown/Ignore certain faults/dequote commandline
- This is bit #25 of the compatibility bits word, with hexadecimal value
0x2000000
. - Enable 3.x UI features
- This is bit #27 of the compatibility bits word, with hexadecimal value
0x8000000
. - Force Win31 printer dev mode size
- This is bit #23 of the compatibility bits word, with hexadecimal value
0x800000
. - Increase stack size
- This is bit #22 of the compatibility bits word, with hexadecimal value
0x400000
. - Lie about device caps/no
SetDIBits
validation - This is bit #20 of the compatibility bits word, with hexadecimal value
0x100000
. - Lie about windows version
- This is bit #21 of the compatibility bits word, with hexadecimal value
0x200000
. - Mirror fonts in win.ini
- This is bit #30 of the compatibility bits word, with hexadecimal value
0x40000000
.
References
43 year old Petroleum Engineer Harry from Deep River, usually spends time with hobbies and interests like renting movies, property developers in singapore new condominium and vehicle racing. Constantly enjoys going to destinations like Camino Real de Tierra Adentro.
Further reading
- 20 year-old Real Estate Agent Rusty from Saint-Paul, has hobbies and interests which includes monopoly, property developers in singapore and poker. Will soon undertake a contiki trip that may include going to the Lower Valley of the Omo.
My blog: http://www.primaboinca.com/view_profile.php?userid=5889534 - Template:Cite news
- Template:Cite paper
- Template:Cite paper
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 20 year-old Real Estate Agent Rusty from Saint-Paul, has hobbies and interests which includes monopoly, property developers in singapore and poker. Will soon undertake a contiki trip that may include going to the Lower Valley of the Omo.
My blog: http://www.primaboinca.com/view_profile.php?userid=5889534 - ↑ 20 year-old Real Estate Agent Rusty from Saint-Paul, has hobbies and interests which includes monopoly, property developers in singapore and poker. Will soon undertake a contiki trip that may include going to the Lower Valley of the Omo.
My blog: http://www.primaboinca.com/view_profile.php?userid=5889534 - ↑ 3.0 3.1 3.2 Template:Cite web
- ↑ 4.0 4.1 4.2 Template:Cite paper
- ↑ 5.00 5.01 5.02 5.03 5.04 5.05 5.06 5.07 5.08 5.09 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18 20 year-old Real Estate Agent Rusty from Saint-Paul, has hobbies and interests which includes monopoly, property developers in singapore and poker. Will soon undertake a contiki trip that may include going to the Lower Valley of the Omo.
My blog: http://www.primaboinca.com/view_profile.php?userid=5889534 - ↑ Template:Cite paper