THE WELCH COMPANY
440 Davis Court #1602
San Francisco, CA 94111-2496
415 781 5700
S U M M A R Y
DIARY: June 17, 2002 09:14 AM Monday;
Brandon, Morris conference call on solving SDS memory problem 640K.
2...Vmware Enables Running SDS in OS2 that Provides Additional Memory
3...Visual Basic Rendering of SDS May be Long-term Solution
4...Additional Documentation for NTVDM May Solve Problem Directly
5...Action Plan to Submit Morris' Questions to Microsoft Developers
Click here to comment!
0201 - Microsoft Corporation
020101 - Mr. Brandon Robinson, MCSA MCP MCSE
020102 - Windows Enterprise Support =469 775 6165
020103 - BrandonR@microsoft.com
020104 - Windows 2000 Support =800 936 4900
020105 - Applications and Performance
0202 - Intel Corporation 408 765 8080
020201 - Mr. Morris E. Jones; Business Unit Manager =408 545 9521
020202 - firstname.lastname@example.org
020203 - Cable Network Operation
SRX020519601479 Microsoft Called and Got Incident Number to nvestiga
DOS Memory Get 750K Instead of 634K
DOS Memory Program for More than 640K
Memory Above 640K Submit SDS Program for Review by Brandon
640K Memory Limit for DOS Need Solution
Submitted E Exe to Brandon at Microsoft
Letter to Brandon Asking About Progress on Investigating Increasing R
Jones, Morris Submit Questions to Brends Cannon at Microsoft on Using
Cannon, Brenda Inquiring About Specific Questions Submitted by Morris
Support Team Getting Communication Out of Sequence Causes Teamwork to
Communication Out of Sequence Causes Teamwork to Fail
SDS Memory Increase above 640K Ask Gary to Comment on Whether there a
Email Out of Sequence Delivery Causes Communiation and Teamwork to Fa
Team Getting Communication Out of Sequence Causes Teamwork to Fail Wo
Email Killer App Causes Mistakes Kills Productivity Needs SDS for Int
Telecon Brandon Morris on Extending SDS Memory
2518 - ..
2519 - Summary/Objective
252001 - Follow up ref SDS 35 0000, ref SDS 34 0000.
252003 - SRX020519601479
252005 - Brandon called for telecon per planning on 020613, ref SDS 34 FH9M,
252007 - While we waited for Morris to come on the line, Brandon said he has
252008 - received the questions Morris submitted on 020613. ref SDS 34 QU4O
252009 - ..
252010 - Brandon related having reviewed the Microsoft knowledge base and
252011 - not finding answers to Morris' questions.
252014 - ..
252015 - Vmware Enables Running SDS in OS2 that Provides Additional Memory
252017 - He suggested using Vmware to run OS2 and this will give SDS a
252018 - little more memory for the short run.
252020 - We prefer to look initially for a solution within the Microsoft OS
252021 - framework.
252023 - Still this is is a possibility. Vmware was investigated on 020519
252024 - and did not improve memory for SDS. ref SDS 26 FX6H This was
252025 - reported to Microsoft on 020521. ref SDS 27 JG9L
252027 - However, at that time, the idea of running OS2 in a DOS 6.22
252028 - window under Vmware was not tried. So, this may yet work.
252032 - ..
252033 - Visual Basic Rendering of SDS May be Long-term Solution
252035 - Brandon further suggested creating SDS using Visual Basic, since this
252036 - would provide the full memory of the OS.
252038 - Morris recalled having posed this solution on 020110. ref SDS 21
252039 - S97L At that time analysis showed that while this may be
252040 - possible, even very desirable, it is (a) a huge task in terms of
252041 - manhours that will take several years; and (b) it is problemantic
252042 - whether the result would be effective based on the record of
252043 - others having failed to create SDS capability by such means. Case
252044 - SRX020519601479 is to provide an interim bridge between SDS as it
252045 - presently exists, and new versions using C+, Visual Basic, etc.,
252046 - so that we can continue using Com Metrics, as set out in POIMS.
252047 - ref OF 1 0001
252051 - ..
252052 - Additional Documentation for NTVDM May Solve Problem Directly
252054 - Brandon indicated this morning that solving the problem within
252055 - NTVDM would entail a re-write of NTVDM and Microsoft developers are
252056 - not willing to do this because it reduces compatibility with other
252057 - programs, notably DOS games.
252059 - We reviewed the objective of this case is to increase memory for SDS
252060 - without harming other applications. There are a lot ways to write
252061 - code; some cause harm while others do not. We want to work with
252062 - Microsoft to find a solution that does not cause harm.
252063 - ..
252064 - Morris needs documentation that is not in the Knowledge Base
252065 - that Brandon has investigated so far, but can guide modifying the
252066 - Medit code that supports SDS, so that we can use memory between 640K
252067 - and 1000K, and would not impact other users. A lot of times
252068 - developers are aware of small, seemingly inconsequential, details that
252069 - do not get documented because the people doing the documentation are
252070 - not aware that a particular requirement or capability exists and is
252071 - helpful. Thus, this case requires looking beyond official/published
252072 - documentation to solve a problem for SDS and without causing harm to
252073 - other applications. This may expand the Knowledge Base to help
252074 - others, which is the purpose of knowledge. It is not static, but
252075 - rather grows to meet emerging needs.
252077 - [...below re-stated this point in a letter to Brandon.
252078 - ref SDS 0 UW8H
252079 - ..
252080 - During the call this morning, Morris suggested an additional
252081 - question, and/or clarification to his letter on 020613, ref SDS 34
252082 - QU4O, that might be presented to the development engineers at
252083 - Microsoft who work on NTVDM code.
252085 - [On 020805 Microsoft to reveal Windows code to public.
252086 - ref SDS 38 0001
252088 - [On 020822 letter to Morris asking if code released by Microsoft
252089 - helps meet our objective. ref SDS 39 RP8N
252091 - ..
252092 - Action Plan to Submit Morris' Questions to Microsoft Developers
252094 - Brandon said he would submit Morris' questions. He said it might
252095 - take from 2 weeks to 2 months for the developers to respond.
252097 - We identified two (2) action items....
252099 - 1. Brandon will obtain research from Brenda Cannon and report to
252100 - Welch/Morris, per planning on 020613. ref SDS 34 LP6F
252102 - ..
252106 - 2. Morris will submit supplemental questions per telecon
252107 - this morning, ref SDS 0 V988, and Brandon will forward to
252108 - Microsoft developers. Brandon will follow up with Microsoft
252109 - developers, and report results when available, expected within
252110 - 2 weeks to 2 months.
252111 - ..
252112 - Morris expects to get the supplemental questions sent to
252113 - Brandon later today or tomorrow.
252115 - [On 020625 Brandon said the response he got on Morris'
252116 - questions were that developers laughed and asked why anyone
252117 - wants to increase DOS memory? ref SDS 37 0001
252118 - ..
252119 - Brandon seemed to discuss closing out this problem (he says
252120 - "archiving the case") with the understanding that Brandon will follow
252121 - it up "off-the-books" so to speak.
252123 - This is agreeable within the understandings for follow up proposed by
252124 - Brandon.
252128 - ..
2524 - 1249
252501 - Received ref DRT 1 0001 from Brandon saying....
252503 - Based on our last conversation, the resolution to your issue as
252504 - agreed upon is rewrite the application to support the newer
252505 - memory structures. I will submit this to our dev groups to see
252506 - if anything can be done, but we were ok with archiving the case.
252508 - Rewriting SDS to support newer memory structures is not part of this
252509 - problem, as reported on 020611, ref SDS 32 BLVT, and explained in the
252510 - letter to Microsoft also on 020611. ref DIP 4 008N
252511 - ..
252512 - Brandon's expression of the solution can be strengthened to
252513 - reflect the objective of using NTVDM memory by SDS between 640K to
252514 - 1000K, as set out on 020519, ref SDS 26 LQ4M, and discussed this
252515 - morning with Morris, per above. ref SDS 0 F632
252516 - ..
252517 - Brandon's plan to "...submit this to our dev groups" needs to be
252518 - clarified to reflect planning in the telecon with Morris to submit
252519 - additional questions Morris raised during the call to the dev groups.
252520 - ref SDS 0 F66F
252521 - ..
252522 - Submitted ref DIT 1 0001 to Brandon with link to this record
252523 - that confirms understandings on pending action items. ref DIT 1 F16N
252525 - Copy to Morris, Brenda and Mark.
252527 - Say in part....
252529 - Your letter this afternoon captures important points from our
252530 - discussion with Morris, and I greatly appreciate you keeping on
252531 - top of this matter with timely communication. ref DIT 1 O66K As
252532 - shown in the action items we agreed upon, resolution of this
252533 - case SRX020519601479, from submission on 020519, ref SDS 26
252534 - LQ4M, is to obtain guidance from Microsoft through research by
252535 - you and Brenda to rewrite the SDS application in a way that
252536 - makes better use of NTVDM memory allocation between 640K and
252537 - 1000K. ref SDS 0 GI4I Achieving this objective requires
252538 - investigating beyond the current Knowledge Base to discover
252539 - opportunities overlooked by people who have worked on the
252540 - Knowledge Base so far. This effort will hopefully exand the
252541 - Knowledge Base to solve our current case, within the meaning of
252542 - "knowledge" as an expanding resource that grows to meet emerging
252543 - requirements.
252544 - ..
252545 - The idea posed in your letter below of rewriting the
252546 - application to support the newer memory structures is a future
252547 - effort that is unrelated to this current case. ref DIT 1 009H
Distribution. . . . See "CONTACTS"