OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Dariusz Piatkowski on February 02, 2023, 04:46:28 am
-
...as the title asks: what exactly do we have on our platform?
Dave Yeo ported Kompozer sometime back in 2018 I think...but tonight I just tried it and while it starts up it then completely dies. It is Mozilla based, the full set of DLLs comes with it, and well it looks like it's not quite compatible with our FF 45.9x release because I had apparently tried this before and ended up setting up a CMD that uses "SET LIBPATHSTRICT=T".
Is there anything else I can look at?
I have my VSE here, but that's all HTML code and I'd rather be lazy and do some WYSIWYG instead (I've got a couple of very simple index.html pages to build).
-
Kompozer runs fine here using run!, Perhaps your cmd also needs set BEGINLIBPATH=.\. Also try redirecting output to see any other errors.
There's also SeaMonkey and its composer, which Komposer was based on. Hasn't had many updates in a long time but does what it does well.
-
Dave!
Thanks for the uber quic response to this!
Kompozer runs fine here using run!, Perhaps your cmd also needs set BEGINLIBPATH=.\. Also try redirecting output to see any other errors.
There's also SeaMonkey and its composer, which Komposer was based on. Hasn't had many updates in a long time but does what it does well.
Well, here is what I actually have in my CMD file:
SET LIBPATHSTRICT=T
rem the following may be needed if another Mozilla based app is in LIBPATH
SET BEGINLIBPATH=G:\code\tools\kompozer
REM SET MOZILLA_HOME=<profile_path>
G:\code\tools\kompozer\kompozer.exe
I've rarely utilized BEGINLIBPATH, so how should I use the ".\." that you mentioned in your post Dave?
I will try the runtime re-direct next to see what's actually going on...I suspect I am running into some DLL conflict?
-
As I said, "set BEGINLIBPATH=.\."
SET LIBPATHSTRICT=T
rem the following may be needed if another Mozilla based app is loaded
SET BEGINLIBPATH=.\.
REM SET MOZILLA_HOME=<profile_path>
G:\code\tools\kompozer\kompozer.exe 2>&1 | tee Kompozer.log
Should do it. If it tries to update, stop it. Also make sure the current directory is G:\code\tools\kompozer\
-
Not sure if the StarOffice included 'thing' qualifies for you as HTML editor. But long time ago I build one with it.
Of course today I would try out the Seamonkey included as SM already runs all day long.
-
I do hard coded HTML5 with CSS with a text editor. That's all.
Mike
-
I prefer plain text files and scripts (located in the root directory) that composes HTML pages.
-
The best editors are cloud-based at this point. I'd vote for wix.com. But it does not run on our browser(s).
In a way, it's better to compose on OS/2, because these new editors also create pages that won't work on our Firefox. I need to check dooble builds on that.
-
Hi
FYI. The HTML editors and some other HTML related tools are located here: https://hobbes.nmsu.edu/?path=/pub/os2/apps/webdev (https://hobbes.nmsu.edu/?path=/pub/os2/apps/webdev)
Let me know if I'm missing any.
Regards
-
Dave,
As I said, "set BEGINLIBPATH=.\."
...
Should do it. If it tries to update, stop it. Also make sure the current directory is G:\code\tools\kompozer\
Hmm, interesting. Firing up the app I see it close immedately and get the following in the LOG:
Killed by SIGSEGV
pid=0x015f ppid=0x001f tid=0x0001 slot=0x010e pri=0x0200 mc=0x0001 ps=0x0010
G:\CODE\TOOLS\KOMPOZER\KOMPOZER.EXE
MOZILLA 1:000fd718
cs:eip=004a7a38:00aad718 ss:esp=0000:015423a0 ebp=00000053
ds=0000 es=0000 fs=0006 gs=0000 efl=00d67e40
eax=00aad49c ebx=1ffc9d7c ecx=00aad4b0 edx=00aad4d4 edi=00000000 esi=00aaff7c
Creating G:\TMP\TRP\015F_01.TRP
...and the TRP file itself shows this (just the front end of it for brevity):
______________________________________________________________________
Exception Report - created 2023/02/04 12:08:13
______________________________________________________________________
LIBC: Killed by SIGSEGV
Hostname: NEUROBOX
OS2/eCS Version: 2.45
# of Processors: 6
Physical Memory: 3199 mb
Virt Addr Limit: 2048 mb
Exceptq Version: 7.11.5-shl BETA8 (Jun 1 2020 18:37:02)
______________________________________________________________________
Exception C0000005 - Access Violation
______________________________________________________________________
Process: G:\CODE\TOOLS\KOMPOZER\KOMPOZER.EXE (12/23/2011 09:59:15 6,412,142)
PID: 15F (351)
TID: 01 (1)
Slot: 10E (270)
Priority: 200
Module: LIBCN0
Filename: G:\USR\LIB\LIBCN0.DLL (08/26/2021 09:13:22 1,266,106)
Address: 005B:00D7C9E3 (0000:FFFFFFFF)
Cause: Attempted to write to 03503462
(not a valid address)
Code: failing instruction can not be disassembled
______________________________________________________________________
Registers
______________________________________________________________________
EAX : 00AAD600 EBX : 00AAD718 ECX : 01638F14 EDX : 01522EC4
ESI : 00AAD718 EDI : 004A7A38
ESP : 00AAD604 EBP : 00AAD620 EIP : 00D7C9E3 EFLG : 00010206
CS : 005B CSLIM: FFFFFFFF SS : 0053 SSLIM: FFFFFFFF
EAX : read/write memory on this thread's stack
EBX : read/write memory on this thread's stack
ECX : read/write memory allocated by LIBCN0
EDX : read/write memory allocated by LIBCN0
ESI : read/write memory on this thread's stack
EDI : read/exec memory at 0001:00497A38 in MOZILLA
______________________________________________________________________
Stack Info for Thread 01
______________________________________________________________________
Size Base ESP Max Top
00100000 00AB0000 -> 00AAD604 -> 00AA8000 -> 009B0000
______________________________________________________________________
Call Stack
______________________________________________________________________
EBP Address Module Obj:Offset Nearest Public Symbol
-------- --------- -------- ------------- -----------------------
Trap -> 00D7C9E3 *Unknown*
00AAD620 0052938A MOZILLA 0001:0051938A
....
I've marked tke Kompozer DLLs as loadhigh (code only), tried other options but those resulted in errors as well.
Now the key issue here is that this result is DIFFERENT when FF isn't already running. In that case Kompozer opens up fine, stays running and only tosses an error when I actually close the app.
I'm doing some DLL load tracing to figure out if Kompozer is pulling another DLL that might not exist in it's own directory and may cause a conflict. I found distorm.dll so far that sits in \usr\lib and that I do not recall what it's used for.
"yum provides " returns nothing either...
EDIT => distorm.dll is provided by EXCEPTQ package, I was using our "\" instead of their "/"...
-
You might want raise your VIRTUALADDRESSLIMIT, otherwise no idea unless you have an old libc on your LIBPATH. Looking, I see it was compiled with GCC 3.3.5 and libc063 with no other dependencies and the code predates xul.dll.
distorm.dll is part of exceptq, which is now in libc IIRC.
Edit: Marking the DLL's high might be a mistake as well. I think the code is from before we started using high memory. For the same reason, it will need more low memory then current Firefox.
-
Hi Dariusz,
My copy of Kompozer runs as it always has since I installed it - v0.8b3 and I work on the principle if it isn't broke don't fix it, but then I never chase the latest and greatest and never rub the RPM/YUM updater which might be the answer to your problem.
-
Dave,
All my libcxxx DLLs are sitting in the \usr\lib directory, no dups anywhere else. I did also try setting different load options for LIBC, but none of them resulted in any improvements.
Maybe VIRTUALADDRESSLIMIT is the key, worth a try I suppose...
Ivan,
The issue I'm seeing with Kompozer ONLY happens when FF is already loaded. Since I have Thunderbird deployed as well here, there are some pretty heavy resource demands, so I suspect I'm actually running into some kind of a conflict given that Kompozer is based on the Mozilla framework as well.
-
I use version 0.8b4pre (20100331, Gecko 1.8.1) as well, and the css-editor make it more useful than SeaMonkey.
Switching directly between the source code- and wysiwyg view cause problems, most often add square characters but also disable the save button. But that occur on other os:es such as "blowing in the wind" as well. Switch between the three tabs at a slow pace from left to right, or right to left to overcome some problems.
KompoZer 0.8b4pre produce code compatible with our firefox as both was created from the same generation of the mozilla engine (as in Firefox: Mozilla/5.0 (OS/2; Warp 4.5; rv:45.0) Gecko/20100101 Firefox/45.0). The included css-editor make it quite useful compared to the newer Blue Griffon 1.1.1 from 2011 (the css editor wasn't included by default), but doesn't support new styles introduced with html5. The css editor may therefore remove code you add by hand that it (the mozilla engine) doesn't support, unless you avoid to touch the custom style.
I would have preferred the idea to have the various front ends (such as KompoZer, Firefox, SeaMonkey, Thunderbird etc.) use one (1) common mozilla engine, but other platforms however must have dictated how and what.
-
Hi Dariusz, since everyone else is running it fine and it only fails for you when Firefox is open and you're using LIBPATHSTRICT, it seems the most likely is resource starvation, and memory makes sense.
Hi Jan-Erik, actually Kompozer is quite a bit older then our Firefox, Gecko 1.8.1, somewhere around Firefox 3.6 IIRC. So no where as capable as our Firefox but creates portable websites. The security stuff is likely too aged making it difficult to load HTTPS sites.
I would have preferred the idea to have the various front ends (such as KompoZer, Firefox, SeaMonkey, Thunderbird etc.) use one (1) common mozilla engine, but other platsforms however must have dictated how and what.
At one point that was the plan. Used to be xul-runner.exe which would run Mozilla apps, "xul-runner firefox.ini" or such would start Firefox. Never caught on, never supported SeaMonkey and Mozilla moved away from the idea. It would have still taken compatible Gecko versions, which sm, ff and tb are, but not Kompozer.
Thanks for the hints to work around some deficiencies, I haven't really used it.
-
Dave, everyone...
Hi Dariusz, since everyone else is running it fine and it only fails for you when Firefox is open and you're using LIBPATHSTRICT, it seems the most likely is resource starvation, and memory makes sense.
...
Yup!
Messing around with VIRTUALADDRESSLIMIT (by making it larger) gets me a working Kompozer install here. Granted, this is only a half-win at best because whatever amount I increase that setting by is certainly taking away from the fs cache, and I'm sure not going to give up my giant JFS cache...LOL!
Anyways...I have my answer though.
So I'm curious: is no one else running this with LIBPATHSTRICT setting like I am? :o
Heck, maybe the simplest solution yet - which I haven't actually tried given that the DLLs between Kompozer and our current FF would be so different - would be to drop all the provided DLLs and try to use the FF ones?
OK..another test, here we go... 8)
-
Hi Dariusz, it is not going to work using the recent FF DLL's. If you want to keep your cache, then I guess the only choice is to only run FF or Kompozer.
I'm using run!, which does the same thing as LIBPATHSTRICT. I'll attach it, drop it into your Kompozer program directory. It'll also log stdout/stderr.