|
|
/************************************************************//* 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 willneed to set up a separate environment from which to make it using the tools in the \WRITE\TOOLS subdirectory. We are sorry for this inconvenienceand 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 isbeing 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 notknow where it came from or why it's here, and of course we may learn thatthings 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 involvedat 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 thesubtle 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 infoin GLOBDEFS.H should really be moved to WRITE.RC because that's whereit 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, whoevertakes on the task of localization to Intl or Kanji should be sure tostart 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 inthe system font. The Kanji version already ensured this so I groupedall the code concerning this under the define 'SYSENDMARK', and enabledit 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 checkedin 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 keepa 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 whenyou change Printer.Setup inside Write, that affects the global Windowsprinter settings (rather than just those for the current Write session).
|
