Hello, I want equivalents for the following .Could any one help me out : -- swap --get/freeenvironmentstrings --exitproc, exitcode --constants like "fmclosed", "fmoutput" etc.. Otherwise are there any compiler directives to avoid the above (supported by delphi)? Is Class type supported by GPC ?
Thanks and Regards Hari
On 28 Aug 2001, at 15:06, Kocherlakota Harikrishna wrote:
Hello, I want equivalents for the following .Could any one help me out : -- swap --get/freeenvironmentstrings --exitproc, exitcode --constants like "fmclosed", "fmoutput" etc..
Some of them are in the dos and system units, and some of them don't exist anywhere. The get/freeenvironmentstrings stuff is purely a Windows API thing, so don't expect to find them in a standard GPC distribution. However the dos unit contains some routines for environment variables.
Otherwise are there any compiler directives to avoid the above (supported by delphi)?
You could always supply switches to force compliance with one of the "standards" (e.g., EP, ISO, etc.).
Is Class type supported by GPC ?
No.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
On 28 Aug 2001, at 15:06, Kocherlakota Harikrishna wrote:
Hello, I want equivalents for the following .Could any one help me out : -- swap --get/freeenvironmentstrings --exitproc, exitcode --constants like "fmclosed", "fmoutput" etc..
Some of them are in the dos and system units, and some of them don't exist anywhere. The get/freeenvironmentstrings stuff is purely a Windows API thing, so don't expect to find them in a standard GPC distribution.
What do they do? Perhaps we can easily emulate them.
Frank
On 29 Aug 2001, at 3:38, Frank Heckenbach wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
On 28 Aug 2001, at 15:06, Kocherlakota Harikrishna wrote:
Hello, I want equivalents for the following .Could any one help me out : -- swap --get/freeenvironmentstrings --exitproc, exitcode --constants like "fmclosed", "fmoutput" etc..
Some of them are in the dos and system units, and some of them don't exist anywhere. The get/freeenvironmentstrings stuff is purely a Windows API thing, so don't expect to find them in a standard GPC distribution.
What do they do? Perhaps we can easily emulate them.
They are easy to emulate. The problem with emulating them in a standard unit will be in those of us who use the WinAPI in Windows programs would then have linker problems (until GPC gets qualified identifiers). So perhaps a new "Delphi compat" unit should be created if you want to emulate these things.
"GetEnvironmentStrings" returns a pointer (pChar in Delphi) to an environment block for the current process. This is basically a list of all the environment variables (each separated by a #0 and the whole list is terminated by a #0#0). "FreeEnvironmentStrings" frees the memory allocated for the block returned by "GetEnvironmentStrings".
The declarations are thus; Function GetEnvironmentStrings : pChar; Function FreeEnvironmentStrings (EnvBlock : pChar) : Boolean; { returns true if the function succeeds }
How do you use the pointer returned by GetEnvironmentStrings? You walk through it (i.e., jumping from one #0 to the next, etc) until you find the variable that you want. It is ugly - but like I said, it is pretty easy to emulate. Now, why someone would want to use this ugly M$ stuff instead of the more sensible ones in the Dos unit beats me.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
On 29 Aug 2001, at 3:38, Frank Heckenbach wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
On 28 Aug 2001, at 15:06, Kocherlakota Harikrishna wrote:
Hello, I want equivalents for the following .Could any one help me out : -- swap --get/freeenvironmentstrings --exitproc, exitcode --constants like "fmclosed", "fmoutput" etc..
Some of them are in the dos and system units, and some of them don't exist anywhere. The get/freeenvironmentstrings stuff is purely a Windows API thing, so don't expect to find them in a standard GPC distribution.
What do they do? Perhaps we can easily emulate them.
They are easy to emulate. The problem with emulating them in a standard unit will be in those of us who use the WinAPI in Windows programs would then have linker problems (until GPC gets qualified identifiers). So perhaps a new "Delphi compat" unit should be created if you want to emulate these things.
"GetEnvironmentStrings" returns a pointer (pChar in Delphi) to an environment block for the current process. This is basically a list of all the environment variables (each separated by a #0 and the whole list is terminated by a #0#0). "FreeEnvironmentStrings" frees the memory allocated for the block returned by "GetEnvironmentStrings".
The declarations are thus; Function GetEnvironmentStrings : pChar; Function FreeEnvironmentStrings (EnvBlock : pChar) : Boolean; { returns true if the function succeeds }
How do you use the pointer returned by GetEnvironmentStrings? You walk through it (i.e., jumping from one #0 to the next, etc) until you find the variable that you want. It is ugly - but like I said, it is pretty easy to emulate. Now, why someone would want to use this ugly M$ stuff instead of the more sensible ones in the Dos unit beats me.
Me too. Internally, GPC stores its environment differently (schema array of CStrings), but it wouldn't be too hard to write a function that creates such a structure on demand. Should I do that (in the System unit)?
Frank
On 31 Aug 01, at 23:24, Frank Heckenbach wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
[...]
How do you use the pointer returned by GetEnvironmentStrings? You walk through it (i.e., jumping from one #0 to the next, etc) until you find the variable that you want. It is ugly - but like I said, it is pretty easy to emulate. Now, why someone would want to use this ugly M$ stuff instead of the more sensible ones in the Dos unit beats me.
Me too. Internally, GPC stores its environment differently (schema array of CStrings), but it wouldn't be too hard to write a function that creates such a structure on demand. Should I do that (in the System unit)?
Like I said, putting them in any of the standard units (unless you change the names slightly) will create problems for those who use the real WinAPI stuff. In Delphi, you have to USE the Windows unit to get access to those functions. I have a functional Windows unit for the WinAPI imports, and there will be name clashes. So, until GPC gets qualified identifiers, I suggest you put them in a totally new Delphi compat unit so that nothing else is affected.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) Author of: Chief's Installer Pro for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm Email: African_Chief@bigfoot.com
Prof Abimbola Olowofoyeku wrote:
On 31 Aug 01, at 23:24, Frank Heckenbach wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
[...]
How do you use the pointer returned by GetEnvironmentStrings? You walk through it (i.e., jumping from one #0 to the next, etc) until you find the variable that you want. It is ugly - but like I said, it is pretty easy to emulate. Now, why someone would want to use this ugly M$ stuff instead of the more sensible ones in the Dos unit beats me.
Me too. Internally, GPC stores its environment differently (schema array of CStrings), but it wouldn't be too hard to write a function that creates such a structure on demand. Should I do that (in the System unit)?
Like I said, putting them in any of the standard units (unless you change the names slightly) will create problems for those who use the real WinAPI stuff. In Delphi, you have to USE the Windows unit to get access to those functions. I have a functional Windows unit for the WinAPI imports, and there will be name clashes. So, until GPC gets qualified identifiers, I suggest you put them in a totally new Delphi compat unit so that nothing else is affected.
That's why I thought of the System unit (which GPC does not use automatically). But, of course, I have no personal interest in writing them at all, so if they're typically only used with other WinAPI routines, it might not be worth to write replacements, but rather a WINE interface or something for those who'll need it ...
Frank
On 1 Sep 01, at 15:58, Frank Heckenbach wrote:
[...]
Like I said, putting them in any of the standard units (unless you change the names slightly) will create problems for those who use the real WinAPI stuff. In Delphi, you have to USE the Windows unit to get access to those functions. I have a functional Windows unit for the WinAPI imports, and there will be name clashes. So, until GPC gets qualified identifiers, I suggest you put them in a totally new Delphi compat unit so that nothing else is affected.
That's why I thought of the System unit (which GPC does not use automatically). But, of course, I have no personal interest in writing them at all, so if they're typically only used with other WinAPI routines, it might not be worth to write replacements, but rather a WINE interface or something for those who'll need it ...
Well, my suggestions here are a bit self-serving, because I normally USE the System unit, and I also have a functional "Windows" unit (the WinAPI imports unit). This of course means linker problems if the new routines are also in the System unit. One possible solution is to have them in the System unit, but to have them within an IFDEF. However, GetEnvironmentStrings et. al. do not really serve any useful purpose when you have the Dos unit, because there are Pascal routines in the Dos unit which do a better job, and without ugly C constructs.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) Author of: Chief's Installer Pro for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm Email: African_Chief@bigfoot.com
-
Frank Heckenbach -
Kocherlakota Harikrishna -
Prof Abimbola Olowofoyeku -
Prof. A Olowofoyeku (The African Chief)