My Vintage Dream PC

Discussion in 'Computer Information' started by GreenXenon, May 18, 2009.

  1. GreenXenon

    jmfbahciv Guest

    Did the book mention the work that JMF and his group were doing
    w.r.t. NT developement? Does it mention the work that MS
    contracted DEC to do w.r.t. NT development?

    jmfbahciv, May 25, 2009
    1. Advertisements

  2. GreenXenon

    jmfbahciv Guest

    And that's why the monitor needs to be "separate" from the user
    code. MS' development tradition is to take the "shortcuts" and
    directly access exec code or put the app code in the exec. this
    allows any old user mode program to spray bits all over the disks
    and core even it's protected with hardware.

    It takes time and lots of design meetings to get people to agree
    on a UUO or CALLI interface. MS' development folklore was to
    always to this stuff the "short" way, w.r.t. wallclock time.

    Just look at the mindset of Gates when he was getting started.
    This mindset was carried into corporate and has become part of
    its folklore.

    jmfbahciv, May 25, 2009
    1. Advertisements

  3. GreenXenon

    jmfbahciv Guest

    I had understood the reference of "enemy" to be the in-house politics
    of Microsoft and not about the quality of their ships.
    I agree. That is why I'm writing my comments about monitor vs. app
    development. Lynn and I know what kinds of work is involved to
    create a secure "gateway" between an app and the monitor during
    a development cycle. Granted, this was in the old days but our
    methods worked. You cannot edict a million lines of code written
    in two months and expect any sensible overall design. MS' usage
    of developers is to make them work 7x24 until they burn out (less
    than a year or two). That means that no learning of previous
    developments ever gets used in the next software release. So
    the old mistakes are recreated, ad infinitum. Functional and
    architectural designs are only as good as the amount of
    old learning about what not to do is included in those designs.

    I wrote that badly but I can't seem to do a rewrite...

    Anyway, taking the lead time to do the designs properly determines
    the ease of getting rid of the bugs that are written and/or
    resurrected. The amount of this lead time goes up exponentially
    with the number of developers involved in a development cycle.
    Lynn? Formula might be e^n, n=number of humans doing the
    development, testing, and documenting the software.

    No where is there a group of three anymore. Three is the ideal



    not to do
    jmfbahciv, May 25, 2009
  4. Wallclock time for development or at run time? Both will lead to
    instability and security problems mentioned here. But our computers are
    so fast that history is running in reverse, people are buying netbooks,
    which are a *serious* step down in power.
    Walter Bushell, May 25, 2009
  5. slightly related recent thread about security/integrity
    (and system design point)
    http://www/ Comuter virus strikes US Marshals, FBI affected

    one of the things about current mainframe batch system is that its (360)
    heritage was from small/limited real-memory (single address, no virtual
    memory) ... supervisor/kernel code was in same address space as
    application code. pervasive use of pointer passing in API between
    application code and supervisor/kernel.

    initial translation of this paradigm into (370) virtual memory was
    single (16mbyte/24bit) virtual address space ... basically simulated 360
    envorinment but with the appearance of larger real memory; the
    supervisor/kernel still occupied the same address space as applications
    and retained extensive pointer-passing API.

    next morph was to have multiple virtual address spaces ... one per
    application. it almost simulated 360 environment ... supervisor/kernel
    and application occupying same address space ... but now there was one
    virtual address space per application (with the same supervisor/kernel
    image appearing in each address space).

    this had some unintended consequences. 370 was 16mbyte/24bit virtual
    address space ... which was laid out with 8mbytes of the
    kernel/supervisor image in each adderss space ... and theoritically
    8mbytes for each application.

    the problem was a number of "sub-system" services which had been outside
    the kernel/supervisor ... and were now in their own unique virtual
    address space (just like applications) ... however there was problem
    with conventions that normal application pointer-passing API "calling"
    these subsysttem services (which no longer resided in the same virtual
    address space). the hack/work-around was something called the "common
    segment" that appeared in every virtual address space (similar to the
    kernel/supervisor image). applications would reserve space in the common
    segment, move API parameters into their reserved common segment space
    and perform sub-system service call, passing pointer to the common
    system area. This common system area could also be used by subsystem to
    return values to the application.

    The problem was that size of common segment was basically proportional
    to number of subsystems and application activity. By the time of 3033,
    large installation were needing common segment area that were 5-6 mbytes
    in size ... leaving only 2-3 mbytes for application use (each
    application had dedicated 16mbyte virtual address space ... but half
    that went to the supervisor/kernel image and then 5-6 mbytes for common

    misc. past posts mentioning common segment and pointer passing API Handling variable page sizes? Handling variable page sizes? Page Table - per OS/Process If the x86 ISA could be redone PCIe as a chip-to-chip interconnect CKD Disks? Integer types for 128-bit addressing The mid-seventies SHARE survey Moving assembler programs above the line address space Intel strikes back with a parallel x86 design Multiple address spaces Multiple address spaces Multiple address spaces virtual memory The Pankian Metaphor virtual memory What part of z/OS is the OS? MIPS architecture question - Supervisor mode & who is using it? Ranking of non-IBM mainframe builders? threads versus task Ranking of non-IBM mainframe builders? "The Elements of Programming Style" IBM to the PCM market(the sky is falling!!!the sky is falling!!) user level TCP implementation IBM 8000 series The name "shell" The name "shell" Does software life begin at 40? IBM updates IMS database Direction of Stack Growth CSA 'above the bar' CSA 'above the bar' segmentation or lack thereof T3 Sues IBM To Break its Mainframe Monopoly New Opcodes Regarding the virtual machines Kernels IBM Preview of z/OS V1.10 Different Implementations of VLIW DB2 & z/OS Dissertation Research Old XDS Sigma stuff Opsystems TOPS-10 What if the computers went back to the '70s too? What if the computers went back to the '70s too? Graphics on a Text-Only Display Why do IBMers think disks are 'Direct Access'?
    Anne & Lynn Wheeler, May 25, 2009
  6. You just described OS4000, running on the GEC 4000 series minicomputers.
    The only code you can run on the system runs in processes. The Kernel
    is all hardware and firmware, and you can't change or modify it.
    The later models in the range were fpga instead.
    GEC did experiment with such a system too, but it never turned into a
    Andrew Gabriel, May 25, 2009
  7. GreenXenon

    Peter Flass Guest

    Peter Flass, May 25, 2009
  8. 1 for the OS
    3 for the GUI
    50 for DRM
    9 for WGA
    1 for the apps
    Ahem A Rivet's Shot, May 26, 2009
  9. GreenXenon

    JosephKK Guest

    Kind of a vague description for something you seem to think important.
    How about trying a bit harder to explain to me (perhaps us).
    JosephKK, May 26, 2009
  10. GreenXenon

    JosephKK Guest

    Pretty much agreed here. I can see hiring a PST for training
    purposes, but with so much available for free (other than a few
    moments of your time) why pay for sex. BTW John, sex and love are
    different things.
    JosephKK, May 26, 2009
  11. GreenXenon

    Peter Flass Guest

    Not very efficient, it would be a return to the bad old days of
    master-slave or asymmetric multiprocessing. The problem usually isn't
    the CPU anyhow, it's memory corruption, and multiple cores don't solve
    this problem.
    Peter Flass, May 26, 2009
  12. GreenXenon

    jmfbahciv Guest

    Making development design decisions.
    History has reversed itself so far that developers are now reinventing
    things that we took for granted.

    jmfbahciv, May 26, 2009
  13. GreenXenon

    jmfbahciv Guest

    I've been hearing about their next release. Not good at all.

    jmfbahciv, May 26, 2009
  14. GreenXenon

    jmfbahciv Guest

    It's vague because each OS provides a different kind of service. Each
    OS has to have its tradeoff litmus test and each one will be different
    depending on how its going to be used.

    jmfbahciv, May 26, 2009
  15. GreenXenon

    jmfbahciv Guest

    Which will cause every system to grind to a halt. think about
    Which will still require one CPU to be "boss".
    The problem is scheduling. Memory corruption would be isolated to an
    app address space, not the monitor's.

    jmfbahciv, May 26, 2009
  16. GreenXenon

    jmfbahciv Guest

    Based on what I've just heard, 1000 for the file system arranger.

    jmfbahciv, May 26, 2009
  17. Why only one? Surely the kernel will be multithreaded.
    Walter Bushell, May 26, 2009
  18. GreenXenon

    Joe Pfeiffer Guest

    You seem to be assuming a microkernel, with the other functions in other
    programs. But at this level of description, that's really a variation
    on the "multithreaded OS" theme.
    I'm not sure we need a "new" approach, but we certainly need an approach
    other than Windows. Coincidentally, I'm typing this on a Linux box.
    Joe Pfeiffer, May 26, 2009
  19. Wheee it's MP/M all over again.
    Ahem A Rivet's Shot, May 26, 2009
  20. GreenXenon

    Peter Flass Guest

    The other way 'round. If you dedicated a core to the OS, it would have
    to single-thread. If any core can execute any thread the OS can get
    whatever it needs. It's tempting to just dedicate something, but OS
    developers decided years ago that the more scheduling flexibility you
    have, the better.
    Peter Flass, May 26, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.