windows-nt-4.0/private/mvdm/wow16/write

/************************************************************/
/* Windows Write, Copyright 1985-1990 Microsoft Corporation */
/************************************************************/

                                                     ** 21-January-1988

        MS-WRITE for version 2.0 of Windows is a weird bird in that it 
cannot be compiled with standard tools (ie: MASM 5.0 etc.).  You will
need to set up a separate environment from which to make it using the 
tools in the \WRITE\TOOLS subdirectory.  We are sorry for this inconvenience
and will attempt to remedy this in future versions of MS-WINDOWS.

Sincerely,

OEM Support Group

                                                     ** 27-February-1989
                                                        pault

I am trying to remove the above restriction.  The Win "DEV" SLM project is
being used to build MS-WRITE for Windows 3.0, currently without problems.
Make sure autoexec references are made/added as follows:
        set path=\dev;\dev\tools
        set include=\dev\inc
        set lib=\dev\lib

WRITE is the makefile for this project.  DO NOT USE MAKEFILE -- I do not
know where it came from or why it's here, and of course we may learn that
things are not currently as rosy as we believe, but this is how I *THINK*
the product has been made in the past...
        
        MAKE WRITE              MAKE "DEBUGDEF=-DDEBUG" "DFLAGS=/Zd" WRITE
        builds the standard     builds a debugging version
        release version

        
                                                     ** 28-March-1989
                                                        pault

The above procedure was not generating quite the same WRITE.EXE as we've 
previously had (Win 2.x).  In talking with anyone who's ever been involved
at all, this is the information I have learned:

   1. Nobody wants this product or claims responsibility for it.
   2. It has been a nightmare for everyone who has worked on, with,
      or around it. 
   3. The international version was incorporated at some time during
      2.x and is now "built in".
   4. There was at one time an online help system designed which was 
      never included in a shipped version.
   5. The 6 or 8 batch files, .libs, and makefiles "makefile" and 
      "wrtmake" are for the 2.x version; since we have since grown up 
      I am removing them...
   6. The K*.* files (or *.K* files) apply to the Kanji make process and
      they have N-O-T been updated yet, but are being left in the project
      (i.e. they must be modified or add to the "write" makefile).  Also
      see the file EDM.EDM (hey, file naming is our specialty here at MS).
   
I have made mods to the project and "write" makefile to incorporate the
subtle changes from 2.x.  Variations of the make process are/will be 
documented inside the makefile.

        
                                                     ** 8-June-1989
                                                        pault

In order to ease localization of this product, all string-related info
in GLOBDEFS.H should really be moved to WRITE.RC because that's where
it belongs and it'll also make things a lot cleaner.  [True for Kanji?]

                                                        
                                                     ** 31-August-1989
                                                        pault

Due to major changes in Write.rc and the split into Write.dlg, whoever
takes on the task of localization to Intl or Kanji should be sure to
start over with the new Write.rc and Write.dlg.

                                                        
                                                     ** 18-October-1989
                                                        pault

I've just made a major revision with regard to font handling in Write.
The first one was to make sure that the endmark is always displayed in
the system font.  The Kanji version already ensured this so I grouped
all the code concerning this under the define 'SYSENDMARK', and enabled
it in the Z version.

The second one was to revamp font enumeration... (under 'NEWFONTENUM')

Old method: Call EnumFonts to get a list of fonts available, and "filter 
            out" fonts which did not match our desired aspect ratio (based 
            on the overall display dimensions).  In addition, any fonts 
            which were not the ANSI character set (i.e. the tmCharSet or 
            lfCharSet fields in the TEXTMETRICS and LOGFONT structures, 
            respectively) were "swallowed".  A specific byproduct of this 
            was that screen fonts such as Modern, Script, Symbol, etc.
            could not be used in Write.

New method: Call EnumFonts to get a list of fonts available.  No filtering-
            out is done.  The major problem here became an issue with the
            Write file format: the font name and font family are stored in
            the document but naturally not the appropriate character set 
            value (since only ANSI had been previously allowed).  So now
            when we read a new document in, we enumerate all the fonts and
            then for each font in the doc we try to match up the correct
            character set value.  

            This slows things down ever-so-slightly and we also have the 
            possibility of getting confused if someone names a font of one
            character set the same as one of a different character set, but 
            there wasn't much alternative -- it was either make this kind
            of guess or revise the file format which would have created a
            lot more problems at this point.


                                                     ** 23-October-1989

FernandD has worked on the localization issue mentioned above and checked
in changes for Rel 1.46

                                                     
                                                     ** 24-October-1989
                                                        pault

One change involved in the above NEWFONTENUM was to use FORM1.C instead 
of the (presumably) faster FORMAT.ASM.  So this sparks the idea to keep
a list of some performance ideas for future use...

done?   task
-----   ----
        1) handcode critical routines (including the use format.asm 
           instead of form1.c)
        2) make use of register vars
        3) chipa suggests breaking up really large segments, and eliminating
           very small ones
  X     4) remove inefficient lockdown of dialog procs, etc.  not sure
           why this is currently done but it forces a large amount of 
           code to be fixed at write startup, and this hampers the general
           idea of movable segments in a winapp!
        5) remove use of C run-time libs

                                                     ** 25-October-1989

It has just been decided to remove support for ExtDeviceMode from Write
(primarily because none of the other apps had it!)  This means that when
you change Printer.Setup inside Write, that affects the global Windows
printer settings (rather than just those for the current Write session).