Something Odd

[Paul S. Person]

Something odd just happened.

When I enter the command line

wgml boxtest ( dev ps file psfont

at a Windows 8.1 command line prompt, it executes.

Well, actually it GP-faults, which explains the next step. But that is
nearly as good, since to GP-fault it must run, and to run it must be
found, and so it must be on the Path.

When I enter the command line

wdw wgml boxtest ( dev ps file psfont

at the same Windows 8.1 command line prompt, wdw claims that it cannot
find the program.

When I dig down using the browse button in wdw so that it can find the
file, it works and I can see where the program is messing up (as is
typical, it is trying to free one of our pools, which means I have
managed to bollix a linked list somewhere).

Invoking wdw this way /used/ to work. It appears to be ignoring the
Patth environment variable. Any ideas what is causing this?

[Hans-Bernhard Bröker]

Post by Paul S. Person
Invoking wdw this way /used/ to work. It appears to be ignoring the
Patth environment variable. Any ideas what is causing this?

More likely than not, it's the contents of %PATH% that's doing this to
you. E.g. Windows used to require blanks in the %PATH% to be escaped /
avoided, but at some point they stopped doing that. Who knows what wdw
might to with unescaped blanks in there...

[Paul S. Person]

On Sat, 18 Oct 2014 23:19:58 +0200, Hans-Bernhard Bröker

Post by Hans-Bernhard Bröker

Post by Paul S. Person
Invoking wdw this way /used/ to work. It appears to be ignoring the
Patth environment variable. Any ideas what is causing this?

More likely than not, it's the contents of %PATH% that's doing this to
you. E.g. Windows used to require blanks in the %PATH% to be escaped /
avoided, but at some point they stopped doing that. Who knows what wdw
might to with unescaped blanks in there...

I made a few changes to the official Windows 8.1 global PATH last
night, so I rechecked this and it still behaves the same way.

It is invoked in

C:\Users\Paul\Documents\ProgDev\Cpp\owTest\wgml\testlib

and the Path at the point of invocation is: :

PATH=c:\ow\ow\bld\wgml\research\nt386;c:\ow\ow\bld\wgml\nt386;C:\Users\Paul\Docu
ments\ProgDev\Cpp\owTest\wgml;c:\ow\ow\bld\build\binnt;c:\ow\ow\bat;c:\ow\owc_c+
+\binnt;c:\ow\owc_c++\binw;C:\windows\system32;C:\windows;C:\windows\System32\Wb
em;C:\windows\System32\WindowsPowerShell\v1.0\;c:\Program Files
(x86)\ATI
Technologies\ATI.ACE\Core-Static;C:\ProgramFiles\Hewlett-Packard\SimplePass\;C:\Progr
am Files (x86)\Windows Live\Shared;C:\Program Files (x86)\AOMEI
Backupper Professional Edition
2.0.2;C:\Users\Paul\Documents\ProgDev\Cpp\owExtra\Scripts;C:\Prog
ram Files (x86)\Perforce

As you can see, the relevant parts have no spaces -- and are listed
first.

Resetting PATH to

PATH=c:\ow\ow\bld\wgml\research\nt386;c:\ow\ow\bld\wgml\nt386;
C:\Users\Paul\Documents\ProgDev\Cpp\owTest\wgml;
c:\ow\ow\bld\build\binnt;
c:\ow\ow\bat;c:\ow\owc_c++\binnt;
c:\ow\owc_c++\binw;
C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0

(when I reset it, I of course pasted it as a single line, but I have
broken it up a bit for readability above) ... it works! Apparently,
you can't have /any/ spaces in the path, even if the bits actually
being used come first.

So, I guess I will have to modify the path in my setup file to include
only the parts I need, leaving out the stuff in Program Files (x86).

Is this in Bugzilla? Should it be? I mean, DOS/Windows paths are ended
by ";" or EOL, not by spaces, and the only thing wdw has to do is pass
each segment to whatever it uses to find files, and so doesn't need to
parse the content of the segment, so isn't this a problem with wdw?

I remember writing code to convert a Path (wgml uses several) into an
array of char *s (one per segment), and I know I tested it, but I
don't recall if I tested it with segments containing spaces.

[Hans-Bernhard Bröker]

Post by Paul S. Person
(when I reset it, I of course pasted it as a single line, but I have
broken it up a bit for readability above) ... it works!

On actual experimentation it turns out to be even simpler. It's not the
blanks. It's the total length of the PATH that breaks this. Even a
path with no blanks will still breaks as long as it's longer than about
512 characters. Reeking of a buffer size limit, that is.

[Paul S. Person]

On Sun, 19 Oct 2014 21:17:23 +0200, Hans-Bernhard Bröker

Post by Hans-Bernhard Bröker

Post by Paul S. Person
(when I reset it, I of course pasted it as a single line, but I have
broken it up a bit for readability above) ... it works!

On actual experimentation it turns out to be even simpler. It's not the
blanks. It's the total length of the PATH that breaks this. Even a
path with no blanks will still breaks as long as it's longer than about
512 characters. Reeking of a buffer size limit, that is.

Oh, that's great.

WDW, when it finds a too-long path, just gives up?

My code, FWIW, is in bld\watcom\c\findfile.c.

Is this already in Bugzilla? Should it be?

[Hans-Bernhard Bröker]

Post by Paul S. Person
On Sun, 19 Oct 2014 21:17:23 +0200, Hans-Bernhard Bröker

Post by Hans-Bernhard Bröker
On actual experimentation it turns out to be even simpler. It's not the
blanks. It's the total length of the PATH that breaks this. Even a
path with no blanks will still breaks as long as it's longer than about
512 characters. Reeking of a buffer size limit, that is.

Oh, that's great.

Not so sure that finding a fixed buffer size limitation is great...

Post by Paul S. Person
WDW, when it finds a too-long path, just gives up?

The culprit is actually bld\trap\lcl\nt\c\accmisc.c::FindFilePath(). It
tries to capture the PATH variable using a 512-byte buffer.

Post by Paul S. Person
Is this already in Bugzilla? Should it be?

No. Yes. Added it.

[Paul S. Person]

On Thu, 23 Oct 2014 02:08:23 +0200, Hans-Bernhard Bröker

Post by Hans-Bernhard Bröker

Post by Paul S. Person
On Sun, 19 Oct 2014 21:17:23 +0200, Hans-Bernhard Bröker

Post by Hans-Bernhard Bröker
On actual experimentation it turns out to be even simpler. It's not the
blanks. It's the total length of the PATH that breaks this. Even a
path with no blanks will still breaks as long as it's longer than about
512 characters. Reeking of a buffer size limit, that is.

Oh, that's great.

Not so sure that finding a fixed buffer size limitation is great...

Post by Paul S. Person
WDW, when it finds a too-long path, just gives up?

The culprit is actually bld\trap\lcl\nt\c\accmisc.c::FindFilePath(). It
tries to capture the PATH variable using a 512-byte buffer.

Post by Paul S. Person
Is this already in Bugzilla? Should it be?

No. Yes. Added it.

Thanks for your help.

FWIW, I apparently found a function,

getenv_s( &path_length, NULL, 0, "PATH" );

that returns the length of the PATH variable in path_length. Of
course, this was only tested under XP (and maybe even NT 4), so
whether it works with older versions of Windows (particularly the
"hone user" series starting with Win95) is unknown. It pretty clearly
works with 8.1, since our wgml finds its files.

[Frank Beythien]

Post by Paul S. Person
FWIW, I apparently found a function,
getenv_s( &path_length, NULL, 0, "PATH" );
that returns the length of the PATH variable in path_length. Of
course, this was only tested under XP (and maybe even NT 4), so

No, it is tested as part of the normal clib function QA test for most
targets (not qnx and RDOS I think)

And don't forget to include

#define __STDC_WANT_LIB_EXT1__ 1
#include <stdlib.h>

for the XXX_s function prototypes. This is done by default for building
WGML...

Post by Paul S. Person
whether it works with older versions of Windows (particularly the
"hone user" series starting with Win95) is unknown. It pretty clearly
works with 8.1, since our wgml finds its files.

CU
Frank

[Hans-Bernhard Bröker]

Post by Paul S. Person
On Thu, 23 Oct 2014 02:08:23 +0200, Hans-Bernhard Bröker

Post by Hans-Bernhard Bröker

Post by Paul S. Person
WDW, when it finds a too-long path, just gives up?

The culprit is actually bld\trap\lcl\nt\c\accmisc.c::FindFilePath(). It
tries to capture the PATH variable using a 512-byte buffer.

FWIW, I apparently found a function,
getenv_s( &path_length, NULL, 0, "PATH" );
that returns the length of the PATH variable in path_length.

There are several functions used to search stuff in the path, or to just
access the PATH variable, in the source code. I'm just not sure that
they can be used in a trap DLL. Memory and/or stack may be more limited
in there than it is elsewhere.

[Paul S. Person]

On Thu, 23 Oct 2014 21:02:12 +0200, Hans-Bernhard Bröker

Post by Hans-Bernhard Bröker

Post by Paul S. Person
On Thu, 23 Oct 2014 02:08:23 +0200, Hans-Bernhard Bröker

Post by Hans-Bernhard Bröker

Post by Paul S. Person
WDW, when it finds a too-long path, just gives up?

The culprit is actually bld\trap\lcl\nt\c\accmisc.c::FindFilePath(). It
tries to capture the PATH variable using a 512-byte buffer.

FWIW, I apparently found a function,
getenv_s( &path_length, NULL, 0, "PATH" );
that returns the length of the PATH variable in path_length.

There are several functions used to search stuff in the path, or to just
access the PATH variable, in the source code. I'm just not sure that
they can be used in a trap DLL. Memory and/or stack may be more limited
in there than it is elsewhere.

Good point. I didn't look too closely at where the problem is.

[Hans-Bernhard Bröker]

Post by Paul S. Person
On Thu, 23 Oct 2014 21:02:12 +0200, Hans-Bernhard Bröker

I'm just not sure that they can be used in a trap DLL.
Memory and/or stack may be more limited
in there than it is elsewhere.

Good point. I didn't look too closely at where the problem is.

I've upped the size from 512 to 2048. It's still fixed-size, but I
don't feel entirely comfortable using malloc() or similar in a trap DLL.
Maybe Michal could have a look at it?

[Paul S. Person]

On Sat, 25 Oct 2014 15:31:27 +0200, Hans-Bernhard Bröker

Post by Hans-Bernhard Bröker

Post by Paul S. Person
On Thu, 23 Oct 2014 21:02:12 +0200, Hans-Bernhard Bröker

I'm just not sure that they can be used in a trap DLL.
Memory and/or stack may be more limited
in there than it is elsewhere.

Good point. I didn't look too closely at where the problem is.

I've upped the size from 512 to 2048. It's still fixed-size, but I
don't feel entirely comfortable using malloc() or similar in a trap DLL.
Maybe Michal could have a look at it?

Thanks.

I build weekly, so, after next Saturdays, I will copy the wdw from
rel2 over and see how it does with the full path.

[Paul S. Person]

On Sun, 26 Oct 2014 10:42:22 -0700, Paul S. Person

Post by Paul S. Person
On Sat, 25 Oct 2014 15:31:27 +0200, Hans-Bernhard Bröker

Post by Hans-Bernhard Bröker

Post by Paul S. Person
On Thu, 23 Oct 2014 21:02:12 +0200, Hans-Bernhard Bröker

I'm just not sure that they can be used in a trap DLL.
Memory and/or stack may be more limited
in there than it is elsewhere.

Good point. I didn't look too closely at where the problem is.

I've upped the size from 512 to 2048. It's still fixed-size, but I
don't feel entirely comfortable using malloc() or similar in a trap DLL.
Maybe Michal could have a look at it?

Thanks.
I build weekly, so, after next Saturdays, I will copy the wdw from
rel2 over and see how it does with the full path.

And it works ... now that I copied the new std.dll over!

Thanks!