From: andyp Thu Apr 13 19:22:20 1989
To: markwa; philba
Cc: janderie; markro; peterma
Subject: WIN, PM
Date: Wed Nov 06 15:54:11 PDT 1991
i have some questions about both WIN and PM. i guess i need two sets of
answers, one for WIN, one for PM.
1. rumer has it there is a memo describing the various prologs/epilogs
which you provide to compiler writers. we also need to know all the
cases where yoy need special FIXUPPs. Etc.
2. presumably the internal - PLMN/PLMF stuff is not in the memo, we'd
like a description of it.
3. we also have some specific questions which may or may not be in the
memo, namely for WIN (or PM), what is done about segments setups when
WIN/PM does a callback;
will WIN/PM replace the first three bytes of codes, to setup DS?
will WIN/PM set the DS to 0, as I see with cvp?
does MS advise the use of -Gw, or -Au, or _loadds, or what?
how about the life program, chapter 13 from Petzold.
if we build it as per his e.g., it fails
if we use -Au (or add _loadds to the callback), it works
We've been playing around w/ C5, QC, C6, and Petzold's book(s), and it
appears that we don't always do the right things.
we'd very much like to figure out what is correct and fix it for C6,
which will be goig beta very soon.
//andy
From: richab Fri Apr 14 07:28:10 1989
To: celesteb; markwa; sherryr
Cc: greglo; jodys; lisacr
Subject: RE: SDK/DDK requirements
Date: Wed Nov 06 1554:11 PDT 1991
dropping serial mice from any release is stupid. Don't do it. We're
taking enough crap over the compaq 386 only support in the alpha.
There are 3X more serial mice in the world than bus mice. Why don't we
focus on getting the work done, rather than hacking at features?
I don't like undocumentated apis? This is also stupid. You assume that
the number of folks interested in this sort of thing is small. all we do
is limit window's appeal to developers and look as if we favor some vendors.
Full disclosure ... that's my position.
***
> From: markwa Fri Apr 7 12:12:19 1989
To: celesteb; richab; sherryr
Cc: greglo; jodys; lisacr
Subject: RE: SDK/DDK requirments
Date: Fri Apr 07 11:09:40 1989
To clarify Greg's question #1 below -- On our current release schedule
of 4/20, the product will go out without support for serial mice under
Win386, that is, under protect mode. This will further limit the number
of configurations that people can use to try out the 3.0 pre-release. If
Marketing knows what proportion of the ISVs receiving the pre-release
have serial as pooosed to bus mice, then you should be able to make an
informed decision as to whether it is acceptable to send out the
pre-release without support for serial mice under protect mode.
> From: greglo Fri Apr 7 11:27:16 1989
To: celesteb; jodys; lisacr; markwa; sherryr
Subject: SDK/DDK requirments
Date: Fri Apr 07 11:26:00 1989
1. Do we need to support serial mice in win386?
If we do, it may involve a schedule hit. Is this important?
2. Do we need to document the api that would allow applications and
device drivers to do DMA from bus master cards? This would probably be
needed by a small number of people, such as Logitech to support their
scanner/app. I vote to leave this one undocumentated, which would allow
us to add it in later in the cycle.
***
From: richab Fri Apr 7 08:30:44 1989
To: bobgu; markwa; winners
Cc: betsyt; jimgr
Subject: RE: Documentation of binary file formats
Date: Wed Nov 06 15:54:19 PDT 1991
i agree 100% with mark.
***
> From: markwa; Tue Apr 11 13:27:32 1989
To: bobgu; winners
Cc: betsyt; jimgr
Subject: RE: Documentation of binary file formats
Date: Tue Apr 11 12:24:45 1989
So, this means that we would have a closed architecture that will
prevent other ISVs from developing resource editing tools that might
improve upon ours. It would be a shame without giving it a chance to
come up with something better.
It turns out, we have already provided resource format information to
WhiteWater, who is currently beta-testing an integrated resource editing
tool set (I don't have a copy yet). Are you implying, Bob, that not only
are we going to discourage other ISVs from coming up with such tools,
but also we might pull the rug from underneath WhiteWater without giving
them a chance to update their tool to the new formats?
I vote for open architecture here. Let the market fill the voids where
we have lacked leadership. If there is a problem with changing formats,
then let's work out a strategy where we casn continue to change formats,
if we need to, and cooperate with ISVs who depend on them, as necessary.
RES overall format
Dialog resource
Bitmap resource
Icon resource
Cursor resource
Menu resource
String table resource
Accelerator resource
RCDATA resource
Absolutly no! We MUST not document the RES file format or the format of
any of the structures contined in it. This is a private file and
documentating it ties our hands for future versions.
This does NOT mean we shouldn't document the structures to be used for
functions like CreateDialogIndirect() or CreateMenuIndirect(). These
structures are independent of the resource file structure. Yes, for some
they might be identical, but that is for us to decide.
- BobGu
From: danbo; Fri Apr 14 10:30:59 1989
To: danb; donr; franzr; jonhod; markwa
Cc: celesteb; richab; sherryr
Subject: Windows SDK Documentation
Date: Wed Nov 06 15:54:27 PDT 1991
Danb, can you please verify the BOM being used for the build of
050-150AV210? Canada is receiving packages with incomplete documentation.
Markwa,, are you familiar with the situation described by John Hodges??
> From: sherryr Fri Apr 14 10:22:32 1989
To: franzr
Cc: danbo; jonhod
Subject: Re: CVW
Date: Fri Apr 14 10:19:35 1989
I asked danbo (who handles manufacturing of Windows products) to check
into this. He and I and others have been out in Chicago at COMDEX this
past week. I am sure danbo will respond when he gets back. thx.
http://edge-op.org/iowa/www.iowaconsumercase.org/011607/5000/px05035.txt
--
court documents in the case of Comes v Microsoft.
|