How to access environ of process prior to last local COMMAND.COM shell?
Frank van Nuffel
For my question, please review this code snippet; thanks in advance
// compiled for small memory model; Borland C++
#include "stdio.h"
#include "alloc.h"
#include "dos.h"
#include "string.h"
char far** penv ;
unsigned penv_size ;
void penv_init() ;
void penv_exit() ;
#pragma startup penv_init
#pragma exit penv_exit
void main ( int argc, char* argv[] ) {
int i, j ;
if ( argc == 1 ) return ;
for ( i = 0; penv[ i ]; i ++ ) {
for ( j = 0; penv[ i ][ j ]; j ++ )
printf( "%c", penv[ i ][ j ] ) ;
printf( "\n" ) ;
}
return ;
}
void penv_init() {
unsigned far*P0 ;
void _seg*P1 ;
char far*P ;
int i, j, k, l ;
P0 = (unsigned far*) MK_FP( _psp, 0x16 ) ; // access PSP of prev process
P1 = ( void _seg*) *P0 ;
P0 = (unsigned far*) MK_FP( P1, 0x16 ) ; // again prev process.
P1 = ( void _seg*) *P0 ; // however, if this
process
P0 = (unsigned far*) MK_FP( P1, 0x16 ) ; // was command.com this
P1 = ( void _seg*) *P0 ; // points to itself
// my question here: is there a way to access the PSP of the process prior
// to this local copy of COMMAND.COM?
P0 = (unsigned far*) MK_FP( P1, 0x2C ) ; // access the environ seg
P1 = ( void _seg*) *P0 ;
P = ( char far*) MK_FP( P1, 0x00 ) ; // and the environ itself
penv = (char far**) malloc(( k + 1 ) * sizeof(char far*)) ;
penv_size = * (unsigned far*) MK_FP( FP_SEG( P1 ) - 1, 0x03 ) * 16 ;
for ( i = 0, j = 0, k = 0, l = 0; j = P[i] ? ( j>0 ? 2 : 1 ) : ( j>0 ? -1 :
0 ); k = ( j==1 ? k+1 : k ), l++, i ++ )
if ( j==1 ) penv[ k ] = (char far*) ( P + i ) ;
penv[ k ] = (char far*) NULL ;
return ;
}
void penv_exit() {
free((void*) penv ) ;
return ;
}
Frank van Nuffel
f_...@pi.be
Martin Ambuhl
> Hi all,
>
> For my question, please review this code snippet; thanks in advance
Why do you think we should do this for someone who has obviously not
checked the FAQ or followed the newsgroup? Your ignoring normal
netiquette is no excuse for your posting crap for code.
Frank van Nuffel
Frank
ke...@hplb.hpl.hp.com
"Frank van Nuffel" <f_...@pi.be> writes:
>
> For my question, please review this code snippet; thanks in advance
You asked ...
>
> // compiled for small memory model; Borland C++
Non-Standard comment, unless you're using a C99 compiler. Borland is
off-topic. C++ is off-topic. Did you read the FAQ? Did you browse this
newsgroup long enough to discern what is topical here?
> #include "stdio.h"
Should be <stdio.h>
> #include "alloc.h"
No such header. What's wrong with <stdlib.h>?
> #include "dos.h"
No such header.
> #include "string.h"
Should be <string.h>
> char far** penv ;
No such thing as `char far` in C.
> unsigned penv_size ;
>
> void penv_init() ;
> void penv_exit() ;
>
> #pragma startup penv_init
> #pragma exit penv_exit
Pragmas are not portable.
> void main ( int argc, char* argv[] ) {
`main` must return `int`.
>
> int i, j ;
>
> if ( argc == 1 ) return ;
>
> for ( i = 0; penv[ i ]; i ++ ) {
`penv` is null. Oops.
> for ( j = 0; penv[ i ][ j ]; j ++ )
`penv` is still null. Oops.
> printf( "%c", penv[ i ][ j ] ) ;
> printf( "\n" ) ;
> }
>
> return ;
>
> }
>
> void penv_init() {
Never called.
> unsigned far*P0 ;
No such thing as `unsigned far`.
> void _seg*P1 ;
Names beginning _ are often reserved to the implementation. The rules
are sufficiently subtle that never using such names is a wise choice.
> char far*P ;
`far` again.
> int i, j, k, l ;
>
> P0 = (unsigned far*) MK_FP( _psp, 0x16 ) ; // access PSP of prev process
`unsigned far` is not a type. `MK_FP` is not defined.
[deletions]
> penv = (char far**) malloc(( k + 1 ) * sizeof(char far*)) ;
Don't cast the return value of `malloc`.
> penv_size = * (unsigned far*) MK_FP( FP_SEG( P1 ) - 1, 0x03 ) * 16 ;
>
> for ( i = 0, j = 0, k = 0, l = 0; j = P[i] ? ( j>0 ? 2 : 1 ) : ( j>0 ? -1 :
> 0 ); k = ( j==1 ? k+1 : k ), l++, i ++ )
Brain exploded. Expression to complicated, meaning indiscernable.
> if ( j==1 ) penv[ k ] = (char far*) ( P + i ) ;
>
> penv[ k ] = (char far*) NULL ;
NULL doesn't need to be cast like that.
> return ;
>
> }
>
> void penv_exit() {
>
> free((void*) penv ) ;
Cast unnecessary.
>
> return ;
>
> }
Too many blank lines.
--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
Frank van Nuffel
<ke...@hplb.hpl.hp.com> schreef in bericht
news:b47ipb$mfg$2...@murdoch.hpl.hp.com...
>
[snip]
> Pragmas are not portable.
comp.lang.c and portability; that makes sense; not asking would not bring
the word any closer
[snip]
> Too many blank lines.
Les goûts et les couleurs --
Frank
ke...@hplb.hpl.hp.com
"Frank van Nuffel" <f_...@pi.be> writes:
>
> <ke...@hplb.hpl.hp.com> schreef in bericht
> news:b47ipb$mfg$2...@murdoch.hpl.hp.com...
>
>> Pragmas are not portable.
>
> comp.lang.c and portability; that makes sense; not asking would not bring
> the word any closer
Pardon?
> [snip]
>
>> Too many blank lines.
>
> Les goûts et les couleurs --
You think the blank lines in:
void penv_exit() {
free((void*) penv ) ;
return ;
}
serve some useful purpose, is it?
Richard Bos
> In article <b47kar$gji$1...@reader11.wxs.nl>,
> "Frank van Nuffel" <f_...@pi.be> writes:
> >
> > <ke...@hplb.hpl.hp.com> schreef in bericht
> > news:b47ipb$mfg$2...@murdoch.hpl.hp.com...
> >
> >> Too many blank lines.
> >
> > Les goûts et les couleurs --
>
> You think the blank lines in:
>
> void penv_exit() {
>
> free((void*) penv ) ;
>
> return ;
>
> }
>
> serve some useful purpose, is it?
IMO, all but one line of that function serves no useful purpose, and
only about half of that line does any good, at that:
free(penv);
The OP might want to consider the KISS principle. It could make his life
so much easier.
Richard
Frank van Nuffel
<ke...@hplb.hpl.hp.com> schreef in bericht
news:b47mfi$oki$1...@murdoch.hpl.hp.com...
> > comp.lang.c and portability; that makes sense; not asking would not
bring
> > the word any closer
>
_portability_ ; it was not my primary concern when writing the code, though
off-topic here; suggestions for the code to meet?
> >> Too many blank lines.
> >
> > Les goûts et les couleurs --
>
> You think the blank lines in:
>
> void penv_exit() {
>
> free((void*) penv ) ;
>
> return ;
>
> }
Not to the compiler; it was cut from a text file, bit by bite
Frank
Frank van Nuffel
"Richard Bos" <r...@hoekstra-uitgeverij.nl> schreef in bericht
news:3e675fa8...@news.nl.net...
> ke...@hplb.hpl.hp.com () wrote:
> > void penv_exit() {
> >
> > free((void*) penv ) ;
> >
> > return ;
> >
> > }
> >
> > serve some useful purpose, is it?
>
> IMO, all but one line of that function serves no useful purpose, and
> only about half of that line does any good, at that:
>
> free(penv);
>
> The OP might want to consider the KISS principle. It could make his life
> so much easier.
The process of my writing code goes thru stages; while first learning I
tend it to expand quite explicitly, as a part of a mental drill. It works
for me, and I'll be conscious about what I'll do next in programming.
As to me, a question of flavour
Frank
ke...@hplb.hpl.hp.com
> news:b47mfi$oki$1...@murdoch.hpl.hp.com...
>> > comp.lang.c and portability; that makes sense; not asking would not
> bring
>> > the word any closer
>>
>> Pardon?
>
> _portability_ ; it was not my primary concern when writing the code, though
> off-topic here;
We're about portable code here. If you want implementation-specific
comments, go find an appropriate implementation-specific newsgroup.
The code you posted was *unnecessarily* non-portable. What's more,
the essential non-portable aspects weren't under control.
> suggestions for the code to meet?
What, other than what I pointed out in my original response? How about
"Document non-standard features"? How about "present examples, preferably
as executable code"? How about, "don't use so many unnecessary
spaces ; they make the code harder to read"? How about "Don't
use // comments in code posted to comp.lang.c, even if you've got a
C99-conforming compiler"?
>> >> Too many blank lines.
>> >
>> > Les goûts et les couleurs --
>>
>> You think the blank lines in:
>>
>> void penv_exit() {
>>
>> free((void*) penv ) ;
>>
>> return ;
>>
>> }
>
> Not to the compiler; it was cut from a text file, bit by bite
Don't be dense; I didn't mean to the compiler. Did they serve some
useful purpose to the *reader*?
--
Chris "Non. No, they did not." Dollin
Frank van Nuffel
<ke...@hplb.hpl.hp.com> schreef in bericht
news:b47omn$pgm$1...@murdoch.hpl.hp.com...
And again, bite!
> > for ( i = 0, j = 0, k = 0, l = 0; j = P[i] ? ( j>0 ? 2 : 1 ) : ( j>0
? -1 :
> > 0 ); k = ( j==1 ? k+1 : k ), l++, i ++ )
>
> Brain exploded.
It shows
> Chris "Non. No, they did not." Dollin
> C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
> C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
What would you know about welcoming!
Frank
ke...@hplb.hpl.hp.com
>>
>> Don't be dense; I didn't mean to the compiler. Did they serve some
>> useful purpose to the *reader*?
>
> And again, bite!
You're trolling, is it? Ah, I see. Sorry to have engaged you.
>> > for ( i = 0, j = 0, k = 0, l = 0; j = P[i] ? ( j>0 ? 2 : 1 ) : ( j>0
> ? -1 :
>> > 0 ); k = ( j==1 ? k+1 : k ), l++, i ++ )
>>
>> Brain exploded.
>
> It shows
Then why write code that obscure?
>> Chris "Non. No, they did not." Dollin
>> C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
>> C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
>
> What would you know about welcoming!
You asked for a review. I supplied one, even though much of your code
was off-topic. You asked for suggestions for the code to meet. I provided
those, too.
You commented on my remark about blank lines. I asked you what purpose
they served in a specific example. You still haven't answered the question.
Instead, you've resorted to insults.
Guests, as well as hosts, have welcoming responsibilities.
--
Chris "electric hedgehog" Dollin
Frank van Nuffel
<ke...@hplb.hpl.hp.com> schreef in bericht
news:b47q3c$q5o$1...@murdoch.hpl.hp.com...
> >> Don't be dense; I didn't mean to the compiler. Did they serve some
> >> useful purpose to the *reader*?
> >
> > And again, bite!
>
> You're trolling, is it? Ah, I see. Sorry to have engaged you.
Then don't
> >> Chris "Non. No, they did not." Dollin
> >> C FAQs at: http://www.faqs.org/faqs/by-newsgroup/comp/comp.lang.c.html
> >> C welcome: http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
> >
> > What would you know about welcoming!
>
> You asked for a review. I supplied one, even though much of your code
> was off-topic. You asked for suggestions for the code to meet. I provided
> those, too.
It was a fair question to the ng. The code that was supplied really didn't
matter;
moreover, off-topic - that was made clear. Just a way of pointing to the
issue
with what I already had; so I move on; whether you have suggestions for the
code
to meet the required job as per title.
> You commented on my remark about blank lines. I asked you what purpose
> they served in a specific example. You still haven't answered the
question.
> Instead, you've resorted to insults.
Blanks happen to clarify the overview, much like breathing in between eye
blinks. What's this investigating about blanks have to do with
recommendations
other than for personal satisfaction; I answered clear and to the point: les
goûts et les couleurs.
> Guests, as well as hosts, have welcoming responsibilities.
I overlooked the portability topic in this ng. I stated I'd see how to
repair.
What part in all this don't you understand?
Frank
ke...@hplb.hpl.hp.com
>> they served in a specific example. You still haven't answered the
> question.
>> Instead, you've resorted to insults.
>
> Blanks happen to clarify the overview, much like breathing in between eye
> blinks.
Eh?
No, they don't.
> What's this investigating about blanks have to do with
> recommendations
> other than for personal satisfaction; I answered clear and to the point: les
> goûts et les couleurs.
Tastes and colours? Or what? They're both off-topic here.
>> Guests, as well as hosts, have welcoming responsibilities.
>
> I overlooked the portability topic in this ng. I stated I'd see how to
> repair.
>
> What part in all this don't you understand?
Why you appeared upset and ratty when you got what you asked for.
--
Chris "electric hedgehog" Dollin
Frank van Nuffel
<ke...@hplb.hpl.hp.com> schreef in bericht
news:b47tkd$scb$1...@murdoch.hpl.hp.com...
> In article <b47t21$499$1...@reader08.wxs.nl>,
> "Frank van Nuffel" <f_...@pi.be> writes:
> > Blanks happen to clarify the overview, much like breathing in between
eye
> > blinks.
>
> Eh?
>
> No, they don't.
You make me smile light-hearted: it's poetry; much like the "obscure"
<dixit> code frag
> Tastes and colours? Or what? They're both off-topic here.
haha, touché
> Why you appeared upset and ratty when you got what you asked for.
I appreciate, really
Thanks for your time :-)
Frank
CBFalconer
>
> For my question, please review this code snippet; thanks in advance
>
> // compiled for small memory model; Borland C++
Syntax error for C89. C++ is off topic.
>
> #include "stdio.h"
> #include "alloc.h"
> #include "dos.h"
> #include "string.h"
You haven't shown the .h files. If you meant <filename.h> then
alloc.h and dos.h don't exist.
>
> char far** penv ;
far is a syntax error.
> unsigned penv_size ;
>
> void penv_init() ;
> void penv_exit() ;
>
> #pragma startup penv_init
> #pragma exit penv_exit
#pragma is system dependant. In std C these do nothing, so remove
them.
>
> void main ( int argc, char* argv[] ) {
another error. main returns int. Undefined behavior.
>
> int i, j ;
>
> if ( argc == 1 ) return ;
Obviously argc == 0 is a satisfactory condition.
I shall go no further.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Mark McIntyre
<f_...@pi.be> wrote:
>Blanks happen to clarify the overview, much like breathing in between eye
>blinks.
What ????
>What's this investigating about blanks have to do with recommendations
>other than for personal satisfaction;
You asked for comments from people with a collective experience of C
of probably over several centuries. A valid comment from such people
is "your style is hard to read, you use too much whitespace".
>I answered clear and to the point: les
>goûts et les couleurs.
That may mean something to you, but its gibberish to me*. This is an
english language group, say it in english.
* c'est vrais que je peux lire Francais, mais c'est hors de sujet*
** and my grammar is terrible
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Richard Bos
>
> "Richard Bos" <r...@hoekstra-uitgeverij.nl> schreef in bericht
> news:3e675fa8...@news.nl.net...
> > ke...@hplb.hpl.hp.com () wrote:
>
> > > void penv_exit() {
> > >
> > > free((void*) penv ) ;
> > >
> > > return ;
> > >
> > > }
> > >
> > > serve some useful purpose, is it?
> >
> > IMO, all but one line of that function serves no useful purpose, and
> > only about half of that line does any good, at that:
> >
> > free(penv);
> >
> > The OP might want to consider the KISS principle. It could make his life
> > so much easier.
>
> The process of my writing code goes thru stages; while first learning I
> tend it to expand quite explicitly, as a part of a mental drill.
I don't understand how extending your code unnecessarily by several
orders of magnitude can be part of a "mental drill", but if you are this
voluble you should really not be surprised that you have problems
reviewing your own code.
Moreover, if you insist on using massive amounts of unnecessarily
implementation-specific and obfuscatory code, you should really not be
surprised if you run into implementation-dependent problems, and if one
of your extensions munges what would otherwise be reliable code.
Richard