Re: Several Perl Questions - Nov. 5, 2013

Discussion in 'Perl Misc' started by Peter J. Holzer, Nov 5, 2013.

  1. On 2013-11-05 15:05, Ben Morrow <> wrote:
    > Quoth Henry Law <>:
    >> On 05/11/13 06:16, E.D.G. wrote:
    >> > Can a 64 bit Perl version be run on a computer that is using a 32
    >> > bit Windows operating system if the computer has a 64 bit processor?

    >>
    >> This is not a Perl question. But the answer is "no": if a computer runs
    >> a 32-bit operating system it's a 32-bit computer, irrespective of the
    >> processor architecture.

    >
    > That's not actually true, though it is true that 32bit Windows won't run
    > 64bit executables. 16bit Windows used to run 32bit executables just
    > fine, and Mac OS X for quite a long time had a 32bit kernel that was
    > capable of running 64bit user processes.


    There is always the question what "16 bit", "32 bit" and "64 bit" means.
    On some architectures, there were just additional instructions to access
    the longer registers. On others (like x86) there is no binary
    compatibility: You could compile a program to access EAX in 16-bit mode
    or in 32-bit mode, but the machine code would be different, and I think
    the same is true for 32/64bit x86 code. On MS-DOS that mattered little
    because there was no hardware protection anyway, so any executable could
    just switch to 32-bit protected mode (and back into real mode[1] before
    exit), but any real OS (starting with Xenix-286 or protected mode
    Windows) needed to be able to set up 32-bit segments to run "real" 32
    bit executables, but without that it could of course run programs which
    just accessed the 32 bit integer registers (but only for computation,
    not as pointers). I'd hesitate to call Win95 with the Win32 subsystem a
    "16 bit OS": While large parts of it were (AIUI) still running in 16 bit
    protected mode, some parts (especially those dealing with 32 bit
    processes) were running in 32 bit mode (the segmented x86 architecture
    made stuff like that almost natural). I don't know about MacOS, but I
    guess you are talking about x86 here, too (AFAIK, Apple never sold
    machines with 64 bit POWER chips).

    hp

    [1] Although the original 386 needed a hardware reset for that

    PS: I'm currently running a 64bit Linux kernel beneath a 32bit Linux
    userland. Debian is supposedly multi-architecture capable, so I
    should be able to do a gradual upgrade to a 64 bit userland, too.

    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
     
    Peter J. Holzer, Nov 5, 2013
    #1
    1. Advertising

  2. On 2013-11-05 22:05, Ben Morrow <> wrote:
    >
    > Quoth "Peter J. Holzer" <>:
    >> On 2013-11-05 15:05, Ben Morrow <> wrote:
    >> >
    >> > That's not actually true, though it is true that 32bit Windows won't run
    >> > 64bit executables. 16bit Windows used to run 32bit executables just
    >> > fine, and Mac OS X for quite a long time had a 32bit kernel that was
    >> > capable of running 64bit user processes.

    >>
    >> There is always the question what "16 bit", "32 bit" and "64 bit" means.
    >> On some architectures, there were just additional instructions to access
    >> the longer registers. On others (like x86) there is no binary
    >> compatibility: You could compile a program to access EAX in 16-bit mode
    >> or in 32-bit mode, but the machine code would be different, and I think
    >> the same is true for 32/64bit x86 code.

    >
    > That's not quite right: %eax is always a 32bit register, the 16bit
    > version is called %ax and refers to the lower half of %eax.


    That's not what I wrote. I wrote that you could access the 32 bit
    register %eax in 16 bit (real or protected) mode as well as in 32 bit
    (protected) mode, but the actual machine code to do that was different.


    >> On MS-DOS that mattered little because there was no hardware
    >> protection anyway, so any executable could just switch to 32-bit
    >> protected mode (and back into real mode[1] before exit), but any real
    >> OS (starting with Xenix-286 or protected mode Windows) needed to be
    >> able to set up 32-bit segments to run "real" 32 bit executables, but
    >> without that it could of course run programs which just accessed the
    >> 32 bit integer registers (but only for computation, not as pointers).
    >> I'd hesitate to call Win95 with the Win32 subsystem a "16 bit OS":
    >> While large parts of it were (AIUI) still running in 16 bit protected
    >> mode, some parts (especially those dealing with 32 bit processes)
    >> were running in 32 bit mode (the segmented x86 architecture made
    >> stuff like that almost natural).

    >
    > I was talking specifically about Win3.1, which would happily run 32bit
    > processes (presumably they included the appropriate setup code to switch
    > to 32bit mode).


    3.1 was the first Windows version which ran exclusively in protected
    mode. I don't think a user process could switch to 32 bit mode without
    help from the OS. And as Wikipedia reminds me, Windows 3.1 had something
    called "386 enhanced mode". So I'd say that it had at least some 32 bit
    support. Probably not enough to call it a "32 bit OS", but it wasn't
    pure 16 bit, either.

    >> I don't know about MacOS, but I guess you are talking about x86 here,
    >> too (AFAIK, Apple never sold machines with 64 bit POWER chips).

    >
    > 10.4 supported 64bit POSIX apps over a 32bit kernel, on amd64 or ppc
    > (the G5 is 64bit). 10.5 also supported 64bit GUI apps, also amd64 or
    > ppc.


    Same here. There is of course first the question what a "64 bit app" is,
    but assuming that it means an application compiled for the long mode
    instruction set, the OS needs to be able to set up and manage processes
    running in long mode, which means at least that the kernel must know how
    to do that and probably also that some (small) parts of it run in the
    same mode.

    hp

    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
     
    Peter J. Holzer, Nov 7, 2013
    #2
    1. Advertising

  3. Am 07.11.2013 11:20, schrieb Peter J. Holzer:
    > 3.1 was the first Windows version which ran exclusively in protected
    > mode. I don't think a user process could switch to 32 bit mode without
    > help from the OS. And as Wikipedia reminds me, Windows 3.1 had something
    > called "386 enhanced mode". So I'd say that it had at least some 32 bit
    > support. Probably not enough to call it a "32 bit OS", but it wasn't
    > pure 16 bit, either.


    IIRC there was a common hack to get access to more memory, involving
    silently rebooting** (without clearing memory or processor registers or
    so), switching to enhanced mode, copy some part of memory to an address
    between 640k-1kk, silently rebooting again (still without clearing
    memory and registers) and working on as nothing happened beside having
    access to enhanced memory with enhanced mode. Took about 1ms, but was
    often used by games or other application with need of much memory.

    Wasn't really necessory, though in 3.1 windows, more for DOS
    applications, but a user process could switch to 32 bit mode or down to
    16 bit mode without help from OS, just using machine code (via
    assembler) directly.
    I think Win NT was the first windows, where win really controlled what
    you did and not just helped you to operate, but didn't checked for
    misuse. Indeed, in enhanced mode it was possible for an OS to check
    secure for that and probit applications to do random stuff, but 3.1 did
    not yet do that.

    Maybe slightly OT,
    so Greetings,
    Janek


    **rebooting was necessary as an 286 or 386 processor couldn't switch
    while running between old and enhanced mode.
     
    Janek Schleicher, Nov 7, 2013
    #3
  4. On 2013-11-07 13:20, Janek Schleicher <> wrote:
    > Am 07.11.2013 11:20, schrieb Peter J. Holzer:
    >> 3.1 was the first Windows version which ran exclusively in protected
    >> mode. I don't think a user process could switch to 32 bit mode without
    >> help from the OS. And as Wikipedia reminds me, Windows 3.1 had something
    >> called "386 enhanced mode". So I'd say that it had at least some 32 bit
    >> support. Probably not enough to call it a "32 bit OS", but it wasn't
    >> pure 16 bit, either.

    >
    > IIRC there was a common hack to get access to more memory, involving
    > silently rebooting** (without clearing memory or processor registers or
    > so), switching to enhanced mode,

    [...]
    >
    > **rebooting was necessary as an 286 or 386 processor couldn't switch
    > while running between old and enhanced mode.


    Not quite. The 286 could only switch to protected mode by setting the PE
    bit, but not back to real mode (earlier I wrote that the 386 had this
    problem, but I was mistaken). But after a reset the processor always
    started in real mode, so PCs had some circuitry (in the keyboard
    controller, IIRC) to trigger a reset in software. The BIOS then checked
    the reason for the reset, skipped the normal self test and boot
    routines and jumped directly to an address supplied by the OS.
    This was used by OS/2 for task switching between the "DOS box" and other
    OS/2 processes (and the reason why there could be only one DOS box).

    > copy some part of memory to an address between 640k-1kk, silently
    > rebooting again (still without clearing memory and registers) and
    > working on as nothing happened beside having access to enhanced memory
    > with enhanced mode. Took about 1ms, but was often used by games or
    > other application with need of much memory.


    I think you are talking about extended memory here. Many DOS programs
    did that (and there were even drivers for it), but since Windows 3.1 was
    running in protected mode anyway there was no need for that.


    > Wasn't really necessory, though in 3.1 windows, more for DOS
    > applications, but a user process could switch to 32 bit mode or down to
    > 16 bit mode without help from OS, just using machine code (via
    > assembler) directly.


    I very much doubt that. AFAIK a process in ring 3 simply can't do that.

    > I think Win NT was the first windows, where win really controlled what
    > you did and not just helped you to operate, but didn't checked for
    > misuse.


    Windows NT added lots of enhancements (or rather it was a completely
    different OS with a compatible API), but some features are just inherent
    in protected mode.

    hp


    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
     
    Peter J. Holzer, Nov 7, 2013
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Charlton Wilbur

    Re: Several Perl Questions - Nov. 5, 2013

    Charlton Wilbur, Nov 5, 2013, in forum: Perl Misc
    Replies:
    3
    Views:
    139
    Charlton Wilbur
    Nov 11, 2013
  2. John Black

    Re: Several Perl Questions - Nov. 5, 2013

    John Black, Nov 5, 2013, in forum: Perl Misc
    Replies:
    0
    Views:
    130
    John Black
    Nov 5, 2013
  3. Peter J. Holzer

    Re: Several Perl Questions - Nov. 5, 2013

    Peter J. Holzer, Nov 5, 2013, in forum: Perl Misc
    Replies:
    0
    Views:
    123
    Peter J. Holzer
    Nov 5, 2013
  4. Tim McDaniel

    Re: Several Perl Questions - Nov. 5, 2013

    Tim McDaniel, Nov 5, 2013, in forum: Perl Misc
    Replies:
    0
    Views:
    167
    Tim McDaniel
    Nov 5, 2013
  5. Justin C
    Replies:
    0
    Views:
    116
    Justin C
    Nov 6, 2013
Loading...

Share This Page