Virtual Pascal

Classic Object Pascal for free

I needed something to do more sensible parsing of command lines than simply using paramstr(), so I had a look at FreePascal's getopts unit, but as yet I haven't been able to compile it.


Problem one, the

{$IF not Declared(argv)} //{$ifdef TP}

directive. I guess it is FPC specific and can be left out, effectively assuming that VP = TP.


Problem two, the

inc(PByte(p), sizeof(toption)); //inc(pointer(p),sizeof(toption)); // for Delphi compatibility


statement. I guess a PByte is a pointer to byte, and that's how it's declared in numerous files in the file, but aliasing a pointer to a byte seems rather type-unsafe. Un-commenting the now commented statement, I get a "Error 104: Ordinal variable expected", which also makes little sense.


Actually defining TP gives various other errors.


Anyone already made this unit VP compatible and willing to share it?

Views: 294

Reply to This

Replies to This Discussion


Sorry to reply so late to this post, but perhaps my addition will be valuable to someone.

I have been using Virtual Pascal off and on for a while, but haven't done anything serious for a while.  I encountered a minor (but annoying) bug in the IDE for version 2.79, so am using 2.74 instead.  My latest project encountered the same problem as you voiced here, and in another post ("Severe bug in VPASCAL commandline handling") in command line handling.  The official VP documentation says "The program name and the parameters are separated by a #0 character." - this is bad, since when this is done, the command line returned will always stop at the first #0 encountered; parameters will not be in the string!  I think this comes from the MSDN documentation for the CreateProcess function which says that "The system adds a terminating null character to the command-line string to separate the file name from the arguments.   This divides the original string into two strings for internal processing."  The catch here is INTERNAL processing!

Anyway, I have written a small unit which fixes all these problems - command line retrieval and processing of parameters  (including quotes on the EXE or parameters!) - and have included it here.  There are some comments in the file, but it can be used "as-is" for all (?) versions of Virtual Pascal to overcome these issues.  This probably comes too late to be of any use for you, but I thought I should "throw it out there" anyway.

The "getopts" unit (Free Pascal), by the way, was something I looked at to put this unit together, but I think it is more detailed than necessary in the way it handles all types of parameters.  Individual applications can handle parameters in their own way, but they MUST be retrieved properly!

- Allen


Note that a max_path of 260 is an old doslike (LFN API) limitation. NT allows longer paths using  \\?\ prefix(*), see

oh, and 8192 ARG_MAX is one of the lowest :-) I think Linux is 131072 or so :-)

((*) anything pre Windows XP is now officially deprecated by MS. That doesn't mean you have to drop it immediately, but I wouldn't consider it for new development)

And the 8192 limitation is a cmd.exe limitation. The limitation of the windows kernel itself is 32k. Since your program might be launched by a different program, this is afaik not safe.


Thanks for the comments!  The little unit was put together quickly, just to solve a problem - Virtual Pascal (both builds 2.74 and 2.79) doesn't fetch the command line parameters reliably - the parsing is flawed, especially if spaces exist in the path or program name.  Anyone could modify the unit easily to increase the buffer size for the GetModuleFileNameA call (that call taken from Free Pascal 2.4.4, by the way - rtl/win32/system.pp - they use a 260 byte buffer).  The 8192 byte limit for arguments comes from MSDN's command prompt (Cmd.exe) description (non-Unicode?) at, old - yes, but then it would be compatible with XP (no service packs?).  I can't imagine launching a command prompt program with an 8000 byte command line!

Cheers, and Merry Christmas,


I just saw some numbers that looked outdated, and did a quick google to confirm and posted the results.

FPC is certainly not clean at this moment. A ful decision to drop legacy windows (win9x) hasn't been taken, and wince compat also takes its toll.

Compatible yes, but you might lose chars. When having batchfiles or programs construct arguments they can get very long. And if you execute the file without cmd.exe, it can even be 32kb.

The classic example being the GNU archiver AR, that wants all object files on the commandline. And when smartlinking in the past every symbol became a file.....


© 2022   Created by Allan Mertner.   Powered by

Report an Issue  |  Terms of Service