Re: ramtest.zip Memory test utility, v 0.3 does not work - OS2

This is a discussion on Re: ramtest.zip Memory test utility, v 0.3 does not work - OS2 ; Ilya Zakharevich wrote: > [A complimentary Cc of this posting was sent to > Marty > ], who wrote in article : > >>That would apply to application-wide usage. I was theorizing out loud >>that limiting it to user variables ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 22 of 22

Thread: Re: ramtest.zip Memory test utility, v 0.3 does not work

  1. Re: ramtest.zip Memory test utility, v 0.3 does not work

    Ilya Zakharevich wrote:
    > [A complimentary Cc of this posting was sent to
    > Marty
    > ], who wrote in article <3LOdndJRRNnNw3bcRVn-1Q@comcast.com>:
    >
    >>That would apply to application-wide usage. I was theorizing out loud
    >>that limiting it to user variables would limit the scope to something
    >>that could be done.


    [a) b) & c) parts understood and snipped]

    > So it boils down to the same question: QA. And, in my estimates, it
    > would be much easier to update EMX than to mutiliate a large
    > particular application.


    But would the modification to EMX alone be enough? We'd be talking
    about not only modifying the memory allocation routines, but also
    wrapping the OS/2 API functions that can't make use of high memory. I'd
    guess we'd have to intercept all of them in EMX, slosh the data around
    to a safe place, and then copy the results back.

    But that by itself will not even guarantee that you're safe. For
    example, what if a structure that you have to pass to a 16-bit API call
    contains a member that needs to be a 16-bit pointer?

    You'd have to handle this on an API-by-API basis. And some complex APIs
    that can take multiple different kinds of structures (like
    mciSendCommand, for example) would have to be fully understood by the
    wrappers. Yuck!

    I don't think transparency to the developer is the correct answer. For
    example, for small buffers, who cares where they are allocated? You
    wouldn't want to take the potential speed hit to translate this data to
    "safe" areas. Even ideally, I think it will be up to the application to
    determine which chunks should go to high memory.

    > You want a good Perl, you participate in QA of EMX. ;-) As simple as
    > this.


    I'd be glad to help, but I'm just not convinced that the aim on the
    problem is correct yet.

    If the wrapper API winds up being the answer, then it need not be
    specific to EMX either. It should be its own project, with
    compatibility for other compilers, such as OpenWatcom.

    If only we didn't need any of the memory tiling nonsense. It
    was great back in the days when we cared about running DOS and Win 3.x,
    but I personally haven't run a 16-bit app in 5 years.

    It's funny, I thought I was done with the concept of "far" pointers when
    I wrote my last DOS app so many years ago.

  2. Re: ramtest.zip Memory test utility, v 0.3 does not work

    [A complimentary Cc of this posting was sent to
    Marty
    ], who wrote in article <41ec4633$1@news.cadence.com>:

    > > So it boils down to the same question: QA. And, in my estimates, it
    > > would be much easier to update EMX than to mutiliate a large
    > > particular application.


    > But would the modification to EMX alone be enough? We'd be talking
    > about not only modifying the memory allocation routines, but also
    > wrapping the OS/2 API functions that can't make use of high memory.


    The only places in the Perl src tree which calls OS/2 API functions
    directly are in ./os2; all other calls go through EMX. And this

    a) is less than 0.5M of code (peanuts!);

    b) mostly written very defensively;

    c) (most important) it should not be hard to pass patches to this
    code through Perl QA framework - most objections are going to be
    objective, since there is no chance it will break anything outside
    of OS/2. ;-)

    > But that by itself will not even guarantee that you're safe. For
    > example, what if a structure that you have to pass to a 16-bit API call
    > contains a member that needs to be a 16-bit pointer?


    In EMX, all 16-bit stuff is already translated from/to 32-bit world by
    two routines. So you modify two translation routine, et voila!

    It is 32-bit entry points which need massaging.

    > You'd have to handle this on an API-by-API basis. And some complex APIs
    > that can take multiple different kinds of structures (like
    > mciSendCommand, for example) would have to be fully understood by the
    > wrappers. Yuck!


    For 32-bit code, this may be tricky indeed. But probably not hard to
    automate using C::Scan perl module... (PLUG!)

    > I don't think transparency to the developer is the correct answer. For
    > example, for small buffers, who cares where they are allocated? You
    > wouldn't want to take the potential speed hit to translate this data to
    > "safe" areas.


    You do not need to transfer data, only alias memory (but maybe
    aliasing is even more expensive, this should be eventually benchmarked).

    > Even ideally, I think it will be up to the application to
    > determine which chunks should go to high memory.


    This is out of question, at least if you consider a large and a
    robustly portable application. Nobody will accept a patch which
    mutiliates the appliation with no benefits outside of an OS with 38
    users worldwide. ;-)

    > If only we didn't need any of the memory tiling nonsense. It
    > was great back in the days when we cared about running DOS and Win 3.x,
    > but I personally haven't run a 16-bit app in 5 years.


    As I said, this has nothing to do with 16-bit applications. *They*
    could be confined to 512M. It is 16-bit system DLLs which are the
    stumbling block.

    > It's funny, I thought I was done with the concept of "far" pointers when
    > I wrote my last DOS app so many years ago.


    Comon, 512M should be enough for everything!

    Yours,
    Ilya

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2