Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Lars

Pages: 1 [2] 3 4 ... 90
16
I understood that fbc on Windows will cross-compile itself to result in an fbc (on Windows) that can then generate the assembler files to build itself which in turn can be assembled with the gnu assembler in OS/2.

17
Applications / Re: More WinOs/2 troubles
« on: August 09, 2024, 01:47:43 am »
I meant to say enhanced mode. If that does not work: too bad.

18
Applications / Re: Unzip Version 6.0 hangs when booting to a commandline
« on: August 08, 2024, 03:28:42 pm »
For once, F2 boot does not initialize Presentation Manager while any other boot does (maybe influenced by SET PROTSHELL and SET RUNWORKPLACE, however having \os2\boot\config.x , which is what is used if F2 is hit, use the same values as for normal boot does not make a difference).
As such, it is unrelated to the path rewriting hook DLL (prewrite) because the system exhibits the same behaviour if no hook DLL at all is loaded.

But there seems to be an additional difference when doing an F2 that influences libc behaviour. I am looking into libc. Using the logging version of libc gave me some clue of what does not look right. I just wonder why it would work with Presentation Manager up and running ...

19
Applications / Re: More WinOs/2 troubles
« on: August 07, 2024, 06:41:10 am »
I think, .VXD drivers cannot be loaded but .386 should do (maybe that also depends how the driver mucks with the OS. I am fairly sure the BC debugger uses that .386 driver to hook into the Windows kernel). But you will need to start Windows in extended mode. I forgot how to do that in OS/2 but I think you can configure that via the DOS/WIN settings for your Win31 object.

20
Applications / Re: Unzip Version 6.0 hangs when booting to a commandline
« on: August 05, 2024, 07:43:35 pm »
Thanks Rich, this is really appreciated, Ill give it a try.
A general fix for this problem would be great, I looked into libc but the process startup/DLL init/term code is so complicated that I cannot follow.
I already found it kind of frustrating that you have to build the rewriter DLL with gcc because of fork support but oh well, it's the way it is.

21
Applications / Re: Unzip Version 6.0 hangs when booting to a commandline
« on: August 04, 2024, 12:04:24 pm »
Hi Dave,

my experience with VAC 3.08 is that you need to use the header files that go along with it instead of using the header files of the Toolkit.
But I think this whole case is hopeless. The only solution is to avoid kLIBC built binaries when having booted to a commandline.

22
Applications / Re: Unzip Version 6.0 hangs when booting to a commandline
« on: August 04, 2024, 02:34:48 am »
1) Just run unzip without any parameters, and you get this:

UnZip 5.52 of 28 February 2005, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

or this:
UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

What you need to know (or find out via exehdr.exe giving you some hints on what UNZIP imports) is that UnZip 5.52 is built the conventional way via VAC or Watcom compiler and UnZip 6.00 is built with kLIBC with gcc compiler.


2) prewrite.dll is not loaded via loadtime linking (that is, together with the start of the application) but via runtime linking (that is dynamically, via a call to DosLoadModule). PMDLL can only show DLLS that are loaded via loadtime linking because for these, the executable contains information with the names of the DLLs to load and the names of the function entry points into the DLLs.

23
Applications / Re: Unzip Version 6.0 hangs when booting to a commandline
« on: August 02, 2024, 08:47:20 pm »
By now I have written my own prewrite.dll. That works (I am directly parsing klibcfg.ini) but the inital problem remains:
Having booted to a commandline, the Unix ported unzip.exe will still hang but can be killed with Ctrl-C.
As you said, there must be yet another issue because having no HOOK DLL at all leads to the same hang.

24
Applications / Re: Unzip Version 6.0 hangs when booting to a commandline
« on: August 02, 2024, 07:59:55 am »
Hi Steve,

yes I saw that you have come up with a replacement (the exact reason was that forked processes would not properly call the path rewriter DLL):
https://trac.netlabs.org/libc/ticket/190
https://trac.netlabs.org/libc/ticket/360

But even with prewrite.dll, when booting to a commandline, any Unix style app will hang, at least on my system.
The moment you call "PrfOpenProfile" will lead to a hang when you execute this from a boot commandline. Running without any prewrite hook dll will also lead to a hang but can be terminated via Ctrl-C.


@Pete: Note that I said "booted to a commandline" and not "booted to the desktop and using a commandline". This is as completely different pair of shoes as in the latter case, you have a fully working Presentation Manager environment.

Just give me some time of trial and error and I see where I end up.

@Steve: as a side question, can I assume that our gcc port has "__cdecl" as the standard calling convention ? Or would that be "__syscall" ? I assume the former but I am not sure.

25
Applications / Re: Unzip Version 6.0 hangs when booting to a commandline
« on: August 01, 2024, 09:30:17 pm »
prewrite.dll still expects %ETC%\klibcfg.ini to exist and contain the path transfomation rules. As much as I can tell from looking into prewrite.dll.
Which is the reason why it still fails when booted to commandline and a Unix ported app is invoked because it tries to use the "Prf" API to read the ini file which does not work without PM up and running.
I am going to glean binary parsing of INI files from  XWorkplace and implement a solution that can work without PM.

26
I now have an idea on how to solve this problem. Will take some trial and error and some time. NO guarantee that it will work but it's worth giving a try.

27
A solution to avoid a system hang is to remove the environment var statement:

set LIBC_HOOK_DLLS=....

from config.x. That at least will allow to hit Ctrl-C to stop the process instead of hanging the whole system.

28
Answer Silvan: the KLIBCCFG sources are lost. End of game.

29
I cannot find the source code for klibccfg.dll. I'll contact Silvan.

30
Well. at least that means it is a libcn problem. I could build a debug copy of unzip if you think it would help.
Perhaps better would be to try the logging version of libcn, @unixroot/usr/lib/log/libcn0.dll I believe. You have to swap it with the usual libcn and reboot, libpathstrict does not work with libc. See https://trac.netlabs.org/libc/wiki/LibcLogging.
@Andi, the OpenWatcom debugger won't work, need to use a native debugger.

Hi Dave,

thanks for the hint. I now did as you suggested and I get the attached as a result. The system hung solid so the last log entry was the last thing that was logged. I am beginning to suspect it is because KLIBCCFG.DLL pulls in so many things, for example FFST (I had a look at KLIBCCFG.DLL with PM DLLTree).

And here comes the biggest problem: _kLIBCInitPath in KLIBCCFG.DLL will likely read its transformed paths from INI file %ETC%\klibccfg.ini where I suspect, it uses the profile API calls. I think, those will only work if PM is up and running.

In short: every program built with kLIBC depends on PM being loaded. I tested this by setting RUNWORKPLACE to cmd.exe (therefore only booting with PM but without the WPS) and then running unzip.exe from that commandline and that worked ok.

The solution would be to replace the profile API calls in KLIBCCFG.DLL against calls that directly work on the binary .INI files. I think XWorkplace also does that.

Pages: 1 [2] 3 4 ... 90