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 ... 60 61 [62] 63 64 ... 85
916
Applications / Re: Converting .BOO to PDF ?
« on: April 08, 2019, 09:55:42 am »
Hallo Martin,
Just to lessen your expectations:

the IBM library reader does NOT allow to print the whole document (via a converter to PDF, for example).
For copyright reasons the reader will only print MARKED text. I don't think that is what you want ...

917
Applications / Re: OS/4 (technical details only)
« on: April 08, 2019, 09:40:14 am »
You should have read the OS/4 kernel readme. It clearly states that in order to use OS4APIC.PSD with the /APIC switch you have to also use ACPI4.BPD. The only alternative to this set up is a patched ACPI.PSD as a replacement for OS4APIC.PSD+ACPI4.BPD (which will never happen as the OS/4 guys need to patch each and every new version of ACPI.PSD in order to make it work with the OS/4 kernel).

In short: if you don't have ACPI4.BPD then you cannot specify the /APIC switch. But if you have working MPS 1.4 tables then you also do not necessarily need ACPI support. One drawback will be that you cannot power off via ACPI (obviously) if you don't have ACPI support.

918
Programming / Re: OW, JNI (GCC built java 1.6) and parameters
« on: April 07, 2019, 08:46:44 pm »
class LoadLib {
...

public:
    EXCEPTIONREGISTRATIONRECORD *pex;
...
    LoadLib( EXCEPTIONREGISTRATIONRECORD *prec, PSZ pszLibrName = "", PSZ pszLibrPath = ".", bool fpe = true) {
    pex = prec;
    memset(pex,0,sizeof(*pex));
    ...
    pex->ExceptionHandler = ( ERR )fpeHandler;
    DosSetExceptionHandler( pex);
    ...

    ~LoadLib() {
         if (pex->ExceptionHandler)
              DosUnsetExceptionHandler(pex);
     ....


call:

JNIEnv* create_vm(EXCEPTIONREGISTRATIONRECORD *pex) {
    javm = new LoadLib( pex,"client\\jvm" );//, ".", false ); //when used with sqlite3 and cairo
    ...


int main( int argc, char **argv ) {
    EXCEPTIONREGISTRATIONRECORD ex;
    JNIEnv* env = create_vm(&ex);
    ...
    delete javm; <---- your forgot this one ...
    return 0;
}


Just one thing to note: be aware that an exception handler can only be registered for the CURRENT stack frame (and everything called directly or indirectly from this point).
That is, you need to do "delete javm" BEFORE you return from the function where you called "new LoadLibrary". That also means you cannot pass around the LoadLibrary object and then return from the function registering it.

Also be aware that you need to set exception handlers PER THREAD. You cannot do a "new LoadLibrary" and then expect the exception handler to work from another thread (but see above, it's forbidden to pass around the object anyways).



       

919
Applications / Re: Converting .BOO to PDF ?
« on: April 06, 2019, 02:42:05 pm »
The link I gave contains everything: the DOS version, the Windows version and the OS/2 version.
The files you need (for english) are ios2pen1.exe and ios2pen2.exe.

920
Applications / Re: OS/4 (technical details only)
« on: April 06, 2019, 02:06:09 pm »
That still does not answer the question why ACPI4.BPD is not bundled with the OS4 kernel package. The kernel package only contains OS4APIC.PSD but not the BPD.
And by now, ACPI4.BPD cannot be found on the OS4 web page any more.
I do have ACPI4.BPD but I don't even remember where I got it from ...

922
Ok, after having had a private exchange I take it for granted that this problem is fixed in the OS/4 kernel but not in the IBM or AN kernels.

923
Applications / Re: OS/4 (technical details only)
« on: April 04, 2019, 11:58:17 am »
For what it is worth:
if you ask the OS/4 guys, they are going to provide you with an ACPI4.BPD driver plus the OS4APIC.PSD driver that goes along with it. This combination is a full replacement for ACPI.PSD as provided by AN.
The "BPD" driver variant is an OS4 extension to the driver model (they are special, will load without being listed in CONFIG.SYS and load early in the boot process).

However, the ACPI4.BPD driver is beta.

924
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 ?

925
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)

926
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.

927
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 ?

928
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.

929
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.

930
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

Pages: 1 ... 60 61 [62] 63 64 ... 85