X-Authentication-Warning:	delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient:	djgpp-workers AT delorie DOT com
Message-ID:	<5AFF1112.20804@gmx.de>
Date:	Fri, 18 May 2018 19:44:50 +0200
From:	"Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp-workers AT delorie DOT com]" <djgpp-workers AT delorie DOT com>
User-Agent:	Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.13) Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7
MIME-Version:	1.0
To:	djgpp-workers AT delorie DOT com
Subject:	Re: DJGPP on NTF with SFN creating disabled [was : gcc-8.1.0 packages
	for testing]
References:	<0244cff9-6176-8aec-bbc2-6fc49602c295 AT iki DOT fi> <558b5ff2-71df-e556-a874-7acbb264c84a AT iki DOT fi> <5AED9B44 DOT 90000 AT gmx DOT de> <df616b96-646c-788b-3177-87de740f03ae AT iki DOT fi> <5AEF5D3A DOT 2030409 AT gmx DOT de> <3569b441-e678-7252-ffdd-7c45f72a5c56 AT iki DOT fi> <5AFDE635 DOT 9030405 AT gmx DOT de> <83muwxijf0 DOT fsf AT gnu DOT org>
In-Reply-To:	<83muwxijf0.fsf@gnu.org>
X-Provags-ID:	V03:K1:qQSd7mRXIAoHlsCMMgsv4C9q9GcmwgqAzvZ8ZpbBMFA6VpI0Eft
	N6JNYQ202QWvc8bm7ngjvNBErvxVZHv9qBFPLYaIy1NpxOGw6cmzcPMjk7sGWnX5yeq01GK
	P4llTb0H59cjyGNK0Xb61X171OXicEj0E/SIXYEvmgsSwZa8lhhtjg/GSjq9YZZs0Z92KxU
	jHs2nZ5rovrBEXDBtO4KQ==
X-UI-Out-Filterresults:	notjunk:1;V01:K0:uujsf68XUso=:3JF4s+5+8EYxvQzTkVDE2L
	hU+k3qZ/5lXR59U06G/7sse+1ksANz7bd1MZfC+HfKYoy8eXH48nXLXxZK04BTz8gdk8O76NO
	epmwUPvaa2Ge8KELMblRXIlP02UUxP8vymBHbuRqgpUCqVnO4UCYuLMzmWVzkH/r/uEGMnkTA
	XnLzceVPyXH+D2K97Jel+OoLd69g/fyPOQ4I3/ffNgOw6+zHgDa51E9Mbf4veexjOF07rj33C
	x2HS9/zsloJM4qanpk7l+AoQmOeDYcjGsBDqiUs+jYUqFWt51ZgV6QeXjUWGXuCcXv92C/LFO
	ILz12/MToEFyyynrJclyvgba/4dON7eAi7iaURqoVvljxot7LUwIFa/QJuYj6N4b1UUR1a2Pn
	51cD9uA4Y5Af2HZv8YiNfW4vm2aM1TIJaMOA8XPl+n//9RpSnzgAN9XfE0Jrl3DIcwJGDYVeY
	I4mpO7D73Lf3AzEn5RcqzaSQjw9RhFpkUmbQCdsTObCdgEgTTvn1h4jW4Aj+b37tNxRvT70Zy
	sSa0l/m6iXRk7thaW2gZD/vUtuAN5YpbGb8nGyDNy5Dgp14nlfvW9Xz6O12A5Kyu45mEB6wVD
	dSmWjBhThtcfy4bYN396R6swZqUK/6phB8S4ORo+duLaa7nfRkRvbgiVRXYZq6Ob/UXi0shHU
	OJmXmYPidQWhyMzlG5ZSDVzZo0IfUF888HoYyWEndb5YQCluIa/a2d8IzclVu3s6Qb/R1NlGy
	EsZE//fhXfGjyLpFWWGyAUq/elnzvHfsvbowA46ul5kfaZ1nocb1gvCAKuSdkrwgypcUpzxSw
	7Pm+ypl
Reply-To:	djgpp-workers AT delorie DOT com

Am 18.05.2018 08:09, schrieb Eli Zaretskii (eliz AT gnu DOT org) [via djgpp-workers AT delorie DOT com]:
>> Date: Thu, 17 May 2018 22:29:41 +0200
>> From: "Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp-workers AT delorie DOT com]"<djgpp-workers AT delorie DOT com>

[snip]

>> The issue concerning the call of the system function is something completely
>> different and cannot be fixed at all.  In the end, the call of system()
>> issues a call of INT21 0x4B00.  One of the arguments passed to function
>> 0x4B00 is the full path of the program to be started and this path and the
>> file name must be a valid DOS path and file name.  This means that the file
>> name must be a valid 8.3 file name and the path length is not allowed to
>> exceed the max. length of a DOS path (IIRC 64 characters).
>
> So you are saying that on a system where SFN is disabled, DJGPP will
> be unable to start programs whose executable file names don't match
> the DOS SFN limitations, is that true?  Then it follows that DJGPP
> will be much less useful on such systems, and will be confined to
> directories whose names fit those limitations.

Yes.
DJGPP is limited by the limitations imposed by INT21 0x4BNN.  For the
versions of DOS that I have inspected, there is no solution for this
issue.  If the absolute LFN file name does not map to a valid DOS file
name, then in the best case the running application gets a "file not found"
error from the system() call and in the worst case it make the machine
freeze.  E.g.:
   z:\a_very_long_directory_name\another_very_long_directory_name\a_very_long_file_name_with.extension
is OK because it becomes a valid DOS path like:
   z:\a_very_l\another_v\a_very_l.ext
as long as it is unique.  But if the SFN does not exist for the LFN
then it does not work.  I cannot talk for other DOS implementations.
I do not know if it works for FreeDOS, or Vista or other Windows versions.

> One comment about the patch:
>
>> +typedef enum {
>> +  false = 0, true = 1
>> +} bool;
>
> We have stdbool.h, so why do we need this enumeration?

The reason why I have retained the enum from the original
patch is because I have seen that in doprnt.c stdbool.h had
also been replaced by an enumeration, thus I have done the
same here.  I do not understand why that was necessary at all
in doprnt.c but to avoid inconveniences I have done the same
here.  I have no preferences. I will use stdbool.h instead.

Regards,
Juan M. Guerrero

- Raw text -