Running 32-bit applications under 64-bit Windows, especially Vista SP2

Discussion in 'Windows 64bit' started by Guest, Jul 11, 2009.

  1. Guest

    Guest Guest

    When 32-bit applications run under 64-bit versions of
    Windows, are they restricted to running in the lowest
    4 GB of memory so that no memory mapping is needed,
    or do the 64-bit versions of Windows provide enough
    memory mapping that the programs can run when
    located above 4 GB? I'm most interested in Vista SP2,
    but would also like similar information about the other
    64-bit versions of Windows.

    If they cannot run above the 4 GB limit that 32-bit addresses
    can specify, it seems that 64-bit Windows needs to offer
    more information about which programs are using memory
    below 4 GB, and how to tell which programs are running
    in 32-bit mode and which in 64-bit mode.

    Robert Miles
     
    Guest, Jul 11, 2009
    #1
    1. Advertising

  2. <> wrote:

    >When 32-bit applications run under 64-bit versions of
    >Windows, are they restricted to running in the lowest
    >4 GB of memory so that no memory mapping is needed,
    >or do the 64-bit versions of Windows provide enough
    >memory mapping that the programs can run when
    >located above 4 GB? I'm most interested in Vista SP2,
    >but would also like similar information about the other
    >64-bit versions of Windows.


    No, yes. There is no above/below concept for 32-bit applications. They get
    a 4GB pool, and that's that.

    >If they cannot run above the 4 GB limit that 32-bit addresses
    >can specify, it seems that 64-bit Windows needs to offer
    >more information about which programs are using memory
    >below 4 GB, and how to tell which programs are running
    >in 32-bit mode and which in 64-bit mode.


    They don't know they're running on 64-bit Windows, unless they're looking
    specifically for that scenario (it can be detected). More importantly,
    they don't generally need to know.

    Where are these questions leading? What's the underlying scenario that's
    brought them up?

    --
    Steve Foster [SBS MVP]
    ---------------------------------------
    MVPs do not work for Microsoft. Please reply only to the newsgroups.
    For SSL Certificates, Domains, etc, visit.: https://netshop.virtual-isp.net
     
    Steve Foster [SBS MVP], Jul 13, 2009
    #2
    1. Advertising

  3. Guest

    Guest Guest

    "Steve Foster [SBS MVP]" <> wrote in message
    news:...
    > <> wrote:
    >
    >>When 32-bit applications run under 64-bit versions of
    >>Windows, are they restricted to running in the lowest
    >>4 GB of memory so that no memory mapping is needed,
    >>or do the 64-bit versions of Windows provide enough
    >>memory mapping that the programs can run when
    >>located above 4 GB? I'm most interested in Vista SP2,
    >>but would also like similar information about the other
    >>64-bit versions of Windows.

    >
    > No, yes. There is no above/below concept for 32-bit applications. They get
    > a 4GB pool, and that's that.
    >
    >>If they cannot run above the 4 GB limit that 32-bit addresses
    >>can specify, it seems that 64-bit Windows needs to offer
    >>more information about which programs are using memory
    >>below 4 GB, and how to tell which programs are running
    >>in 32-bit mode and which in 64-bit mode.

    >
    > They don't know they're running on 64-bit Windows, unless they're looking
    > specifically for that scenario (it can be detected). More importantly,
    > they don't generally need to know.
    >
    > Where are these questions leading? What's the underlying scenario that's
    > brought them up?
    >
    > --
    > Steve Foster [SBS MVP]
    > ---------------------------------------

    ..
    Trying to find a reason for the assorted problems I've seen on my 64-bit
    8 GB computer for the assorted freezes and drastic slowdowns I often
    see when running BOINC workunits, with BOINC allowed to use up
    to 50% of the physical memory and with nearly all the workunits compiled
    to run in 32-bit mode instead of 64-bit mode.

    If all the 32-bit programs on the machine share one 4 GB pool, even
    though there are 4 CPU cores within the CPU, that's a good enough
    explanation, since I've seen no sign that BOINC applies any separate
    memory usage limits to workunits running in 32-bit mode.

    Asking for similar information for other 64-bit versions of Windows is
    mainly intended to get help for the BOINC developers.

    Robert Miles
     
    Guest, Jul 14, 2009
    #3
  4. Guest

    Bo Persson Guest

    wrote:
    > "Steve Foster [SBS MVP]" <> wrote in
    > message news:...
    >> <> wrote:
    >>
    >>> When 32-bit applications run under 64-bit versions of
    >>> Windows, are they restricted to running in the lowest
    >>> 4 GB of memory so that no memory mapping is needed,
    >>> or do the 64-bit versions of Windows provide enough
    >>> memory mapping that the programs can run when
    >>> located above 4 GB? I'm most interested in Vista SP2,
    >>> but would also like similar information about the other
    >>> 64-bit versions of Windows.

    >>
    >> No, yes. There is no above/below concept for 32-bit applications.
    >> They get a 4GB pool, and that's that.
    >>
    >>> If they cannot run above the 4 GB limit that 32-bit addresses
    >>> can specify, it seems that 64-bit Windows needs to offer
    >>> more information about which programs are using memory
    >>> below 4 GB, and how to tell which programs are running
    >>> in 32-bit mode and which in 64-bit mode.

    >>
    >> They don't know they're running on 64-bit Windows, unless they're
    >> looking specifically for that scenario (it can be detected). More
    >> importantly, they don't generally need to know.
    >>
    >> Where are these questions leading? What's the underlying scenario
    >> that's brought them up?
    >>
    >> --
    >> Steve Foster [SBS MVP]
    >> ---------------------------------------

    > .
    > Trying to find a reason for the assorted problems I've seen on my
    > 64-bit 8 GB computer for the assorted freezes and drastic slowdowns
    > I often see when running BOINC workunits, with BOINC allowed to use
    > up to 50% of the physical memory and with nearly all the workunits
    > compiled to run in 32-bit mode instead of 64-bit mode.
    >
    > If all the 32-bit programs on the machine share one 4 GB pool, even
    > though there are 4 CPU cores within the CPU, that's a good enough
    > explanation, since I've seen no sign that BOINC applies any separate
    > memory usage limits to workunits running in 32-bit mode.
    >
    > Asking for similar information for other 64-bit versions of Windows
    > is mainly intended to get help for the BOINC developers.
    >
    > Robert Miles


    Each program will get up to 4 GB of *virtual* address space,
    independently of each other. The system will use RAM and disk, as
    needed, to back up the use.

    On the other hand, 4 programs actually using its 4 GB each will run
    slower than a single program. The difference should show up as
    increased disk activity.


    Bo Persson
     
    Bo Persson, Jul 14, 2009
    #4
  5. <> wrote:

    >Trying to find a reason for the assorted problems I've seen on my 64-bit
    >8 GB computer for the assorted freezes and drastic slowdowns I often
    >see when running BOINC workunits, with BOINC allowed to use up
    >to 50% of the physical memory and with nearly all the workunits compiled
    >to run in 32-bit mode instead of 64-bit mode.


    Workunits aren't compiled. You can run either 32-bit or 64-bit BOINC
    clients - both process the same workunits (at least, AIUI).

    If you shut down BOINC, do the freezes and slowdowns stop?

    >
    >If all the 32-bit programs on the machine share one 4 GB pool, even
    >though there are 4 CPU cores within the CPU, that's a good enough
    >explanation, since I've seen no sign that BOINC applies any separate
    >memory usage limits to workunits running in 32-bit mode.


    They don't.


    >Asking for similar information for other 64-bit versions of Windows is
    >mainly intended to get help for the BOINC developers.


    All x64 versions of Windows use the same 32-bit subsystem - WOW64.

    Since BOINC is available in both 32 and 64 bit versions, it'd make more
    sense to run the 64-bit version if you're running Windows x64.

    --
    Steve Foster [SBS MVP]
    ---------------------------------------
    MVPs do not work for Microsoft. Please reply only to the newsgroups.
    For SSL Certificates, Domains, etc, visit.: https://netshop.virtual-isp.net
     
    Steve Foster [SBS MVP], Jul 21, 2009
    #5
  6. Guest

    Guest Guest

    "Steve Foster [SBS MVP]" <> wrote in message
    news:...
    > <> wrote:
    >
    >>Trying to find a reason for the assorted problems I've seen on my 64-bit
    >>8 GB computer for the assorted freezes and drastic slowdowns I often
    >>see when running BOINC workunits, with BOINC allowed to use up
    >>to 50% of the physical memory and with nearly all the workunits compiled
    >>to run in 32-bit mode instead of 64-bit mode.

    >
    > Workunits aren't compiled. You can run either 32-bit or 64-bit BOINC
    > clients - both process the same workunits (at least, AIUI).

    ..
    Looks like we aren't quite agreeing on the terminology to use. Each
    workunit
    specifies a workunit-specific program to run, with the BOINC client
    controlling which workunits get to run at any particular time on each of the
    CPU cores (and the GPU, if present), and which get at least virtual memory
    reserved but are currently suspended. I'm not sure if it also controls
    swapping
    out the suspended workunits to the swap file. Nearly all the workunits
    available for my field of interest specify 32-bit workunit-specific
    programs.

    The BOINC client uses only about 6 megabytes; the workunit-specific
    programs often use much more (500 megabytes and up), with one
    workunit-specific program supposed to be running on each CPU core at
    any time.

    There's also a BOINC manager program that acts as a user interface for
    the BOINC client.
    >
    > If you shut down BOINC, do the freezes and slowdowns stop?
    >

    Hard for me to do without aborting all the workunits currently in progress -
    the freezes and slowdowns usually also freeze or slow down the BOINC
    manager program, and the process that starts it when you click on its
    icon.

    If I manage to suspend the BOINC client, and therefore all the
    workunit-specific programs, I free the CPU time but not the memory
    reserved for the various workunits. This does not stop the freezes and
    slowdowns.
    >>
    >>If all the 32-bit programs on the machine share one 4 GB pool, even
    >>though there are 4 CPU cores within the CPU, that's a good enough
    >>explanation, since I've seen no sign that BOINC applies any separate
    >>memory usage limits to workunits running in 32-bit mode.

    >
    > They don't.
    >

    Whether it's important depends on how independant the 4 GB space
    assigned to each workunit using a 32-bit workunit specific program
    is of the 4 GB space assigned to any other workunits, suspended or
    not, assigned to the same CPU core, the 4 GB spaces assigned to
    workunits assigned to different CPU cores, and of the 4 GB space
    assigned to any other non-workunit 32-bit program running on the same
    CPU core.
    >
    >>Asking for similar information for other 64-bit versions of Windows is
    >>mainly intended to get help for the BOINC developers.

    >
    > All x64 versions of Windows use the same 32-bit subsystem - WOW64.

    ..
    It's not immediately clear whether WOW64 or the BOINC client is
    responsible for deciding how independent these 4 GB spaces are.
    >
    > Since BOINC is available in both 32 and 64 bit versions, it'd make more
    > sense to run the 64-bit version if you're running Windows x64.
    >

    It's hard to tell the difference, but as far as I know I'm using a 64-bit
    BOINC client, with nearly all the workunit-specific programs 32-bit.
    I haven't found information on whether the BOINC manager program
    is 32-bit or 64-bit.

    For this reason, I'd like a way to tell the difference between 32-bit
    programs and 64-bit programs if the program developers don't see
    it useful to tell me which they are.
    > --
    > Steve Foster [SBS MVP]
    > ---------------------------------------
    > MVPs do not work for Microsoft. Please reply only to the newsgroups.
    > For SSL Certificates, Domains, etc, visit.:
    > https://netshop.virtual-isp.net


    Robert Miles
     
    Guest, Jul 24, 2009
    #6
  7. Guest

    Dave Warren Guest

    In message <#cOu$>
    <> was claimed to have wrote:

    >For this reason, I'd like a way to tell the difference between 32-bit
    >programs and 64-bit programs if the program developers don't see
    >it useful to tell me which they are.


    IIRC, boinc runs each WU in a separate process, correct? If so, modern
    versions of Windows' Task Manager show a "*32" beside 32-bit processes.

    However, whether an app is 32-bit or 64-bit is likely not related to any
    lockups or stalls, I'd probably look to memory bandwidth saturation.

    One other thought, you're not on a P4 based CPU are you? If so, turn
    off Hyperthreading in the BIOS and see if the problem goes away.
     
    Dave Warren, Jul 24, 2009
    #7
  8. <> wrote:

    >"Steve Foster [SBS MVP]" <> wrote in message
    >news:...
    >><> wrote:
    >>
    >>>Trying to find a reason for the assorted problems I've seen on my 64-bit
    >>>8 GB computer for the assorted freezes and drastic slowdowns I often
    >>>see when running BOINC workunits, with BOINC allowed to use up
    >>>to 50% of the physical memory and with nearly all the workunits compiled
    >>>to run in 32-bit mode instead of 64-bit mode.

    >>
    >>Workunits aren't compiled. You can run either 32-bit or 64-bit BOINC
    >>clients - both process the same workunits (at least, AIUI).

    >.
    >Looks like we aren't quite agreeing on the terminology to use. Each
    >workunit
    >specifies a workunit-specific program to run, with the BOINC client
    >controlling which workunits get to run at any particular time on each of
    >the
    >CPU cores (and the GPU, if present), and which get at least virtual memory
    >reserved but are currently suspended. I'm not sure if it also controls
    >swapping
    >out the suspended workunits to the swap file. Nearly all the workunits
    >available for my field of interest specify 32-bit workunit-specific
    >programs.


    Work units do not specify anything (other than what type they are).

    The BOINC client downloads the right sort of application to process the
    workunits automatically. I thought that the 64-bit BOINC client would
    download 64-bit applications, but it appears that the SETI@Home folks
    haven't written/ported these applications to x64 yet (on Windows at
    least), so the BOINC client actually runs 32-bit crunching applications
    regardless of whether it is 32 or 64 bit itself.


    >The BOINC client uses only about 6 megabytes; the workunit-specific
    >programs often use much more (500 megabytes and up), with one
    >workunit-specific program supposed to be running on each CPU core at
    >any time.


    I've never seen a crunching application use that much memory. SETI@Home
    Enhanced usually uses between 30-50MB, Astropulse a bit more. Note that
    S@H don't seem to be sending out many Astropulse work units at present
    (all my machines are only getting S@H Enhanced work units to process, and
    have been for the last week or two).

    If you let it, the BOINC client will indeed run an instance of the
    crunching applications for each CPU core.

    >There's also a BOINC manager program that acts as a user interface for
    >the BOINC client.
    >>
    >>If you shut down BOINC, do the freezes and slowdowns stop?
    >>

    >Hard for me to do without aborting all the workunits currently in progress
    >-
    >the freezes and slowdowns usually also freeze or slow down the BOINC
    >manager program, and the process that starts it when you click on its
    >icon.


    Stopping the BOINC client (and therefore the crunching applications) does
    not abort work units. All computation carried out so far is preserved, and
    work resumes from the same point when the BOINC client is restarted.
    Obviously, if the BOINC client is down for too long, the deadline for
    reporting completed units might expire, but those are generally fairly
    generous.

    Incidentally, do you run the BOINC client as a service (you have to
    specify the Advanced settings during install to get it installed as a
    service)?

    >If I manage to suspend the BOINC client, and therefore all the
    >workunit-specific programs, I free the CPU time but not the memory
    >reserved for the various workunits. This does not stop the freezes and
    >slowdowns.
    >>>
    >>>If all the 32-bit programs on the machine share one 4 GB pool, even
    >>>though there are 4 CPU cores within the CPU, that's a good enough
    >>>explanation, since I've seen no sign that BOINC applies any separate
    >>>memory usage limits to workunits running in 32-bit mode.

    >>
    >>They don't.
    >>

    >Whether it's important depends on how independant the 4 GB space
    >assigned to each workunit using a 32-bit workunit specific program
    >is of the 4 GB space assigned to any other workunits, suspended or
    >not, assigned to the same CPU core, the 4 GB spaces assigned to
    >workunits assigned to different CPU cores, and of the 4 GB space
    >assigned to any other non-workunit 32-bit program running on the same
    >CPU core.


    Is this supposed to mean something? It's complete gibberish.





    >>>Asking for similar information for other 64-bit versions of Windows is
    >>>mainly intended to get help for the BOINC developers.

    >>
    >>All x64 versions of Windows use the same 32-bit subsystem - WOW64.

    >.
    >It's not immediately clear whether WOW64 or the BOINC client is
    >responsible for deciding how independent these 4 GB spaces are.


    There is no decision to make. Every 32-bit application gets its own
    distinct 4GB virtual memory space (ie each 32-bit application can request
    a memory allocation of up to 4GB for itself [if it's LARGEMEMORYAWARE, 2GB
    otherwise]). There is no sharing, no overlap, no CPU dependency, nothing.
    The OS manages the memory allocation of RAM or paging file as the
    applications request memory, just like every other Windows application.


    >>Since BOINC is available in both 32 and 64 bit versions, it'd make more
    >>sense to run the 64-bit version if you're running Windows x64.
    >>

    >It's hard to tell the difference, but as far as I know I'm using a 64-bit
    >BOINC client, with nearly all the workunit-specific programs 32-bit.
    >I haven't found information on whether the BOINC manager program
    >is 32-bit or 64-bit.


    If you downloaded the x64 version, you're running the 64-bit BOINC client.
    As we've discovered (and discussed), that doesn't mean all the constituent
    parts are x64.

    >For this reason, I'd like a way to tell the difference between 32-bit
    >programs and 64-bit programs if the program developers don't see
    >it useful to tell me which they are.


    You can tell whether any particular process is 32-bit or 64-bit from Task
    Manager. 32-bit processes are marked with "*32" after the executable name,
    64-bit processes have no suffix.

    --
    Steve Foster [SBS MVP]
    ---------------------------------------
    MVPs do not work for Microsoft. Please reply only to the newsgroups.
    For SSL Certificates, Domains, etc, visit.: https://netshop.virtual-isp.net
     
    Steve Foster [SBS MVP], Jul 26, 2009
    #8
  9. Guest

    Guest Guest

    "Dave Warren" <> wrote in message
    news:...
    > In message <#cOu$>
    > <> was claimed to have wrote:
    >
    >>For this reason, I'd like a way to tell the difference between 32-bit
    >>programs and 64-bit programs if the program developers don't see
    >>it useful to tell me which they are.

    >
    > IIRC, boinc runs each WU in a separate process, correct? If so, modern
    > versions of Windows' Task Manager show a "*32" beside 32-bit processes.
    >
    > However, whether an app is 32-bit or 64-bit is likely not related to any
    > lockups or stalls, I'd probably look to memory bandwidth saturation.
    >
    > One other thought, you're not on a P4 based CPU are you? If so, turn
    > off Hyperthreading in the BIOS and see if the problem goes away.


    ..
    Thank you.

    I've now seen a similar problem on my 32-bit Vista SP2 machine,
    which only has 2 GB. To me this suggests that the problem is
    actually that BOINC can't handle using a full 50% of the memory
    or more well. I've currently set it to allow BOINC to use only
    40% of the physical memory on my 64-bit machine, and this seems
    to have eliminated most of the hard faults and most of the slowdowns

    How do I check for memory bandwidth problems?

    The CPU is more recent than P4, has 4 CPU cores, and does not
    have hyperthreading.

    Robert Miles
     
    Guest, Aug 6, 2009
    #9
  10. Guest

    Guest Guest

    "Steve Foster [SBS MVP]" <> wrote in message
    news:...
    > <> wrote:
    >
    >>"Steve Foster [SBS MVP]" <> wrote in message
    >>news:...
    >>><> wrote:
    >>>
    >>>>Trying to find a reason for the assorted problems I've seen on my 64-bit
    >>>>8 GB computer for the assorted freezes and drastic slowdowns I often
    >>>>see when running BOINC workunits, with BOINC allowed to use up
    >>>>to 50% of the physical memory and with nearly all the workunits compiled
    >>>>to run in 32-bit mode instead of 64-bit mode.
    >>>
    >>>Workunits aren't compiled. You can run either 32-bit or 64-bit BOINC
    >>>clients - both process the same workunits (at least, AIUI).

    >>.
    >>Looks like we aren't quite agreeing on the terminology to use. Each
    >>workunit
    >>specifies a workunit-specific program to run, with the BOINC client
    >>controlling which workunits get to run at any particular time on each of
    >>the
    >>CPU cores (and the GPU, if present), and which get at least virtual memory
    >>reserved but are currently suspended. I'm not sure if it also controls
    >>swapping
    >>out the suspended workunits to the swap file. Nearly all the workunits
    >>available for my field of interest specify 32-bit workunit-specific
    >>programs.

    >
    > Work units do not specify anything (other than what type they are).
    >
    > The BOINC client downloads the right sort of application to process the
    > workunits automatically. I thought that the 64-bit BOINC client would
    > download 64-bit applications, but it appears that the SETI@Home folks
    > haven't written/ported these applications to x64 yet (on Windows at
    > least), so the BOINC client actually runs 32-bit crunching applications
    > regardless of whether it is 32 or 64 bit itself.
    >

    The BOINC projects I'm subscribed to do not inclide SETI@Home,
    and few if any of them have 64-bit applications ready to run their
    workunits.

    All of them seem to know that the 64-bit version of BOINC can run
    workunits with only 32-bit applications ready, IF those applications
    can be downloaded using the names the 64-bit applications should have
    if they were ready.
    >
    >>The BOINC client uses only about 6 megabytes; the workunit-specific
    >>programs often use much more (500 megabytes and up), with one
    >>workunit-specific program supposed to be running on each CPU core at
    >>any time.

    >
    > I've never seen a crunching application use that much memory. SETI@Home
    > Enhanced usually uses between 30-50MB, Astropulse a bit more. Note that
    > S@H don't seem to be sending out many Astropulse work units at present
    > (all my machines are only getting S@H Enhanced work units to process, and
    > have been for the last week or two).

    ..
    I just saw The Lattice Project give me three workunits that required 750 MB
    each to run the application; they sat to occasionally expect some that take
    1 GB.
    BOINC tried to run all three of the 750 MB workunits at the same time,
    which may be part of ny recent problems I've heard that Superlink@Technion
    also needs over 500 MB to run each workunit, but haven't been able to
    observe
    one in progress yet. I regularly have workunits from Rosetta@home,
    RALPH@home, and some of the World Community Grid projects that take
    500 MB to run. The application programs are probably smaller, but the total
    memory they take to run is more important.
    >
    > If you let it, the BOINC client will indeed run an instance of the
    > crunching applications for each CPU core.

    ..
    I normally run a separate workunit on each of the 4 CPU cores; none of
    the application programs can handle spreading work for the same
    workunit to more than one CPU core.
    >
    >>There's also a BOINC manager program that acts as a user interface for
    >>the BOINC client.
    >>>
    >>>If you shut down BOINC, do the freezes and slowdowns stop?
    >>>

    >>Hard for me to do without aborting all the workunits currently in
    >>progress -
    >>the freezes and slowdowns usually also freeze or slow down the BOINC
    >>manager program, and the process that starts it when you click on its
    >>icon.

    >
    > Stopping the BOINC client (and therefore the crunching applications) does
    > not abort work units. All computation carried out so far is preserved, and
    > work resumes from the same point when the BOINC client is restarted.
    > Obviously, if the BOINC client is down for too long, the deadline for
    > reporting completed units might expire, but those are generally fairly
    > generous.

    ..
    Then maybe I don't know enough about how to stop and restart it; the
    way I'm familiar with does abort all the workunits in progress.
    >
    > Incidentally, do you run the BOINC client as a service (you have to
    > specify the Advanced settings during install to get it installed as a
    > service)?
    >

    As a service on my 32-bit machine, but not also on my 64-bit machine.
    ..
    >>If I manage to suspend the BOINC client, and therefore all the
    >>workunit-specific programs, I free the CPU time but not the memory
    >>reserved for the various workunits. This does not stop the freezes and
    >>slowdowns.
    >>>>
    >>>>If all the 32-bit programs on the machine share one 4 GB pool, even
    >>>>though there are 4 CPU cores within the CPU, that's a good enough
    >>>>explanation, since I've seen no sign that BOINC applies any separate
    >>>>memory usage limits to workunits running in 32-bit mode.
    >>>
    >>>They don't.
    >>>

    >>Whether it's important depends on how independant the 4 GB space
    >>assigned to each workunit using a 32-bit workunit specific program
    >>is of the 4 GB space assigned to any other workunits, suspended or
    >>not, assigned to the same CPU core, the 4 GB spaces assigned to
    >>workunits assigned to different CPU cores, and of the 4 GB space
    >>assigned to any other non-workunit 32-bit program running on the same
    >>CPU core.

    >
    > Is this supposed to mean something? It's complete gibberish.
    >

    It was supposed to mean that the memory mapping for different workunits
    that get time slices on the same CPU core might not be fully independent,
    but it now seems more likely that BOINC is poor at assigning more than
    50% of the physical memory at the same time.
    >
    >>>>Asking for similar information for other 64-bit versions of Windows is
    >>>>mainly intended to get help for the BOINC developers.
    >>>
    >>>All x64 versions of Windows use the same 32-bit subsystem - WOW64.

    >>.
    >>It's not immediately clear whether WOW64 or the BOINC client is
    >>responsible for deciding how independent these 4 GB spaces are.

    >
    > There is no decision to make. Every 32-bit application gets its own
    > distinct 4GB virtual memory space (ie each 32-bit application can request
    > a memory allocation of up to 4GB for itself [if it's LARGEMEMORYAWARE, 2GB
    > otherwise]). There is no sharing, no overlap, no CPU dependency, nothing.
    > The OS manages the memory allocation of RAM or paging file as the
    > applications request memory, just like every other Windows application.
    >
    >
    >>>Since BOINC is available in both 32 and 64 bit versions, it'd make more
    >>>sense to run the 64-bit version if you're running Windows x64.
    >>>

    >>It's hard to tell the difference, but as far as I know I'm using a 64-bit
    >>BOINC client, with nearly all the workunit-specific programs 32-bit.
    >>I haven't found information on whether the BOINC manager program
    >>is 32-bit or 64-bit.

    >
    > If you downloaded the x64 version, you're running the 64-bit BOINC client.
    > As we've discovered (and discussed), that doesn't mean all the constituent
    > parts are x64.

    ..
    I have the 64-bit client, but nearly all of the application programs for
    specific workunits are available only in a 32-bit version.
    >
    >>For this reason, I'd like a way to tell the difference between 32-bit
    >>programs and 64-bit programs if the program developers don't see
    >>it useful to tell me which they are.

    >
    > You can tell whether any particular process is 32-bit or 64-bit from Task
    > Manager. 32-bit processes are marked with "*32" after the executable name,
    > 64-bit processes have no suffix.
    >
    > --
    > Steve Foster [SBS MVP]
    > ---------------------------------------
    > MVPs do not work for Microsoft. Please reply only to the newsgroups.
    > For SSL Certificates, Domains, etc, visit.:
    > https://netshop.virtual-isp.net

    ..
    Thanks, the *32 imformation was much of what I needed.

    Robert Miles
     
    Guest, Aug 6, 2009
    #10
    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. Will
    Replies:
    2
    Views:
    682
    Charlie Russel - MVP
    Nov 7, 2006
  2. =?Utf-8?B?SmliZXkgSmFjb2I=?=

    32-bit applications on 64-bit Vista

    =?Utf-8?B?SmliZXkgSmFjb2I=?=, Jul 15, 2007, in forum: Windows 64bit
    Replies:
    4
    Views:
    386
    R. C. White
    Jul 17, 2007
  3. Replies:
    5
    Views:
    972
  4. Jrdn2

    32-bit applications running on 64-bit OS

    Jrdn2, Dec 5, 2007, in forum: Windows 64bit
    Replies:
    6
    Views:
    565
    Jrdn2
    Dec 10, 2007
  5. Peter Wagner

    A router running under WinXP runs under Windows Vista too?

    Peter Wagner, Jan 30, 2008, in forum: Wireless Networking
    Replies:
    12
    Views:
    995
    Peter Wagner
    Feb 4, 2008
Loading...

Share This Page