GetEnvVar in TPC versus FPC 
Author Message
 GetEnvVar in TPC versus FPC

I've written a test cgi-bin program and used the TPC compiler
successfully.  However, I need a 32 bit executable instead if 16 bit
and thought I'd use FPC for that purpose.  Unfortunately FPC says it
cannot find the WINDOS unit which is necessary for the GetEnvVar
function I need.  I tried compiling the WINDOS.PAS unit found in the
\BP\RTL\WIN directory, but I get many errors from FPC.

PROGRAM test;
{$X+}

USES
  strings, Dos, WinDos;

Var
  parmline : PChar;
...
  parmline:=GetEnvVar('QUERY_STRING');
...

Any thoughts about how to get a LARGE environment variable pointed to
by a PChar variable would be appreciated.

Jim Bishop
==========================================================================
For Big Bend NP info try http://www.*-*-*.com/ ~jbishop/bb/index.htm



Sun, 10 Aug 2003 04:11:11 GMT  
 GetEnvVar in TPC versus FPC

Quote:

>I've written a test cgi-bin program and used the TPC compiler
>successfully.  However, I need a 32 bit executable instead if 16 bit
>and thought I'd use FPC for that purpose.  Unfortunately FPC says it
>cannot find the WINDOS unit which is necessary for the GetEnvVar
>function I need.  I tried compiling the WINDOS.PAS unit found in the
>\BP\RTL\WIN directory, but I get many errors from FPC.

(blush)

Hmm, there seems to be none. On all targets except Dos,
GetEnv is being converted from pchar or ansistring to a plain TP one.

This will be fixed in the next version (1.0.6) :-)

Meanwhile, for Linux there is a GetEnv in the Linux unit, and for Windows
you could use this quick and dirty untested adaptation (I'm under FreeBSD at
the moment) from the Win32 version:

Uses Strings;

function GetEnvironmentStrings : pchar;
     external 'kernel32' name 'GetEnvironmentStringsA';
function FreeEnvironmentStrings(p : pchar) : longbool;
     external 'kernel32' name 'FreeEnvironmentStringsA';

Function  GetEnv(envvar: string): pchar;
var
   s : string;
   i : longint;
   hp,p : pchar;
begin
   getenv:=NIL;
   p:=GetEnvironmentStrings;
   hp:=p;
   while hp^<>#0 do
     begin
        s:=strpas(hp);
        i:=pos('=',s);
        if upcase(copy(s,1,i-1))=upcase(envvar) then
          begin
             getenv:=StrNew(hp);
             break;
          end;
        { next string entry}
        hp:=hp+strlen(hp)+1;
     end;
   FreeEnvironmentStrings(p);
end;



Sun, 10 Aug 2003 05:38:32 GMT  
 GetEnvVar in TPC versus FPC

Quote:

>>I've written a test cgi-bin program and used the TPC compiler
>>successfully.  However, I need a 32 bit executable instead if 16 bit
>>and thought I'd use FPC for that purpose.  Unfortunately FPC says it
>>cannot find the WINDOS unit which is necessary for the GetEnvVar
>>function I need.  I tried compiling the WINDOS.PAS unit found in the
>>\BP\RTL\WIN directory, but I get many errors from FPC.

>(blush)

>Hmm, there seems to be none. On all targets except Dos,
>GetEnv is being converted from pchar or ansistring to a plain TP one.

>This will be fixed in the next version (1.0.6) :-)

>Meanwhile, for Linux there is a GetEnv in the Linux unit, and for Windows
>you could use this quick and dirty untested adaptation (I'm under FreeBSD at
>the moment) from the Win32 version:

>Uses Strings;

>function GetEnvironmentStrings : pchar;
>     external 'kernel32' name 'GetEnvironmentStringsA';
>function FreeEnvironmentStrings(p : pchar) : longbool;
>     external 'kernel32' name 'FreeEnvironmentStringsA';

>Function  GetEnv(envvar: string): pchar;

Note, in the release it will be called "GetEnvironmentVariable" or so,
reside in sysutils, and use AnsiStrings (not pchar)


Sun, 10 Aug 2003 15:50:42 GMT  
 GetEnvVar in TPC versus FPC


Quote:



> >>I've written a test cgi-bin program and used the TPC compiler
> >>successfully.  However, I need a 32 bit executable instead if 16 bit
> >>and thought I'd use FPC for that purpose.  Unfortunately FPC says it
> >>cannot find the WINDOS unit which is necessary for the GetEnvVar
> >>function I need.  I tried compiling the WINDOS.PAS unit found in the
> >>\BP\RTL\WIN directory, but I get many errors from FPC.

> >(blush)

> >Hmm, there seems to be none. On all targets except Dos,
> >GetEnv is being converted from pchar or ansistring to a plain TP one.

> >This will be fixed in the next version (1.0.6) :-)

> >Meanwhile, for Linux there is a GetEnv in the Linux unit, and for Windows
> >you could use this quick and dirty untested adaptation (I'm under FreeBSD at
> >the moment) from the Win32 version:

> >Uses Strings;

> >function GetEnvironmentStrings : pchar;
> >     external 'kernel32' name 'GetEnvironmentStringsA';
> >function FreeEnvironmentStrings(p : pchar) : longbool;
> >     external 'kernel32' name 'FreeEnvironmentStringsA';

> >Function  GetEnv(envvar: string): pchar;

> Note, in the release it will be called "GetEnvironmentVariable" or so,
> reside in sysutils, and use AnsiStrings (not pchar)

Does using AnsiStrings for the "GetEnvironmentVariable" function mean
there will be a 255 character limit?  If so, then many of the "text
areas" used in HTML forms for letters, comments, or general text, will
not be totally usable since these variables tend to be large in size.
Using a pointer to a null terminated string would be much more flexible
(at least for me).

Jim



Mon, 11 Aug 2003 06:18:15 GMT  
 GetEnvVar in TPC versus FPC

Quote:

>> Note, in the release it will be called "GetEnvironmentVariable" or so,
>> reside in sysutils, and use AnsiStrings (not pchar)

>Does using AnsiStrings for the "GetEnvironmentVariable" function mean
>there will be a 255 character limit?

No. Ansistrings are dynamical and on the heap. You can even typecast them to
pchar (but it is wise to only access that pchar read-only then)

They are slightly (10-20%) slower than pchars, but nearly work like ordinary
TP strings. Main exception are their existance in records and that you are
not allowed to use s[0]:=newlength; and mylen:=s[0]; but should use length,
and the new procedure setlength(s,newlength);

Quote:
> If so, then many of the "text
>areas" used in HTML forms for letters, comments, or general text, will
>not be totally usable since these variables tend to be large in size.
>Using a pointer to a null terminated string would be much more flexible

There are HTML reading classes in the FCL iirc.


Mon, 11 Aug 2003 07:33:17 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. V.C++ versus V.Basic versus Delphi

2. FPC:problem with printing from fpc programs

3. FPC: translate execvp from c to FPC

4. TPC causes DOS window to halt in NT 4.0

5. Bizarre TPC Behavior

6. Bug in TPC 7

7. tpc command line compiling

8. TPC Freeware?

9. TPC/IP samples?

10. TPC/IP driver

11. slow FP with BPC (&TPC)

12. Performace BDE versus native interbase3.3 on unix

 

 
Powered by phpBB® Forum Software