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?

    /BAH
     
    jmfbahciv, May 25, 2009
    #41
    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.

    /BAH
     
    jmfbahciv, May 25, 2009
    #42
    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
    number.

    /BAH


    /BAH

    not to do
     
    jmfbahciv, May 25, 2009
    #43
  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
    #44
  5. slightly related recent thread about security/integrity
    (and system design point)
    http://www/garlic.com/~lynn/2009h.html#28 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
    segment).

    misc. past posts mentioning common segment and pointer passing API
    http://www.garlic.com/~lynn/2002l.html#57 Handling variable page sizes?
    http://www.garlic.com/~lynn/2002m.html#0 Handling variable page sizes?
    http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process
    http://www.garlic.com/~lynn/2004c.html#6 If the x86 ISA could be redone
    http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect
    http://www.garlic.com/~lynn/2004n.html#54 CKD Disks?
    http://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
    http://www.garlic.com/~lynn/2005b.html#53 The mid-seventies SHARE survey
    http://www.garlic.com/~lynn/2005f.html#57 Moving assembler programs above the line
    http://www.garlic.com/~lynn/2005p.html#18 address space
    http://www.garlic.com/~lynn/2005q.html#48 Intel strikes back with a parallel x86 design
    http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
    http://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces
    http://www.garlic.com/~lynn/2006b.html#32 Multiple address spaces
    http://www.garlic.com/~lynn/2006i.html#33 virtual memory
    http://www.garlic.com/~lynn/2006j.html#38 The Pankian Metaphor
    http://www.garlic.com/~lynn/2006k.html#44 virtual memory
    http://www.garlic.com/~lynn/2006p.html#10 What part of z/OS is the OS?
    http://www.garlic.com/~lynn/2006r.html#32 MIPS architecture question - Supervisor mode & who is using it?
    http://www.garlic.com/~lynn/2006s.html#42 Ranking of non-IBM mainframe builders?
    http://www.garlic.com/~lynn/2006t.html#23 threads versus task
    http://www.garlic.com/~lynn/2006v.html#23 Ranking of non-IBM mainframe builders?
    http://www.garlic.com/~lynn/2006y.html#16 "The Elements of Programming Style"
    http://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
    http://www.garlic.com/~lynn/2007k.html#27 user level TCP implementation
    http://www.garlic.com/~lynn/2007o.html#10 IBM 8000 series
    http://www.garlic.com/~lynn/2007o.html#73 The name "shell"
    http://www.garlic.com/~lynn/2007o.html#75 The name "shell"
    http://www.garlic.com/~lynn/2007q.html#26 Does software life begin at 40? IBM updates IMS database
    http://www.garlic.com/~lynn/2007q.html#68 Direction of Stack Growth
    http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar'
    http://www.garlic.com/~lynn/2007r.html#69 CSA 'above the bar'
    http://www.garlic.com/~lynn/2007t.html#16 segmentation or lack thereof
    http://www.garlic.com/~lynn/2007t.html#75 T3 Sues IBM To Break its Mainframe Monopoly
    http://www.garlic.com/~lynn/2008c.html#35 New Opcodes
    http://www.garlic.com/~lynn/2008d.html#69 Regarding the virtual machines
    http://www.garlic.com/~lynn/2008e.html#14 Kernels
    http://www.garlic.com/~lynn/2008e.html#33 IBM Preview of z/OS V1.10
    http://www.garlic.com/~lynn/2008g.html#60 Different Implementations of VLIW
    http://www.garlic.com/~lynn/2008h.html#29 DB2 & z/OS Dissertation Research
    http://www.garlic.com/~lynn/2008o.html#53 Old XDS Sigma stuff
    http://www.garlic.com/~lynn/2008p.html#40 Opsystems
    http://www.garlic.com/~lynn/2008q.html#31 TOPS-10
    http://www.garlic.com/~lynn/2008r.html#32 What if the computers went back to the '70s too?
    http://www.garlic.com/~lynn/2008r.html#34 What if the computers went back to the '70s too?
    http://www.garlic.com/~lynn/2009.html#55 Graphics on a Text-Only Display
    http://www.garlic.com/~lynn/2009c.html#59 Why do IBMers think disks are 'Direct Access'?
     
    Anne & Lynn Wheeler, May 25, 2009
    #45
  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
    product.
     
    Andrew Gabriel, May 25, 2009
    #46
  7. GreenXenon

    Peter Flass Guest

    CDC-6600.
     
    Peter Flass, May 25, 2009
    #47
  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
    #48
  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
    #49
  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
    #50
  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
    #51
  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.

    /BAH
     
    jmfbahciv, May 26, 2009
    #52
  13. GreenXenon

    jmfbahciv Guest

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

    /BAH
     
    jmfbahciv, May 26, 2009
    #53
  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.

    /BAH
     
    jmfbahciv, May 26, 2009
    #54
  15. GreenXenon

    jmfbahciv Guest

    Which will cause every system to grind to a halt. think about
    networking.
    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.


    /BAH
     
    jmfbahciv, May 26, 2009
    #55
  16. GreenXenon

    jmfbahciv Guest

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

    /BAH
     
    jmfbahciv, May 26, 2009
    #56
  17. Why only one? Surely the kernel will be multithreaded.
     
    Walter Bushell, May 26, 2009
    #57
  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
    #58
  19. Wheee it's MP/M all over again.
     
    Ahem A Rivet's Shot, May 26, 2009
    #59
  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
    #60
    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.