linux-8086.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David O'Shea" <dcoshea@gmail.com>
To: linux-8086@vger.kernel.org
Subject: Re: Memory issues and USB support? (and OpenWatcom)
Date: Thu, 15 Jun 2017 19:48:20 +0930	[thread overview]
Message-ID: <CAN0DjM2tP5nam+nS-uoOGdMZsHb_NJCGACM+=CV9udbSW-Lj2Q@mail.gmail.com> (raw)
In-Reply-To: <20170614022305.615ec8ca@alans-desktop>

On Wed, Jun 14, 2017 at 10:53 AM, Alan Cox <alan@llwyncelyn.cymru> wrote:
> Mostly the latter. If you want the full glorious horror story take a look
> at how windows16 does call stack frame fixup for 16bit apps.
>
> (Short version - each stack frame pushes bp. Windows 16 inc's bp before
> pushing and decs after if the function is far, thus allowing the windows
> OS code to walk the stack frames and modify each far return according to
> what is and isn't in memory and where it moved)

Oh, nice, sort of!  I found
https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=11203
which explains it in more words, but I probably would have understood
your explanation if I had thought about it some more :)

> We could modify the compiler to do that, but it's up there with coding
> while drunk on 'good idea' rating.

Yeah, it was pointed out in the comments on the above article that if
you corrupt your stack you're going to make the kernel corrupt some
other memory.

I presume that modifying far pointers to code within the code (rather
than within the stack as is covered above) on Win16 relies on having a
relocation table, and ELKS binaries don't have relocation tables since
they're small model, correct?

> That was more because a DOS program owns all of memory so you don't know
> how much to give it.

Oh yeah, of course, thanks!

>> And regardless of moving away from tiny model, I gather that moving to
>> OpenWatcom just for the optimisations and ANSI C would potentially be
>> worthwhile?
>
> 16bit gcc is probably better.

I was thinking that at least OpenWatcom is maintained, but I didn't
think to check if anyone had resurrected 16-bit GCC in the last 3
months :)

Thanks!
David

      reply	other threads:[~2017-06-15 10:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-11 14:09 Memory issues and USB support? (and OpenWatcom) David O'Shea
2017-06-11 14:54 ` Alan Cox
2017-06-12  4:05   ` David O'Shea
2017-06-14  1:23     ` Alan Cox
2017-06-15 10:18       ` David O'Shea [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAN0DjM2tP5nam+nS-uoOGdMZsHb_NJCGACM+=CV9udbSW-Lj2Q@mail.gmail.com' \
    --to=dcoshea@gmail.com \
    --cc=linux-8086@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).