From: muta...@gmail.com   
      
   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?   
      
   Icing on the cake is huge memory model. If we can get that   
   to work on the 80286, that would be ideal.   
      
   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.   
      
   > > 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.   
      
   > 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.   
      
   > > > 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   
   > > DOS programs in the 1990s, at work, on machines   
   > > with something like 16 MiB or 32 MiB of memory,   
   > > and I was running out of memory because I was   
   > > hitting the 1 MiB barrier.   
   > >   
   > > It is only recently that I realized it didn't   
   > > need to be like that. It was possible to avoid   
   > > hardcoding the number 4.   
      
   > There is more to this. There was a lot of programs   
   > that hardcoded something like 2M, 4M or similar.   
   > They were not affected by 1M barrier and typically   
   > would not even run if virtual memory was restricted to 1M.   
      
   What 2 MB hardcoding?   
      
   > Yes, is was possible to avoid that, but such programs   
   > are part of difference between real and fantasy world.   
      
   My question is not about the real world being shitty.   
      
   My question is not about running every single shitty   
   program ever written.   
      
   Why do you keep pretending that that is my question?   
      
   You can call it a "fantasy world" if you want, that is   
   closer to my question. But it's not really a fantasy,   
   because MY applications EXIST. I want to make sure   
   that MY applications work with a 5-bit shift, or (possibly)   
   even on the 80286 in PM16 (willing to negotiate).   
      
   > More generaly, politicians and marketing folk like   
   > to talk about "potential" saying that someting has   
   > say "huge potential". In plain language, that means   
   > future possiblities, which may materialize or not.   
   > But while gains are in future and uncertain, costs   
   > are today. Extra connector for future device, extra   
   > bits reserved for some future use have immediate   
   > cost. Your "flexible shift" has its cost too. You   
   > may think that it is worth paying.   
      
   From the software side, the cost is entirely being   
   born by me, and I am already paying it.   
      
   It's true that I asked what the hardware costs   
   would be to match what I can do in software.   
      
   And the answer was 5% on 8086 (in which case,   
   forget it), and approximately 0% on 80286 (in   
   which case, I'd like to have it).   
      
   > In general I like   
   > to "future proof" my designs. But whatever rules I   
   > may invent, I have no way to force other folks to   
   > follow them.   
      
   I never suggested that I intended to force every   
   programmer in the world to follow rules that I invent.   
   That is slavery.   
      
   I will call programmers that don't follow good rules   
   jackasses though. That is freedom of speech.   
      
   > I have seen folks breaking rules simply   
   > because they did not understand why the rule is there.   
   > Or folks felt that something was "too hard" (when for   
   > me it looked essentially efortless).   
      
   All fine by me.   
      
   My own DOS executables have a 4-bit shift hardcoded   
   in them too, because I still don't clearly understand   
   the rules.   
      
   > > interest, but it would have been nice if I knew   
   > > that the software was all set up correctly, and   
   > > a monopoly with patent protection was standing in   
   > > the way.   
      
   > If you assume that your program were "well behaved",   
   > then all you need is appropriate version of DOS   
   > (or DOS extender). I think that "loader" programs   
   > that could do this were available. Certainly effort   
   > to write such program would be much smaller that   
   > effort needed to design and manufacture processor.   
      
   Ok. This is what interests me, and I am only at the   
   beginning of trying to understand it. My own software   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)