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 5 ... 26
31
But what's more: this mismatch between the filename and the internal module name will eventually massively confuse/screw up the module loader (if done repeatedly) until the whole system reboots without showing any trap screen or the like.

Quote
I could easily create a test case that would blow your whole system just by creating (and loading a DLL) that has a mismatch in filename and internal module name.

What if  you prepare some test so I can run it om my computer and have this reboot?

Ok, just give me some time. Where can I send that ?

32
Programming / Re: OW, JNI (GCC built java 1.6) and parameters
« on: April 01, 2019, 06:06:28 pm »
I think the problem he tries to catch is that some DLLs keep resetting the FPU control word to what they think is correct. So if you call a routine in those DLLs, the FPU control word will be modified when the call returns (which of course is bad,bad,bad).
Jan-Erik does set the FPU control word to what he wants (namely, to disable all FPU exceptions).
But then he wants to register an exception handler so that if something resets the FPU control word and subsequently an FPU exception occurs he can reset the FPU control word to what he wants (namely, to disable all FPU exceptions)

33
MMRES_DE.DLL  installed with eCS 2.2 beta. Back at the time, I chose the installation in german.
Maybe you need to look into the CWMM install package to find it (but I don't know where you find that on the DVD, eCS or ArcaOS).
If you want to experience the "sudden system reboot", what you can do is to back up mmres_en.dll, lxlite /x the DLL, use a hex editor to change the internal module name from MMRES_EN to say MMRES_DE and save back.
For once that will prevent the DLL from loading. But if you try often enough (by invoking volume.exe multiple times, say 10 times) it will eventually take down your whole system.

34
Applications / Re: nguest2.exe (netop) fails to start
« on: March 31, 2019, 09:36:02 pm »
Hi Dave

If I unlock and delete helpmgr.dll then during the necessary following reboot I see this message:-

The system cannot find the file HELPMGR specified
in the PROTSHELL statement on line 105 of the CONFIG.SYS file.
Line 105 is ignored.
The system is stopped.  Correct the preceding error and
restart the system.


Line 105 is
   PROTSHELL=M:\OS2\PMSHELL.EXE

Ummm...  not sure how to get around that apart from putting helpmgr.dll back in place.


I have installed the latest NewView, 2.19.5, to eCS2.2b2 and, following a reboot, I can report that the helpmgr.dll file included with the latest NewView causes exactly the same problem - no netop applications will start, all deliver SYS3175.

Replacing helpmgr.dll with the earlier release resolves that problem.


Regards

Pete

Can you do a "exehdr /V helpmgr.dll" on the failing helpmgr.dll and post the results ?

35
I updated both Resource DLLs (the english as well as the german one) but yes that's the version I am talking about:

[d:\mmos2\mmclass\bin]bldlevel mmres_en.dll
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#(c) Chris Wohlgemuth :0.2 (13.03.02) (mmres_en.DLL)#@##1## 13
.03.2002 18:17:00      My ;-)  ::::1::@@Resource-DLL
Vendor:          (c) Chris Wohlgemuth
Revision:        0.02
Date/Time:       13.03.2002 18:17:00
Build Machine:   My ;-)
File Version:    0.2.1
Description:     Resource-DLL

But the problem is the GERMAN Resource: DLL mmres_de.dll.
And the real universal problem is that the OS module loader will barf on the mismatch between file name and internal module name. This is true for ANY DLL loaded. I could easily create a test case that would blow your whole system just by creating (and loading a DLL) that has a mismatch in filename and internal module name.

36
I always had the problem that closing and restarting the Volume applet repeatedly while a video (with sound) was playing in Firefox would eventually blow up the whole system with a subsequent reboot.

I have now found the reason: the CWMM classes (which the volume applet is part of) come with 2 resource DLLs: MMRES_EN.DLL and MMRES_DE.DLL ( in the \MMOS2\MMCLASS\BIN directory).
On my system which has set LANG to de_DE, the volume applet would attempt to load MMRES_DE.DLL, for all others that would be MMRES_EN.DLL.
Apparently, somebody decided to just copy the file MMRES_EN.DLL over to MMRES_DE.DLL as a shortcut to producing the german resources DLL.
However that leads to the following: the file is called MMRES_DE.DLL but the internal module name (set during link time) is MMRES_EN.
The volume applet attempts to load the resource DLL dynamically. It fails because the filename (stem) does not match the internal module name. But what's more: this mismatch between the filename and the internal module name will eventually massively confuse/screw up the module loader (if done repeatedly) until the whole system reboots without showing any trap screen or the like.
My solution was to LXLITE /X (unpack) the DLL, use a hex editor to modify the internal module name from MMRES_EN to MMRES_DE and do an LXLITE to pack it again. Now the proper resource DLL is loaded (even though it still contains english resources ...).
Now my system does not reboot anymore on running the volume applet.

If someone has an AN account I suggest to raise a problem report against this module loader oddity.

37
Programming / Re: OW, JNI (GCC built java 1.6) and parameters
« on: March 29, 2019, 08:27:22 am »
1) catching the exception will work (as you observed). However, you will break the exception handler chaining if you do not place the exception registration record on the stack. That might lead to some odd effects (remember there is a default exception handler that the OS installs in order to catch exceptions in your program).

2) As far as I can tell from your code, the only reason that you need to catch exceptions is so that you can reset the FPU controls flags to turn back off FP exceptions. I am no C++ expert. I see these solutions (from best to worst)
a) have a look at C++ exceptions. I would hope that they allow to catch HW exceptions. But I don't know how you would be able to continue program execution from the point of exception
b) write C macros to set up and remove exception handlers. This is how XWorkplace does it and it works just fine. In the following example, for your case, you will not need to use setjmp/longjmp because you can always continue execution from the point of exception:

typedef struct _EXCEPTIONREGISTRATIONRECORD2
{
    EXCEPTIONREGISTRATIONRECORD reg;
    jmp_buf                                 jmp;
} EXCEPTIONREGISTRATIONRECORD2, *PEXCEPTIONREGISTRATIONRECORD2;

extern ULONG APIENTRY ExceptionHandler(
                                    PEXCEPTIONREPORTRECORD pRep,
                                    PEXCEPTIONREGISTRATIONRECORD2 pReg,
                                    PCONTEXTRECORD pCtx,
                                    PVOID pDispCtx);

#define TRY(except)                                                                     \
{                                                                                              \
    EXCEPTIONREGISTRATIONRECORD2 except={0};                                \
    except.reg.ExceptionHandler = (ERR)ExceptionHandler;                       \
    DosSetExceptionHandler((PEXCEPTIONREGISTRATIONRECORD)&except);   \
    if (setjmp(except.jmp) == 0) {

#define CATCH()                                                                          \
    } else {

#define ENDTRY(except)                                                                     \
    }                                                                                               \
    DosUnsetExceptionHandler((PEXCEPTIONREGISTRATIONRECORD)&except);    \
}

...

ULONG APIENTRY ExceptionHandler(
                                    PEXCEPTIONREPORTRECORD pRep,
                                    PEXCEPTIONREGISTRATIONRECORD2 pReg,
                                    PCONTEXTRECORD pCtx,
                                    PVOID pDispCtx)
{
    if (pRep->fHandlerFlags & (EH_EXIT_UNWIND|EH_UNWINDING|EH_NESTED_CALL))
    {
        return XCPT_CONTINUE_SEARCH;
    }

    switch (pRep->ExceptionNum)
    {
        case XCPT_ACCESS_VIOLATION:
        case XCPT_ILLEGAL_INSTRUCTION:
        case XCPT_PRIVILEGED_INSTRUCTION:
        case XCPT_INVALID_LOCK_SEQUENCE:
        case XCPT_INTEGER_DIVIDE_BY_ZERO:
        case XCPT_INTEGER_OVERFLOW:
        case XCPT_FLOAT_DIVIDE_BY_ZERO:
        case XCPT_FLOAT_OVERFLOW:
        case XCPT_FLOAT_UNDERFLOW:
        case XCPT_FLOAT_INVALID_OPERATION:
        case XCPT_FLOAT_DENORMAL_OPERAND:
        case XCPT_FLOAT_INEXACT_RESULT:
        case XCPT_FLOAT_STACK_CHECK:
            longjmp(pReg->jmp,1);

        default:
            break;
    }
    return XCPT_CONTINUE_SEARCH;
}


c) allocate an exception registration record on the stack and pass the address to your constructor. In the constructor, register the handler and save the address of the exception registration record to a private variable. Then, in the destructor use that address to deregister the exception handler.

Lars

38
Programming / Re: OW, JNI (GCC built java 1.6) and parameters
« on: March 28, 2019, 03:27:04 pm »
Sorry I cannot help with your initial problem but you cannot use DosSetExceptionHandler / DosUnsetExceptionHandler the way you do because the exception registration record ("ex") has to be placed on the stack.
For what you did, it'll go into the heap. You will have to expose this parameter (address) at the constructor so that you can set it in the constructor.

39
Will "UEFI only" systems be the end of Panorama ?
Panorama uses VESA BIOS services. I wonder in how far that will work if you have no conventional BIOS any more.

40
Applications / Re: nguest2.exe (netop) fails to start
« on: March 27, 2019, 09:10:01 am »
ok, I'll take it.
I am beginning to believe that the SMP kernel has at least one massive bug in the memory management (and another one we know already: shared high memory space allocated by DLLs is not freed if the DLLs are unloaded).
Probably introduced when high memory support was added. And the more applications make use of high memory (like Thunderbird and Firefox, to name just the most prominent) the more likely these errors pop up.

Unfortunately, Windows 10 is a lot more stable than OS/2 these days.
Of course, that does not help ...

41
The nail in the coffin for OS/2 will neither be UEFI nor USB 3.
It will be the lack of an internet browser.

42
Applications / Re: nguest2.exe (netop) fails to start
« on: March 26, 2019, 04:06:27 pm »
Have you (accidentally or intentionally) marked the executable (nguest2 or nhost2) to load into high memory ?
If yes, you shouldn't. Never. That will only ever work for DLLs. But in your case, also check what DLLs are loaded by nguest2 / nhost2 and make sure for now that these DO NOT load into high memory. Neither the data segments nor the code segments.

As I said, the EIP of the trap location looks extremely weird. In fact, it makes no sense at all.

43
Applications / Re: nguest2.exe (netop) fails to start
« on: March 25, 2019, 04:51:38 pm »
Yes, it tells us that indeed the trap register display is in line with what Theseus reports for the descriptors in use by DS,ES,SS,CS (you picked the correct ones).
However, as I said, these limit values should NEVER appear.

The only thing I can think of is QSINIT or ArcaOS'es equivalent thereof. With the original QSINIT (that I use under eComStation) I still do not see these weird values.

Have you checked what the eCS installation will tell you when you run Theseus ?

44
Applications / Re: nguest2.exe (netop) fails to start
« on: March 25, 2019, 01:32:29 pm »
There is another issue that is extremely odd:

EDI contains the same address as EIP. Obviously there was a function call via a function pointer (saved in EDI).
But the address of 0xd708e800 looks like complete bogus (it is located outside of the normal private or shared memory regions, even the high memory regions would not cover that address).

Looks like the OS memory management is completely screwed up.

45
Applications / Re: nguest2.exe (netop) fails to start
« on: March 25, 2019, 07:50:50 am »
Then there must be a bug in the ArcaOS kernel. The limit for DS,ES,SS,CS in user mode should NEVER EVER cover the whole possible address space. There always has to be some address space for PCI bus and video aperture and kernel data structures.

The only GDT descriptors that have a limit across the whole address range are the DS and CS flat descriptors used in kernel mode.

As a test you could try the eCS kernel (14.106 SMP) on the ArcaOS installation.

What you could also do is install Theseus and have a look at the GDT. If the limits are plausible, that is, far below 0xFFFFFFFF (don't forget that you need to append FFF to the limit for any GDT selector marked with G=1) then the formatting of the trap screen register contents would be wrong but I doubt that.

Pages: 1 2 [3] 4 5 ... 26