muta...@gmail.com  wrote:   
   > On Sunday, October 23, 2022 at 11:27:48 AM UTC+8, anti...@math.uni.wroc.pl   
   wrote:   
   >   
   > > > I only care about programs that obey the rules and   
   > > > are either bug-free or the vendor is willing to fix   
   > > > the bugs.   
   > > >   
   > > > Also I'm not a commercial CPU vendor and I'm not   
   > > > trying to generate a profit.   
   > > >   
   > > > I'm trying to get a handle on the underlying theory.   
   >   
   > > Theory is simple: if program treats segments in abstract   
   > > way, that is does not attempt to use aritmetic to   
   > > produce new segment selectors, then it will work with   
   > > no problems in 286 protected mode.   
   >   
   > Ok, thankyou.   
   >   
   > But are you sure?   
   >   
   > For starters, if an MSDOS executable has a function that   
   > crosses a 64k boundary, it will be tied down to a 4-bit   
   > shift, won't it?   
      
   That depends how functions bigger than a segment are handled.   
   IIRC some (most ???) compilers required function to fit   
   into single segment.  In principle compiler can split   
   function into multiple segments.  If this is done right,   
   that is segments are disjoint, then there is no need to   
   talk about "segment shift".  It is essentially the same   
   as having two (or more) separate functions (but the control   
   transfers are done by far jumps).  Actually, you may have   
   more complicated code using multiple selectors, main point   
   is that segments selectors are delivered by OS and program   
   never produces new segments using arithmetic.   
      
   Note that when DOS loads program (EXE) it adjusts segments.   
   In PM loader will produce different segment selectors,   
   mapping the same memory.  Of course, this means that   
   program will use for code exactly the same amount of   
   memory as in real mode and thinking in terms of assembly   
   there will be the same "labels" (just shifted into different   
   place in memory).  However, in a sense that is not a   
   restriction, this is how things work.   
      
   > Icing on the cake is huge memory model. If we can get that   
   > to work on the 80286, that would be ideal.   
      
   That is problematic.  You can probably "solve" it by using   
   function calls for huge pointer arithmetic and providing   
   (in OS) different function for real and protected mode.   
   But that is really not satisfactory.   
      
   > And if it works on the 80286 it will probably work with   
   > 5-bit shifts too.   
   >   
   > > In practice, it did not work -- your (and Intel) assumptions   
   > > were not valid.   
   >   
   > What assumption?   
   >   
   > I didn't assume that people would write bug-free code.   
   > I didn't assume that people would fix bugs.   
   >   
   > All I wanted was technically valid programs to work.   
   >   
   > Especially ones that I write myself.   
      
   I do not know what you wrote.  But people wanted smoothly   
   working editors, which involved direct writes to screen   
   memory.  That would break with your 5-bit shift (could be   
   made to work in protected mode by running program with no   
   protection (kernel mode) and allocating appropriate segment).   
      
   In slightly different spirit: if you want to handle block   
   of memory bigger than 64k given just its size and address of   
   its start you have to do segment arithmetic.  If you need   
   a lot of pointers to structure where each structure is 16 bytes   
   big, then you can allocate them in such a way that each   
   starts at address divisible by 16.  After that you can   
   use just segment part to point to each structure.  If you   
   need a lot of such pointers, that may give you nice saving.   
   But this may introduce dependence on 4-bit shift.  Or   
   possibly program will work with bigger shifts, but waste   
   memory.   
      
   Of course, you may say that such programs are buggy, but   
   if alternative is not having a program at all or one that   
   is too slow or too big to fit into available memory, then   
   real word judgement is clear: such programs are valid   
   solutions.   
      
   > > > Never. Microsoft could have coded MSDOS to support   
   > > > a flexible shift (or even a flexible segment   
   > > > manipulation) and laid out clear rules. And if Intel   
   > > > had a vested interest in holding real mode applications   
   > > > to 1 MB, a competitor could have come along.   
   >   
   > > As I wrote, in theory programs should run in protected   
   > > mode using up to 16 M on 286 and up to 1G on 386   
   > > (limit on 386 is because two bits in selector encode   
   > > access rights, so only 14 bits determine actual segment).   
   >   
   > And that's the theory that I want.   
   >   
   > > In principle Microsoft could create version of DOS   
   > > that would run ordinary, but "well behaved" DOS programs in   
   > > protected mode and allow use of large memory.   
   >   
   > And in theory if Microsoft can do it, I can do it too.   
   >   
   > And that is what I am interested in.   
   >   
   > > I do not know   
   > > if they did this. I know that other companies created so called   
   > > DOS extenders that allowed programs to run in protected   
   > > mode and use large memory. As I wrote, program still   
   > > would run on 8086 in 1M, but programer had to link to   
   > > extender or use it as a "loader".   
   >   
   > I don't want anything that modifies the executable. I want   
   > a nice clean MSDOS executable, and I want it to use 16 MB   
   > of memory or 1 GB or whatever.   
      
   In a sense EXE is always "modified", that is part of program   
   loading (handling relocations).  Extender provided different   
   program loader and differen OS functions, needed to in protected   
   mode.  You would like this to be part of OS, or in different   
   words you want OS to do this work.  In fact, late DOS contained   
   buit-in DOS extender.  But Microsft gave priority to programs   
   that (using your language) are "not technically valid", so   
   even on 286 by default you got real mode and program had to   
   explicitely "opt in" to be run in protected mode.   
      
   > > So you should not blame Intel. Concerning Microsoft, you   
   > > can blame them because they did not do what you wanted.   
   > > But in all worlds where your assumptions are true they   
   > > created such wonder-DOS. The problem is that such world   
   > > does not exist...   
   >   
   > I am creating a world with a wonder-DOS. I am not dependent   
   > on Microsoft.   
   >   
   > All I asked for was technical details on how to create a   
   > wonder-DOS.   
   >   
   > This is an OS development group. It's an obvious place to   
   > get answers on OS development as opposed to   
   > alt.os.accept.whatever.shit.microsoft.gives.you.and.learn.to.love.it.   
      
   Well, sane use of segments has it limits.  As I wrote, those   
   limits are almost OK if all what you have is 1M of memory.   
   For bigger systems one want linear 32 (or 64) bit address   
   space.  And for programs that _you_ wrote correct way is to   
   recompile them.   
      
   So basically, you are trying to solve artificial, made up   
   problem.  Apparently you enjoy this, that is fine.  But   
   do not be angry that people tell you truth: this is made   
   up problem.   
      
   > > > > But most people were in different position. They had 16-bit   
   > > > > real mode binary programs. They needed to run them. So for   
   > > > > them it was essential to have VM86 to be able to run existing   
   > > > > binaries.   
   > > >   
   > > > The situation I was in was that I was running   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)