+ codepage support for textrec/filerec and the above routines
* textrec/filerec now store the filename by default using widechar. It is
possible to switch back to ansichars using the FPC_ANSI_TEXTFILEREC define.
In that case, from now on the filename will always be stored in
DefaultFileSystemEncoding
* fixed potential buffer overflows and non-null-terminated file names in
textrec/filerec
+ dodirseparators(pwidechar), changed the dodirseparators(pchar/pwidechar)
parameters into var-parameters and gave those routines an extra parameter
that indicates whether the p(wide)char can be changed in place if
necessary or whether a copy must be made first (avoids us having to make
all strings always unique everywhere, because they might be changed on
some platforms via a pchar)
* do_open/do_erase/do_rename got extra boolean parameters indicating whether
the passed pchars point to data that can be freely changed (to pass on to
dodirseparators() if applicable)
* objects.pp: force assign(pchar) to be called, because
assign(array[0..255]) cannot choose between pchar and rawbytestring
versions (and removing the pchar version means that assign(pchar) will
be mapped to assign(shortstring) in {$h-})
* fixed up some routines in other units that depend on the format of
the textrec/filerec.name field
git-svn-id: branches/cpstrrtl@25137 -
this allows passing command lines longer than 126 chars to
Free Pascal or go32v2 programs.
By default only command lines longer than 126 chars are
passed using !proxy method,
it is however possible to disable this conversion completely by
set Use_go32v2_proxy boolean variable to false (true by fdefault).
In that case, command lines longer than 126 will be truncated, but
a warning is echoed to stderr.
For testing purposes, it is possible to set the boolean variable
force_go32v2_proxy to true to force systematic use of this
conversion.
This is set by default if the RTL is compiled with
SYSTEM_DEBUG_STARTUP conditional set.
To allow use by sysutils unit, a new procedure:
exec_ansistring(path : string;comline : ansistring);
has been added to the interface, which is now called instead
of Dos.Exec from Sysutils.ExecuteProcess
git-svn-id: trunk@18159 -
Int21/7303 is not related to lfn, since it's supported by win9x even when in DOS mode, while it's not supported by WinNTs.
The behaviour (inspired by djgpp) is then to try different methods:
* if the drive is a cdrom unit, try to ask to MSCDEX (this is required for pure DOS)
* else, try int21/7303 (it will work for non-cdrom drives under win9x when in DOS mode, and in Win9x dos box and FreeDOS)
* else, last choice is old int21/36 (it will work in MSDOS and WinNTs, though in the latter case sizes are wrong for free space or disk size > 2GB, but it's the best we can do)
This solves bug #11477
git-svn-id: trunk@11246 -
