Modifying process environment - OS2

This is a discussion on Modifying process environment - OS2 ; Andy Staszko wrote: > Sorry, I thought there may have been some hidden piece of magic > being used: Watcom and the IBM toolkits do the same. > Unfortunately, there doesn't seem to be any magic... > It seems you're ...

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

Thread: Modifying process environment

  1. Re: Modifying process environment

    Andy Staszko wrote:

    > Sorry, I thought there may have been some hidden piece of magic
    > being used: Watcom and the IBM toolkits do the same.
    >

    Unfortunately, there doesn't seem to be any magic...

    > It seems you're well and truly stuffed!
    >

    Yes. No big deal - I'm just surprised that there appears to be
    no "good" way to do what I want.


    Michal


  2. Re: Modifying process environment

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Michal Necasek
    ], who wrote in article <6M2vd.8099$nE7.2587@newssvr17.news.prodigy.com>:
    > Yes. No big deal - I'm just surprised that there appears to be
    > no "good" way to do what I want.


    But can you reiterate *why* would you need to do this *in your own
    process*; if some APIs search the PATH from DosScanEnv(), just do your
    own scan of PATH before calling them...

    [Of course, if you want to change somebody else's environment, then
    the question is legitimate; I would think about changing environment
    fo the first copy of PMSHELL on the fly...]

    Yours,
    Ilya



  3. Re: Modifying process environment

    Ilya Zakharevich wrote:

    > But can you reiterate *why* would you need to do this *in your own
    > process*; if some APIs search the PATH from DosScanEnv(), just do your
    > own scan of PATH before calling them...
    >

    That's making a big assumption that I can find and modify all instances
    of such code. In this particular case I can get around it, but in general
    it's between difficult and impossible. The OS/2 API calls might be in
    libraries or DLLs that I cannot modify.


    Michal


  4. Re: Modifying process environment

    Rich Walsh wrote:

    > Small world :-) Yesterday I was attempting to do exactly this.
    > I gave up. In a nutshell: 32-bit code, no problem; 16-bit code,
    > no joy.
    >

    Interesting...

    > Why I encountered this problem is hard to understand. If you've ever
    > looked at cmd.exe's environment after entering a few SET statements,
    > you'll see that they're tacked on at the end of its existing strings.
    > In doing so, it clobbers the f/q exename and the commandline parms
    > that follow the environment, but with no ill effect AFAICT. If the
    > prototypical 16-bit app can modify its environment, why can't I?
    >

    Perhaps because internally CMD.EXE tightly controls how the environment
    is used. It knows that it won't be trying to look at the exe name or
    args after startup, so it can safely trash those. Furthermore, CMD.EXE
    does not have the problem of mixing C runtime environment and OS
    environment.


    Michal


  5. Re: Modifying process environment

    Ruediger Ihle wrote:

    > I cannot speak for VisualAge, but looking at the RTL source
    > for Borland C++, I see that putenv() works on a copy of the
    > original environment strings. The code for updating the real
    > process environment is inside an #ifdef __WIN32__ block.
    >

    Watcom does much the same thing. Initially, the runtime
    builds the 'environ' array and makes it point to the "real"
    OS environment. Any modification will allocate a new copy
    (only for the one env var though) and the runtime keeps track
    of which variables were allocated and which weren't. This
    method is of course much more flexible because it allows
    modification of individual env vars without having to reshuffle
    the entire environment.

    When the time comes to spawn a new process, the runtime
    constructs the environment in the OS format from the C runtime
    copy (which may or may not have been modified) and passes that
    to the child process.

    > For OS/2, they just do nothing. This means, that any change
    > done by putenv() will only be reflected by the CRTL functions
    > - like the mentioned ones -. DosScanEnv() will *NOT* see these
    > modifications. But this is, what Michal wants to achive !
    >

    Why can everyone but Herbert Rosenau understand that?

    > Maybe Borland is doing this due to the lack of a proper API.
    > But OTOH, this API may be nonexistent by design. Since
    > DosScanEnv returns a pointer to the string (instead of copying
    > it), a modification of the original environment would cause
    > unpredictable results.
    >

    That was my conclusion too. I'd be curious to know how Win32
    handles this internally, that is where the strings live in
    memory and how the OS handles addition/deletion.


    Michal


  6. Re: Modifying process environment

    On Sun, 12 Dec 2004 22:10:32 UTC, Michal Necasek wrote:
    > Rich Walsh wrote:
    >
    > > Small world :-) Yesterday I was attempting to do exactly this.
    > > I gave up. In a nutshell: 32-bit code, no problem; 16-bit code,
    > > no joy.
    > >

    > Interesting...


    I went back to this & found the problems on the 16-bit side were the
    result of a dumb error. While I had thunked my data pointers, I had
    failed to declare DosSizeSeg() & DosReallocSeg() as APIENTRY16. With
    that fixed, I had no problem increasing the environment seg's access
    limit.


    --
    == == almost usable email address: rws AT e-vertise.com == ==
    __________________________________________________ _________________
    |
    | New - Remote Workplace Server v0.60
    Rich Walsh | interact with the WPS from any program
    Ft Myers, FL | http://e-vertise.com/rws/rws060.zip
    __________________________________________________ _________________

  7. Re: Modifying process environment

    On Sun, 12 Dec 2004 02:40:40 GMT, Michal Necasek wrote:

    >> What size limitations? I can't see there are any.
    >>

    > Bad things start happening if the size of the environment gets
    > close to 32K. I don't recall the exact details but I think that
    > if the total size of environment strings is "too big", DosExecPgm
    > starts failing. I seem to remember that "too big" was just under
    > 32K.


    But that has nothing to do with what I suggested. The same will happen
    if your original environment is that big.

    > But 16-bit apps have no PIB and the env strings are stored in
    > a special environment segment... which I don't think can be
    > reallocated.


    I guess you're right. I haven't looked that closely at 16 bit code for
    ages. I see Rich came up with a solution though.

    > I just thought of a problem with changing the OS enviroment,
    > although I'm not sure if it's a real problem or not: If some code
    > kept a pointer to the strings in the OS environment, reallocating
    > will invalidate that pointer.


    True. There's no way round that.

  8. Re: Modifying process environment

    Paul Ratcliffe wrote:

    >> Bad things start happening if the size of the environment gets
    >>close to 32K. I don't recall the exact details but I think that
    >>if the total size of environment strings is "too big", DosExecPgm
    >>starts failing. I seem to remember that "too big" was just under
    >>32K.

    >
    > But that has nothing to do with what I suggested. The same will happen
    > if your original environment is that big.
    >

    Yes, that's true. It's an unrelated limitation of OS/2. One of those
    annoying things that go back to the original 16-bit design and won't
    ever get fixed.


    Michal


  9. Re: Modifying process environment

    MN> Note that I'm talking about the OS/2 process environment, not the
    MN> environment maintained by a C runtime library.

    Then you're onto a loser ... *unless* you have a Pure 32-Bit program.

    It's relatively easy to write a DosSetEnv() function that DosAllocMem()s
    a new environment area, DosFreeMem()s the old, and modifies the pointer
    in the PIB. I wrote one many years ago. It's the underpinnings of the
    setenv() function in my C++ standard library, as used by my Command
    Interpreter, Command Line Utilities, Internet Utilities, et al..

    The difficulty arises when you consider 16-bit code. 16-bit code
    requires that the environment area reside in tiled memory aligned to a
    64KiB boundary, that it be 32KiB or less in size, and that it be pointed
    to from the 16-bit local information segment.

    I avoided the problem. All of my programs are Pure 32-Bit programs.

  10. Re: Modifying process environment

    RI> But OTOH, this API may be nonexistent by design. Since DosScanEnv
    RI> returns a pointer to the string (instead of copying it), a
    RI> modification of the original environment would cause unpredictable
    RI> results.

    Usually, the definition of such APIs is that if one modifies the
    environment, any previously obtained pointers to environment strings are
    by definition invalidated.

  11. Re: Modifying process environment

    HR> The C runtime does nothing more than to give you the same environment
    HR> that you gets with DosScanEnv()

    Only when you use *my* C++ standard library. As far as I know, I'm as
    yet the only C++ library implementor for OS/2 that has ever implemented
    his/her library this way. All other implementations operate upon copies
    of the OS/2 per-process environment, causing all of the problems Michal
    alluded to (and more that he hasn't mentioned).

  12. Re: Modifying process environment

    Hi,

    there is an old 16-bit API to get a pointer to the WHOLE environment of a process:

    typedef SEL * _Seg16 PSEL16;
    typedef USHORT * _Seg16 PUSHORT16;
    #define DosGetEnv DOS16GETENV
    APIRET16 APIENTRY16 DosGetEnv(PSEL16,PUSHORT16);

    rc16 = DosGetEnv(&sel,&off);
    pEnv = (PBYTE)MAKEP(sel,0);

    You might want to check if pointer pEnv is writable, I am not sure.
    The single environment strings are separated by \0 while the whole environment
    is ended by \0\0.
    But I remember (as others have stated) that there is some extra space (up to 64K I think), so
    you could use memmove, if you need to expand(?)/shrink a variable within.

    Lars



    Michal Necasek schrieb:
    >
    > I thought this should be elementary - but I can't find any way to
    > modify the environment of the current process. Win32 has a nice
    > SetEnvironmentVariable API, Unix has setenv(). Does OS/2 have an
    > equivalent?
    >
    > Note that I'm talking about the OS/2 process environment, not
    > the environment maintained by a C runtime library.
    >
    >
    > Michal
    >


  13. Re: Modifying process environment

    Oops, Rich was right, the environment segment ends right after the end of the last
    environment string + executable name + the commandline (Theseus tells me so).
    Too bad, so it's indeed DosSizeSeg/DosReallocSeg to get a bigger environment space ...
    But you have to be careful, the environment is FOLLOWED by the executable name + commandline
    and NOT PRECEDED by it !
    This leads to yet another problem: How do you tell OS/2 that the offset (in the
    enviroment segment) of the commandline has changed ?
    DosGetEnv(&sel,&off) returns the commandline offset in "off".

    Lars

    Lars Erdmann schrieb:
    > Hi,
    >
    > there is an old 16-bit API to get a pointer to the WHOLE environment of
    > a process:
    >
    > typedef SEL * _Seg16 PSEL16;
    > typedef USHORT * _Seg16 PUSHORT16;
    > #define DosGetEnv DOS16GETENV
    > APIRET16 APIENTRY16 DosGetEnv(PSEL16,PUSHORT16);
    >
    > rc16 = DosGetEnv(&sel,&off);
    > pEnv = (PBYTE)MAKEP(sel,0);
    >
    > You might want to check if pointer pEnv is writable, I am not sure.
    > The single environment strings are separated by \0 while the whole
    > environment
    > is ended by \0\0.
    > But I remember (as others have stated) that there is some extra space
    > (up to 64K I think), so
    > you could use memmove, if you need to expand(?)/shrink a variable within.
    >
    > Lars


  14. Re: Modifying process environment

    Rich Walsh schrieb:
    > On Sat, 11 Dec 2004 07:12:15 UTC, Michal Necasek wrote:
    >
    >> I thought this should be elementary - but I can't find any way to
    >>modify the environment of the current process. Win32 has a nice
    >>SetEnvironmentVariable API, Unix has setenv(). Does OS/2 have an
    >>equivalent?

    >
    >
    > Small world :-) Yesterday I was attempting to do exactly this.
    > I gave up. In a nutshell: 32-bit code, no problem; 16-bit code,
    > no joy.
    >
    > I'm updating my Run! util and wanted to modify its environment so
    > I could it pass it as-is to the program it starts without having
    > to make a separate copy.


    If you want to do just this (if there is no change in environment),
    use old 16-bit API DosGetEnv to get the environment pointer:

    typedef SEL * _Seg16 PSEL16;
    typedef USHORT * _Seg16 PUSHORT16;
    #define DosGetEnv DOS16GETENV
    APIRET16 APIENTRY16 DosGetEnv(PSEL16,PUSHORT16);


    rc16 = DosGetEnv(&sel,&off);
    /*
    off points to the command arguments but we want the whole environment
    so pass offset 0 to the pointer conversion macro
    */
    pEnv = (PBYTE)MAKEP(sel,0);

    You can pass pEnv to DosStartSession,DosExecPgm.


    Adding & removing strings was no problem
    > as long as I didn't cross a page boundary. However, when I called
    > DosStartSession(), I kept getting an access violation in 16-bit code.
    >
    > Eventually I realized it was an access limit problem: using a 16-bit
    > selector, the segment was exactly as long as the original environment
    > + f/q exename + commandline arguments. I tried calling DosSizeSeg()
    > to get its size and DosReallocSeg() to change it, but all attempts
    > failed. I don't recall the rc, but yes, I was using suitably-thunked
    > pointers/selectors.
    >
    > Why I encountered this problem is hard to understand. If you've ever
    > looked at cmd.exe's environment after entering a few SET statements,
    > you'll see that they're tacked on at the end of its existing strings.
    > In doing so, it clobbers the f/q exename and the commandline parms
    > that follow the environment, but with no ill effect AFAICT. If the
    > prototypical 16-bit app can modify its environment, why can't I?


    This is really interesting. I would have never expected cmd.exe to screw up the exename + commandline.
    That means that DosGetEnv will fail in returning the offset to the commandline once cmd.exe has
    extended its environment space. How awful.

    Lars

  15. Re: Modifying process environment

    On Fri, 17 Dec 2004 23:42:22 UTC, Lars Erdmann wrote:
    > Rich Walsh schrieb:


    >> I'm updating my Run! util and wanted to modify its environment so
    >> I could it pass it as-is to the program it starts without having
    >> to make a separate copy.

    >
    > If you want to do just this (if there is no change in environment),
    > use old 16-bit API DosGetEnv to get the environment pointer:


    16-bit or 32-bit, the environment is at the same location. Since it's
    easier to work with 32-bit code, I get the address from the PIB then
    assign it to 32 & 16-bit pointers. Using an explicit _Seg16 pointer
    means the function only needs a single thunk (in the assignment
    statement). Plus, it makes getting the selector simple: HIUSHORT(ptr16).

    >> If you've ever looked at cmd.exe's environment after entering a few
    >> SET statements, you'll see that they're tacked on at the end of its
    >> existing strings. In doing so, it clobbers the f/q exename and the
    >> commandline parms that follow the environment, but with no ill effect
    >> AFAICT.

    >
    > This is really interesting. I would have never expected cmd.exe to
    > screw up the exename + commandline. That means that DosGetEnv will
    > fail in returning the offset to the commandline once cmd.exe has
    > extended its environment space. How awful.


    It's not awful if you think about it. After all, who is this info
    intended for other than the program to which the info was given?
    Once the app has parsed its commandline, who needs it? As long as
    some intruder-app (of the sort I'm so fond of writing) doesn't rely
    on it, it's of no further use.

    Back when I wrote RWL to demonstrate than any program could invade
    any PM process at will and do what it liked, it occurred to me that
    a possible use was to modify PMShell's environment. At the time, I
    wasn't interested enough to bother. Now I am, so I've started working
    on just such a util. BTW... even though it shouldn't matter, it will
    preserve the stuff after the environment & update the PIB accordingly.
    32-bit intruder-apps have nothing to worry about :-)


    --
    == == almost usable email address: rws AT e-vertise.com == ==
    __________________________________________________ _________________
    |
    | New - Remote Workplace Server v0.60
    Rich Walsh | interact with the WPS from any program
    Ft Myers, FL | http://e-vertise.com/rws/rws060.zip
    __________________________________________________ _________________

  16. Re: Modifying process environment

    [A complimentary Cc of this posting was NOT [per weedlist] sent to
    Rich Walsh
    ], who wrote in article :
    > > This is really interesting. I would have never expected cmd.exe to
    > > screw up the exename + commandline. That means that DosGetEnv will
    > > fail in returning the offset to the commandline once cmd.exe has
    > > extended its environment space. How awful.

    >
    > It's not awful if you think about it. After all, who is this info
    > intended for other than the program to which the info was given?


    Any DLL which the application loads.

    > Once the app has parsed its commandline, who needs it?


    E.g., if you load Perl DLL into cmd.exe via the REXX interface to
    Perl, Perl will not be able to deduce that it was cmd.exe which called
    it; so it may behave inpredictable (e.g., when trying to start another
    copy of itself/or/Perl to handle some task).

    > Back when I wrote RWL to demonstrate than any program could invade
    > any PM process at will and do what it liked, it occurred to me that
    > a possible use was to modify PMShell's environment. At the time, I
    > wasn't interested enough to bother. Now I am, so I've started working
    > on just such a util. BTW... even though it shouldn't matter, it will
    > preserve the stuff after the environment & update the PIB accordingly.
    > 32-bit intruder-apps have nothing to worry about :-)


    Thanks,
    Ilya

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2