From: muta...@gmail.com   
      
   On Tuesday, October 25, 2022 at 9:40:34 AM UTC+8, anti...@math.uni.wroc.pl   
   wrote:   
      
   Thankyou for your informative reply!   
      
   > > 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.   
      
   Sorry for my bad English. I expect the function itself to be   
   less than 64k in size.   
      
   > In principle compiler can split   
   > function into multiple segments.   
      
   It is the linker I am worried about. I believe it needs to add   
   padding (x'00') before placing the code in the executable   
   if the executable size is going to cross a 64k boundary   
   while laying out the function (or maybe object file - I'm   
   not sure).   
      
   > > 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.   
      
   I'm happy to produce multiple version of my 16-bit   
   executable.   
      
   The "universal" one which relies on the OS, and multiple   
   others hardcoded to specific known segment manipulation   
   strategies.   
      
   > I do not know what you wrote. But people wanted smoothly   
   > working editors, which involved direct writes to screen   
   > memory.   
      
   I am interested in what "people" want to some extent, but   
   I'm also interested in a solution that is clean.   
      
   If the clean solution is pretty crappy on an 8086, but a user   
   can't tell the difference on an 80386, then I am happy to have   
   two versions of my executable.   
      
   However, I dispute this rationale. ANSI text was slow under   
   MSDOS because MSDOS used the BIOS. If MSDOS itself   
   had done the direct screen writes, there would probably   
   not have been a need for every single application to do   
   this.   
      
   Furthermore, even if there was some reason even MSDOS   
   couldn't have solved the problem, and the problem had to be   
   relegated to the application, there is still no reason why   
   MSDOS couldn't have returned an address of screen memory   
   appropriate to whatever segment shift was in effect.   
      
   > 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).   
      
   I'm happy to run in kernel mode. No worse off compared   
   to the 8086.   
      
   > 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.   
      
   I don't particularly want to change shortcuts people   
   took to deal with real world constraints.   
      
   I just want to eliminate the shortcuts now that the   
   storm is over. For my own applications at least.   
      
   Also, this assumes that the hardware progressed at   
   exactly the pace it had. If there had been a 200 year   
   delay between the 80286 and the 80386, and a 500   
   year delay between the 8086 and 80286, how would   
   you develop the software?   
      
   Even though the 8086 was going to be there for 500   
   years, it doesn't mean the clock speed wasn't going   
   to change. It may have been fast enough to enable   
   some solutions.   
      
   If we are having this discussion in 1955, you have no   
   idea how fast computers are going to be in 1983.   
      
   Segmentation as a concept could have been thought   
   of in 1955 as something that might happen.   
      
   > > 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).   
      
   I'm happy with that. I just want the binary itself to be clean.   
      
   > 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.   
      
   Yes.   
      
   > 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.   
      
   Maybe a 1-byte NOP zap in MSDOS would force all programs   
   to "opt in"? And let the user make the choice to take their   
   chances?   
      
   I wasn't aware this existed. That would probably cover most   
   of what I want.   
      
   And if PM16 would work then 5-bit segment shifts probably   
   would too.   
      
   So the only thing lacking was an OS function to cover   
   huge memory model?   
      
   > > 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.   
      
   I can't do that, because the 80386 hasn't been invented yet   
   and I'm going to die a year before it does.   
      
   But I expect my RM16 programs to run with a 4 GB address   
   space on an NEC 8086+, or RM16+ of the 80Z86.   
      
   Even though I will take the source code to my grave.   
      
   > 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.   
      
   It's a question from science, more than a problem.   
      
   The question is - how do you future-proof RM16 programs   
   starting circa 70s/80s?   
      
   Assuming you're not rushing to market.   
      
   > In nice world you can recompile, no reason to care about   
   > binaries. The _only_ reasons for caring about binaries   
   > are shitty ones.   
      
   Perhaps.   
      
   > > I'm interested in the 8086 executables, and I want them   
   > > to be clean, not kludged with conditional execution to   
   > > load strange loaders or thunking or god knows what   
   > > else.   
   >   
   > I think you miss the point: this conditional code is part   
   > of your binary, but _not_ part of you source.   
      
   I don't want it in my binary either.   
      
   And that assumes you know the rules for the 80286 in   
   advance. I don't want rules for an 80286, that hasn't   
   been invented yet, but rules for "who knows what   
   follows the 8086 - it could be an NEC 8086+".   
      
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)