THE WELCH COMPANY
440 Davis Court #1602
San Francisco, CA 94111-2496
415 781 5700
rodwelch@pacbell.net


S U M M A R Y


DIARY: August 3, 2003 01:40 PM Sunday; Rod Welch

Morris comments on DOS Extender to improve SDS memory.

1...Summary/Objective
2...DOS Extender Allows a Single File to Fit Current Memory Limits
3...Extended Memory Allows Multiple Files to Fit Current Limits in DOS
4...5 Years Development Period for Next Version of SDS Apply DOS Extender
........C++ Best Programming Language for PC
........Macros Enable Non-programmers to Extend Basic Functionality


..............
Click here to comment!

CONTACTS 
0201 - Intel Corporation                                                                                                                                                  O-00000704 0201
020101 - Mr. Morris E. Jones;
0202 - Boeing                                                                                                                                                             O-00000816 0505
020201 - Mr. Garold L. Johnson
020203 - Modeling and Simulation                                                                                                                                          O-00000816 0505

SUBJECTS
Development Planning for Next Generation SDS
Language SDS Development Next Version Practical Immediate Improvement
SDS Development Next Version Practical Immediate Improvements Plannin
Medit Macro Language Gary Asks about Where to Learn Commands
Johnson, Gary Develop Next Generation Programming Language Survey of
SDS Design Difficult to Reverse Engineer Need Experience Using SDS to
Johnson, Gary Submits Ideas Questions to Morris on Using DOS Extender
Johnson, Gary Survey Software Programming Language Choices and Compil
Programming Language SDS Development Next Version Practical Immediate
DOS Extender For Interim Memory Solution to Medit and SDS Gary Johnso

3612 -
3612 -    ..
3613 - Summary/Objective
3614 -
361401 - Follow up ref SDS 14 0000, ref SDS 12 0000.
361402 -
361403 - Received ref DRT 1 0001 from Morris responding to an email submitted
361404 - yesterday, ref SDS 14 QF91, asking for input on Gary's record for
361405 - 030727 that develops planning for the next version of SDS. ref SDS 11
361406 - 0001
361407 -
361409 -  ..
361410 - DOS Extender Allows a Single File to Fit Current Memory Limits
361411 - Extended Memory Allows Multiple Files to Fit Current Limits in DOS
361412 - 5 Years Development Period for Next Version of SDS Apply DOS Extender
361413 -
361414 -
361415 - Morris says....
361416 -
361417 -    1.  I followed the links a little.  Never did find the letter from
361418 -        Gary. The problem with DOS extenders is the code uses 16 bit
361419 -        pointers assuming each pointer points to a paragraph (16 byte
361420 -        chunk) of memory.  While some swapping could be arranged with a
361421 -        DOS extender, it won't allow a single file to grow larger than
361422 -        the current memory limits. ref DRT 1 0001
361424 -  ..
361425 - Gary's letter to Morris, cited in my record on 030728, asked for input
361426 - on using a "DOS extender" to increase memory for SDS, ref SDS 12 0001,
361427 - and was based on Gary's analysis on 030727. ref SDS 11 LM5O  Morris
361428 - does not seem to have responded to Gary; but, today, he sent a letter
361429 - to me answering the email to him yesterday that reviews Gary's
361430 - planning for a next version of SDS. ref SDS 14 VL4I
361432 -  ..
361433 - Does Morris' comment that a DOS extender will not "...allow a single
361434 - file to grow larger than the current memory limits," mean that....
361435 -
361436 -           a.  we could have a separate memory block assigned for each
361437 -               file?
361438 -
361439 -           b.  would these memory blocks be 640K or 1 MB?
361441 -                  ..
361442 -                 [On 030902 developed method for using Windows Start
361443 -                 command to accomplish this level of memory management.
361444 -                 ref SDS 15 0001
361446 -                ..
361447 -           c.  would this scheme support loading say 10 files with 500K
361448 -               each to actually use 5 MB of memory; or could the files
361449 -               be say 800K each to use 8 MB of memory?
361451 -                ..
361452 -               These are common scenarios with SDS, sometimes we could
361453 -               bump up to 15 or 20 files vary easily.
361455 -                ..
361456 -               What impact would this have on speed?
361458 -                ..
361459 -               What impact on fragmenting memory.
361460 -
361461 -                  Generally have to shut down w2k 1 - 2 times a day to
361462 -                  refresh memory, because we typically have a primary
361463 -                  session of SDS, and several other sessions for
361464 -                  working on different issues.  Assumes that opening
361465 -                  and closing these sessions leads to fragmented memory
361466 -                  that requires shutting down, depending on how heavy
361467 -                  the traffic has been.
361469 -                   ..
361470 -                  Would using extended memory in the manner under
361471 -                  discussion here increase the frequency of requiring a
361472 -                  shut down to refresh memory.
361474 -                   ..
361475 -                  Would increasing the total RAM in the computer have a
361476 -                  positive effect.  Currently, we have 500MB.  If we
361477 -                  went to 1 GB would the problem of fragmented memory
361478 -                  requiring shut down be expected to decline?  What
361479 -                  would this do to the speed of operations?
361480 -
361482 -  ..
361483 - While this is not a complete solution, it is big interim help while
361484 - the next version is being developed and debugged over the next five
361485 - (5) years, per planning on 030801. ref SDS 14 U87N  Gary called today,
361486 - and he feels that a five (5) year window is needed to use the current
361487 - version while the next version is developed.  This aligns with
361488 - planning on 950803 showing a 5 - 10 year development schedule.
361489 - ref SDS 2 S952
361490 -
361491 -
361492 -
361493 -
361494 -
361495 -
3615 -

SUBJECTS
C++ Morris Recommends for Programming on a PC Next Version of SDS
Develop Next Generation SDS Practical Immediate Improvements Planning

380401 -         ..
380402 -        C++ Best Programming Language for PC
380403 -
380404 -
380405 - Morris continues...
380406 -
380407 -    2.  The comments on design language are mostly moot with the speeds
380408 -        of current processors.  Write in the computer language that
380409 -        provides the most productivity for the programmer.  (Most
380410 -        likely C++, or some other higher language).  If writing for
380411 -        windows on a PC, then C++ has the best tools.  When PCs were
380412 -        slow, with limited memory, programming language and style could
380413 -        have an impact.  Now with huge memory spaces, and multi GHz
380414 -        processors, it is a non-issue.
380416 -  ..
380417 - Morris does not cite the location nor any specifics on comments for a
380418 - design language referenced in his letter.  Gary's record on 030727
380419 - discusses this subject at length. ref SDS 11 UY5H  Since this is the
380420 - only place where the subject has been addressed recently, and since
380421 - Gary's record was linked to the record on 030801, which Morris was
380422 - asked to review, ref SDS 14 QF91, assume that when Morris says he
380423 - followed some links, he is disclosing that he reviewed the heading
380424 - for....
380426 -                        ..
380427 -                       Choice of programming language
380428 -
380429 -
380430 - ...in Gary's record on 030727, ref SDS 11 UY5H, which is cited in my
380431 - record on 030801. ref SDS 14 2X38
380433 -  ..
380434 - Morris' recommendation to use C++ for programming on a PC aligns with
380435 - the work on 950802 when Morris started work on a Windows version of
380436 - SDS using C++. ref SDS 1 9U8K
380437 -
380438 -
380439 -
380440 -
3805 -

SUBJECTS
Microsoft Macro Language Visual Basic Recommended by Morris for SDS D
Macro Language Reported Not to be Effective for Enhancing Software Pr
Macro Language Microsoft Visual Basic Can Convert Outlook and Word Ca
Visual Basic Macro Language for Programming to Customize Word Outlook
Microsoft Word Outlook Visual Basic Programming Language May be able

430701 -         ..
430702 -        Macros Enable Non-programmers to Extend Basic Functionality
430703 -
430704 -
430705 -    3.  The macros are a result of you refusing to learn a real
430706 -        programming language. I have suggested, and still suggest you
430707 -        learn C, and the macros are a thing of the past.
430709 -  ..
430710 - This aligns with Morris' suggestion above to use C++ for programming a
430711 - new version of SDS. ref SDS 0 YG3H
430713 -  ..
430714 - On 020110 Morris suggested creating SDS support for Com Metrics by
430715 - using the Microsoft macro language to enhance Word, Outlook, etc.
430716 - ref SDS 4 W559  This suggests that macros might be helpful for making
430717 - a program "extensible," which enables users to experiment in order to
430718 - identify useful new functionality, as occurred with SDS.
430719 -
430720 -
430721 -
430722 -
430723 -
430724 -
430725 -
430726 -
430727 -
430728 -
430729 -
430730 -
430731 -
430732 -
430733 -
Distribution. . . . See "CONTACTS"