[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

keep the formats closed ..

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.

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index