Custom Query (245 matches)

Currently, in order to better support the Unix-like file system structure (which in turn simplifies porting of many Unix software to OS/2) the /@unixroot path rewrite rule is used. This pseudo-path is replaced with the value of the UNIXROOT environment variable which makes it possible to move the Unix file system from drive to drive w/o breaking software.

However, this technique still requires one change to the original Unix sources: you have to replace each / which is meant as the root of the Unix file system tree along the sources and makefiles with /@unixroot. This is quite annoying (as there may be dozens of places where this change is needed) and error prone (you may forget one place and this will break everything).

I suggest to extend UNIXROOT support by changing the path rewriter so that it will always treat paths starting with / as Unix-like paths and therefore replace / with the value of UNIXROOT. This will eliminate the need of prepending /@unixroot to them. In theory, many programs should just build and work out-of-the-box.

The only thing that we will lose with such a change is the original meaning of / as a reference to the root directory of the current drive. Though I don't think that this feature is really used by any software, it may be expected by the end user. So it sounds reasonable to make it optional (and even off by default).

Since r3645 (AFAIU), spawn() passes some hidden arguments to the started executable if it is a kLIBC-based one. In some cases this makes problems for other applications. One of such examples is Odin-based applications (e.g. OpenJDK). In Odin, KERNEL32.DLL needs to process the command line. Since the DLL can't currently access the main() arguments, it has to access the command line directly using PIB pointers and this makes those hidden arguments (in particular the "kLIBC" signature) visible to the application which it totally does not expect. In particular, java.exe will simply fail with the message like "cannot filnd class kLIBC".

For now I have to add a hack to Odin that cuts out the "kLIBC" signature from the command line. But this hack depends on kLIBC internals and will not work if these internals change.

A proper way will be to provide global argc and argv pointers that will let any DLL access the command line post-processed by kLIBC in a way it needs.

On my sever with a "cron" type process running fork/system/popens very frequently. The end result is that after so long any program that uses LIBC065 will fail to start with a "LIBC Error: Couldn't register process in shared memory!" Anything that is already started or does not use LIBC065 just sails along merrily. Although the ones that do use it may hang when you try and shutdown.

On my laptop I can reproduce the first type by using "ps" but if I change it to a "hello world" program I get the "nothing will shut down" problem. I think the problem has been around for a long time as I have *never* had uptime on the server of more than three weeks - I think LIBC065 has just made it worse - I never saw that libc error message before 65 came along.

The following program shows the problem:

#include <os2.h> #include <string.h> #include <stdio.h> #include <stdlib.h> #include <sys/time.h> #include <errno.h>

int main(int argc, char argv) {

char psline[256], temp[128]; char ps_string[] = "hw.exe";

long count;

FILE *ptr;

for(count = 1;; count++) {

ptr = popen(ps_string, "r");

if ( ptr == NULL ) {

int local_errno = errno; printf("\npopen(%s read) failed: %s\n", ps_string, strerror(local_errno)); exit(0);

}

fgets(psline, 80, ptr); /* read header line */

while( fgets(temp, 80, ptr) != NULL ); /* read away rest of popen pipe */ pclose(ptr); printf("\r%ld %s", count, psline);

}

}

and

#include <os2.h> #include <string.h> #include <stdio.h> #include <stdlib.h>

int main(int argc, char argv) {

printf("Hello World");

}

It usually blows around 60,000. Suspect 65535 problem?

I complied the above with EMX and got bored with it at 70,000+