DOS ain't dead

I'm trying like idiot and nothing works.
I tried various functions like

int main(void)
{
  printf("putenv: %d\n", putenv("TEST1=123"));
  printf("sys: %d\n", system("SET TEST2=123"));
...clearenv, setenv
  return(0);
}

I can only read env. Funtions returns 0 = success but when I type set or env in shell I don't see new var. I tried DOS, win, linux - all the same. Do I need to call some extra function that flush env. changes to make it persistent? Or other way to do it? Uf going to bed now....

---
DOS gives me freedom to unlimited HW access.

In such way you change only your local copy of environment for your program.
To make the changes persistent you must change the master environment
(look for "DOS master environment" in google)

---
DOS-u-akbar!

> In such way you change only your local copy of environment for your
> program.
> To make the changes persistent you must change the master environment
> (look for "DOS master environment" in google)

Hm, that I feared about - you mean there's no standard C function to do this. As I try to keep portability over dos/win/linux I don't want implement any dirty hack like direct rewriting memory.
I was asked from user of CPUID that I implement a feature that put CPU name string into env. var. I hoped it would be easy task because I remember there are getenv/putenv manipulation funcs in stdlib but it's useless

EDIT: I asked colleagues and there's no way. User would need to use grep/awk to filter out the desired text and then use it for SET.

---
DOS gives me freedom to unlimited HW access.

> > In such way you change only your local copy of environment for your
> > program.
> > To make the changes persistent you must change the master environment
> > (look for "DOS master environment" in google)
>
> Hm, that I feared about - you mean there's no standard C function to do
> this. As I try to keep portability over dos/win/linux I don't want
> implement any dirty hack like direct rewriting memory.
there's no way for that from an .EXE file.

BUT: you can write a batch file
SetCPUID.bat
CPUID.EXE > cpuid.bat
call CPUID.BAT

where running CPUID.EXE would print
set CPUID=386


> EDIT: I asked colleagues and there's no way. User would need to use
> grep/awk to filter out the desired text and then use it for SET.
information technology should save users from
'use grep/awk to filter out the desired text and then use it for SET'

in case you didn't notice, this is the year 2013

> in case you didn't notice, this is the year 2013

What's wrong with grep/awk? It's standard linux/unix (ported to dos/win) tools that have been used many years. This is a special case of usage of my program that was not intended so user have to acomodate or use another program, thats's simply. I was just trying to help him with some solution...

---
DOS gives me freedom to unlimited HW access.

> > in case you didn't notice, this is the year 2013
>
> What's wrong with grep/awk?
grep/awk is ok.
> It's standard linux/unix (ported to dos/win)
> tools that have been used many years. This is a special case of usage of my
> program that was not intended so user have to acomodate or use another
> program, thats's simply. I was just trying to help him with some
> solution...

asking users to (manually) grep/awk is not. this should be automated.

> BUT: you can write a batch file
> SetCPUID.bat
> CPUID.EXE > cpuid.bat
> call CPUID.BAT
>
> where running CPUID.EXE would print
> set CPUID=386

Hm, it seems I have to use such batch files because it seems that I cannon feed SET with redirector <
SET VAR=<program.exe
doesn't work, it has to be file. And under dos I can use only real file on disk...

---
DOS gives me freedom to unlimited HW access.

> I don't want implement any dirty hack like direct rewriting memory.

Unfortunately, directly rewriting memory is the only way to do this, and it would get VERY ugly. You would probably not only want to add/modify the variable in the master environment, but also in any child environments that may exist between you and the master. Some or all of the environments may not even have enough space left to add anything new to them. Even indirectly running the SET command after you exit won't work correctly if you're not a direct descendent of the master.

DJGPP seems to have a function for this:

setenv

This is the group of these environment functions:
environment functions

Georg

> DJGPP seems to have a function for this:
> setenv

Of course this is what I tried 1st and also mentioned in post but this doesn't work - variable exist only during program is running, not permanently.

---
DOS gives me freedom to unlimited HW access.

> Unfortunately, directly rewriting memory is the only way to do this, and it
> would get VERY ugly. You would probably not only want to add/modify the
> variable in the master environment, but also in any child environments that
> may exist between you and the master. Some or all of the environments may
> not even have enough space left to add anything new to them. Even
> indirectly running the SET command after you exit won't work correctly if
> you're not a direct descendent of the master.

I wanted to set env. var only for parent shell that started running my program. But I definitely will not implement any hack... Thanks for all replies. I was little bit naive when I belived it could be easy task...

---
DOS gives me freedom to unlimited HW access.

> Hm, that I feared about - you mean there's no standard C function to do
> this. As I try to keep portability over dos/win/linux I don't want
> implement any dirty hack like direct rewriting memory.

Without a "dirty hack" you wont be able to do it. But if you don't fear "undocumented features" then it can be done!

> Hm, it seems I have to use such batch files because it seems that I cannon feed SET with redirector <
> SET VAR=<program.exe
> doesn't work, it has to be file. And under dos I can use only real file on disk...

That's true and that's exactly why the utility PIPESET exists. Get the DOSUTILS package e.g. from here: http://www.bttr-software.de/products/jhoffmann/ and see whether it does what you need. You could do it with such a command line:

program.exe | PIPESET VAR

Or look into the sources, which are also included in the package, to see how it can be done in C.

> That's true and that's exactly why the utility PIPESET exists. Get the
> DOSUTILS package e.g. from here:
> http://www.bttr-software.de/products/jhoffmann/ and see
> whether it does what you need. You could do it with such a command line:
>
> program.exe | PIPESET VAR

I tried pipeset under WinXP cmd and dosbox but it doesn't set any var. Currently cannot reboot. Probably the hack works only under pure DOS.

---
DOS gives me freedom to unlimited HW access.

> I wanted to set env. var only for parent shell that started running my
> program. But I definitely will not implement any hack... Thanks for all
> replies. I was little bit naive when I belived it could be easy task...

I know you don't want to implement a "hack" for portability reasons, but if anyone else is interested in pursuing this I think it would be possible (though probably not very easy, and may or may not always work depending on specific circumstances).

Though a USB sound system driver has yet to even be started, I was thinking that it will probably be necessary (or at least desirable) to create a BLASTER environment variable in this fashion.

> Though a USB sound system driver has yet to even be started, I was thinking
> that it will probably be necessary (or at least desirable) to create a
> BLASTER environment variable in this fashion.

Yes but this is quite special case of driver when you heavily depend on DOS anyway. BTW do you plan to emulate SB? :)

---
DOS gives me freedom to unlimited HW access.

> > That's true and that's exactly why the utility PIPESET exists. Get the
> > DOSUTILS package e.g. from here:
> > http://www.bttr-software.de/products/jhoffmann/ and see
> > whether it does what you need. You could do it with such a command line:
> >
> > program.exe | PIPESET VAR
>
> I tried pipeset under WinXP cmd and dosbox but it doesn't set any var.
> Currently cannot reboot. Probably the hack works only under pure DOS.

you have to use for /f to do so in Windows 2000/XP/etc.(NT4 not tested)
for /f %i in ('your-command') do set yourenv=%i

> > Hm, that I feared about - you mean there's no standard C function to do
> > this. As I try to keep portability over dos/win/linux I don't want
> > implement any dirty hack like direct rewriting memory.
>
> Without a "dirty hack" you wont be able to do it. But if you don't fear
> "undocumented features" then it can be done!
>
> > Hm, it seems I have to use such batch files because it seems that I
> cannon feed SET with redirector <
> > SET VAR=<program.exe
> > doesn't work, it has to be file. And under dos I can use only real file
> on disk...
>
> That's true and that's exactly why the utility PIPESET exists. Get the
> DOSUTILS package e.g. from here:
> http://www.bttr-software.de/products/jhoffmann/ and see
> whether it does what you need. You could do it with such a command line:
>
> program.exe | PIPESET VAR
>
> Or look into the sources, which are also included in the package, to see
> how it can be done in C.

PIPESET let me remember Horst Schaeffer's batch support tools.
http://www.horstmuc.de/horst.htm

The NSET document even has a section for workarounding in NTDVM environment:
------------------------------------------------------------------------
NSET Work-around for WIN NT/2000/XP NSET Ver 2.1
------------------------------------------------------------------------

NSET writes variable assignments directly into the environment variable
space of COMMAND.COM. However, this does no work under Win NT/2000/XP.

Work-around:

NSET also supports sending the string to STDOUT, instead assigning it
to a variable. This is done by omitting the variable name (not the "="
sign).

Example: CD | nset currDir=$0 (normal mode, sets variable)
CD | nset =$0 (string is output to screen)

Now, you prepend "SET varname=" to the string, and send the result to
a temporary batch file (which is CALLed to execute the SET statement).

Example: CD | nset =SET currdir=$0 > temp.bat
call temp.bat

Actually, compared to normal mode, you just insert "=SET", and redirect
the output. Everything else remains the same.

Example: CD | nset currDir=$0 (normal mode)
CD | nset =SET currdir=$0 > temp.bat
---- ----------

Remember to delete the temporary batch file after use.

** 20.05.1999

> NSET also supports sending the string to STDOUT, instead assigning it
> to a variable.

PIPESET does so too. Just try PIPESETs "/S" switch".

> > in case you didn't notice, this is the year 2013
>
> What's wrong with grep/awk?

- *nix stuff.
- Balkanisation in versions and accepted regexes. (awk is better than sed tho)
- On Dos/Windows, other toolchains might install incompatible versions earlier in PATH
- mixes output with functionality. What is user output, what is needed for chained programs?
- on commercial unix same with properietary and GNU version
- Requires decent pipe implementations on relevant platforms
- DIY solution with bad errorhandling.
- I never liked regexes to begin with.

> BTW do you plan to emulate SB? :)

Someday I will probably try to do that, unless somebody else takes the initiative before I get around to it. Don't hold your breath, though -- too many other distractions and projects for now.

> - *nix stuff.
> - Balkanisation in versions and accepted regexes. (awk is better than sed
> tho)
> - On Dos/Windows, other toolchains might install incompatible versions
> earlier in PATH
> - mixes output with functionality. What is user output, what is needed for
> chained programs?
> - on commercial unix same with properietary and GNU version
> - Requires decent pipe implementations on relevant platforms
> - DIY solution with bad errorhandling.
> - I never liked regexes to begin with.

Well, I played with pipeset and found that it's intelligent enough so I was able to extract desired substrig via output filter options avoiding the grep, problem solved :)

---
DOS gives me freedom to unlimited HW access.

> BUT: you can write a batch file
> SetCPUID.bat
> CPUID.EXE > cpuid.bat
> call CPUID.BAT
>
> where running CPUID.EXE would print
> set CPUID=386
>

Or you can create the batch file, run it and than remove it directly from C/C++. IE: create a new file in %TMP% or %TEMP%, write appropriate "set" commands into it, than run %COMSPEC% on it and then unlink (remove) it.

Ugly, but will probably work. I used something along these lines once. Although for my own use, so it wasn't important how crappy the code is if it does the job. :)