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 ... 61 62 [63] 64 65 ... 85
931
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.

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

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

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

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

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

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

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

939
Applications / Re: nguest2.exe (netop) fails to start
« on: March 24, 2019, 07:27:41 pm »
One thing that looks really odd is that the CS,DS,ES,SS limits are 0xFFFFFFFF.
Can you crosscheck the values for VIRTUALADDRESSLIMIT that you have set for your ArcaOS and eCS installations ?
You might need to lower these values from say 3072 to 2048 or so.
I have set it to 2048 which results in a limit of 0x7FFFFFFF. If you set it to 3072 that should result in a limit of 0xBFFFFFFF and I think that is the maximum allowed value.

940
Applications / Re: mozturbo
« on: March 24, 2019, 07:10:58 pm »
I looked at the tbturbo/ffturbo code: it lists "mozalloc.dll" as a file to preload. But I cannot find that file, neither in my firefox nor in my Thunderbird directory.
I remember that it showed up there in the past but no longer (maybe I deleted it as I identified it as superfluous).
Maybe that file should be removed from the list of files to load.
Neil, if you still find this file in your FF or TB directories, try to remove it or rename it and see if that helps.

941
Applications / Re: OS/4 (technical details only)
« on: March 11, 2019, 10:15:02 pm »
No. The FIRST variable in a section is aligned. But not necessarily the ones that follow.

942
Applications / Re: OS/4 (technical details only)
« on: March 11, 2019, 03:40:58 pm »
Only the FIRST variable in the section is aligned to the desired alignment.The others need to be aligned manually.

Lars,

ff_cos_32  defined in C,  what is defined in asm  right now is aligned ok

Really ? I could see various variables that were only aligned to 16 bytes (typically it was a sequence of 4 * 4 bytes). If these are only accessed by SSE code then everything is fine but if you pass these to AVX code then you will experience a trap.

943
Applications / Re: OS/4 (technical details only)
« on: March 11, 2019, 07:36:10 am »
Only the FIRST variable in the section is aligned to the desired alignment.The others need to be aligned manually.

944
Applications / Re: OS/4 (technical details only)
« on: March 10, 2019, 10:09:32 am »
You Need to define all segments as public. Only then will they combine.

They are declared as public. The weird thing is the various types of text segments. From the map file,
Code: [Select]
Segment                Class          Group          Address         Size
=======                =====          =====          =======         ====

TEXT32                 CODE           CGROUP         0001:00000000   009fe590
________TEXT           CODE           CGROUP         0001:009fe590   00000000
text                   CODE           AUTO           0002:00000000   000ca2cb
DATA32                 DATA           DGROUP         0003:00000000   0001d990

Aout gives,
Code: [Select]
TEXT32                 CODE           CGROUP         0001:00000000   00bd1560
________TEXT           CODE           CGROUP         0001:00bd1560   00000000
DATA32                 DATA           DGROUP         0002:00000000   00015a20

Note that the DGROUP ends up in segment 0003.
The other question is, does it matter?

It does not seem to matter. At least the AVCODE65 that I use has only 2 segments: a CODE segment and a DATA segment.
You can check with THESEUS: System->Modules->AVCODE65->double click one MTE @
The AVCODE65 that I used was installed via RPM from the Netlabs repo.

But you can also enforce that differents segments go into the same group:
CGROUP GROUP ________TEXT,TEXT32,text
put that in an assembler file that is linked, preferably the one for the first obejct file to be linked.
You might get warnings like the one you posted but if it is the FIRST object file to be linked it will take precedence over everything that follows :-)

By the way: I very much doubt that our OS/2 tools can do anything else but the OMF and the AOUT format. I used nasm without the -f switch and that worked right out of the box. Which means that in this case it produces OMF format.

945
Applications / Re: OS/4 (technical details only)
« on: March 09, 2019, 10:59:46 pm »
Same error.
Anyways there are bigger problems, still using 64kb segments, lots of missing symbols for some reason, perhaps lost when the code is bigger then the segment, inconsistent underline prefix (I just hacked the code to fix for us, changing an ifdef to ifndef). Too many segments.
Here's a map file.
You Need to define all segments as public. Only then will they combine.

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