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 - Dariusz Piatkowski

Pages: [1] 2 3 ... 82
Hardware / Dell KB900 keyboard - workable?
« on: March 23, 2023, 02:51:49 am »
Hi Everyone,

Dell sent me an email with a discount code...and well, all my keyboards are still wired, so this one seems like a real nice upgrade.

It is a full keyboard and the comms are done through a Wireless RF2.4GHz & Bluetooth 5.1 setups. The RF link is accomplished through 'Secure Link USB Type-A Receive', which is a little plug that connects to your USB port.

My hope is that this literally just becomes a standard USB keyboard...but...that may be wishful thinking only...LOL, so I'm curious of anyone has tried either this specific keyboard, or keyboards like this with a similar connectivity setup?

Here is the link to the Product Support Page =>


BTW: This keyboard will support pairing up with 2 Bluetooth devices as well, which means this is also a nice way to get comfy typing away in front of a larger tablet, or even a laptop.

Applications / Re: pdf plugin for Lucide missing after Poppler upgrade
« on: March 23, 2023, 02:12:06 am »
Good catch Martin, that was going to be my suggestion: look at the xxx-legacy stuff.

All in all I find Lucide to be pretty spot on with the exception of a couple of things:

1) PSCRIPT print jobs occasinoally trap on my Brother printer, this I can deal with: GSView will handle the print just fine


2) Lucide is extremely slow over the LAN and pulling PDFs from any Samba shares out there...watchin the tcp/ip traffic literally looks like just about all the data that's getting pulled down also seems to go back up to the source...weird...very weird...and only the PDFs do this, no issue with JPEGs, videos, etc!

Anyways, both are another separate topic, sorry to pollute this discussion!

Utilities / Re: HPFS386.IFS
« on: March 07, 2023, 03:32:17 am »
I see you found this to work, and I can certainly confirm that when I was using HPFS386 that was indeed the case.

Applications / Re: GS adding text to pdf's
« on: March 03, 2023, 04:07:40 am »
Well, as it turns out, attempting to use gsos2 from CLI here just causes a bunch of "can't find the font file" error messages...which I suspect is either the result of some wrong font mapping on my system or maybe even a broken gscript install?

I suspect a bad environment variable though because I can normally successfully create PDFs with PDFMergeNX, which itself uses gsos2 but has the following set as the libpath:


Indeed, there are pile of fonts in the \usr\share\fonts\default\ghostscript subdirectories.

Sorry...but no test results here.

Applications / Re: GS adding text to pdf's
« on: March 01, 2023, 03:56:07 am »
Your PDF file shows:

1) Times-Roman as 'Not embedded'
2) NimbusSanL-Bold as 'Embedded subset'

Do you know which font the special characters are coming from?

What is your input file to create this PDF with? If you have it handy I can give it a try here and pipe it through gs9.18 to compare the results...

Hi Andi,

I've used a couple of Brother Postscript printers with my OS/2 setup over the years. Once I had the printer driver adjusted (by importing the PPD) all settings are available.

The models are:

1) OLD - HL1650

The only issue/complaint I have is that with both of these printers, when printing from Lucide (PDF doc) I occasionally get a PScript error at the printer, meaning: instead of a page I get an error page print out of some sort of PScript error.

No problem, I print all my stuff using GSView.

Both of these Brother machines support PCL6 (in emulation), so I supposed one could always try that if the native BR-Script3 does not work.

Applications / Re: ANPM - YUM error. [Errno 256] No more mirrors to try
« on: February 17, 2023, 12:03:11 am »
After updating to ANPM 1.1.0 the app crashes immediately. ANPM.err says:

Line 25 of NLSSetText in yumie.VRM:
+++                           Call VRSet control, property, text;
*** Error 40 Incorrect call to routine
Line 32 of ProgressUpdate in yumie.VRM:
+++                       Call NLSSetText 'DT_PROGRESS1', 'Caption', 190;
Line 25 of ProgressEvent in yumie.VRM:
+++           Call ProgressUpdate data;
Line 51 of Main in yumie.VRM:
+++       Call ProgressEvent;
Line 51 of Main in yumie.VRM:
+++     Interpret _VREEvent;

Anyone an idea?

Turn on the debug logging: use "/DEB" as a parameter, as per the ReadMe:


/NOP  No Progress bar
   Disables display of progress bars.

/DUP  Show Duplicate packages
   Allows the display of duplicate packages (multiple architectures)
   in lists. (Normally, only those packages which most closely match
   the configured platform - i386, i686, pentium4 - or marked "noarch"
   are shown.)

/DEB  Debug
   Include more information in %LOGFILES%\ANPM.LOG (useful for troubleshooting)

Storage / Re: LVM stopped working
« on: February 09, 2023, 06:26:15 pm »

Any chance the LIBPATH stuff got messed up somehow?

What happens if you "cd" to let's say \os2\dll and try to fire it up from there?

lvmgui.cmd is in \os2, and if you start that up it'll look for in your CLASSPATH or directly in \os2\javaapps.

If OS2\DLL would not be correctly in the libpath OS/2 would most not even start up...


Sure...reasonable conclusion on your part, but did I actually say THAT "OS2\DLL" got removed from LIBPATH???

I think not!

Storage / Re: LVM stopped working
« on: February 09, 2023, 06:24:11 pm »

To my fellow posters: if you don't know the answer, please keep your hands off the keyboard! Ill-considered, *untested* answers that send people down deadends are not "helpful"...

Wow man...who messed around with your breakfast cereal today???

Dude, take a "chill pill" if you one on this forum provides feedback with a "guaranteed to work" clause, but for sure these are all intended to be (hopefully) useful suggestions.

What is going on here recently...???

Storage / Re: LVM stopped working
« on: February 09, 2023, 03:02:15 pm »
Any chance the LIBPATH stuff got messed up somehow?

What happens if you "cd" to let's say \os2\dll and try to fire it up from there?

lvmgui.cmd is in \os2, and if you start that up it'll look for in your CLASSPATH or directly in \os2\javaapps.

Hi ivan,

...All my computers have various iterations of the AMD Ryzen processor now which I assemble/build myself.  The top of the range for me is an MSI B550-A PRO board with a Ryzen 3 PRO 4350G.  I also have a couple of ASRock B450 PRO 4 with Ryzen 3 3200G.  All of them drive 1920 x 1200 HDMI monitors.  At the moment I have set the UEFI bios to compatibility mode and everything works well.

Any chance you could run SysBench and post the results?

I've been looking to upgrade the hardware here, and truth be told the only thing that is holding me back is the pleasure of using the two 1920x1200 panels...not going back to a single monitor, not at this time.

Having said that though, with more CPU power I suspect that even a generic video driver (non accelerated SNAP, or simply Panorama) can produce pretty good results. So maybe I can see myself replacing the two monitors with a nice large (curved) display???


Programming / Re: WebSite / HTML editor - what do we have?
« on: February 05, 2023, 04:05:57 pm »
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.


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)

Programming / Re: WebSite / HTML editor - what do we have?
« on: February 04, 2023, 07:25:25 pm »
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...

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.

Programming / Re: WebSite / HTML editor - what do we have?
« on: February 04, 2023, 06:41:21 pm »

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:

Code: [Select]
Killed by SIGSEGV
pid=0x015f ppid=0x001f tid=0x0001 slot=0x010e pri=0x0200 mc=0x0001 ps=0x0010
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):

Code: [Select]

 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



 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 "/"...

Wow...I never knew we had 'conspiracy theorists' and 'against all I'm unfamiliar with' thinkers on our board! the heck have you survived all these years???!!!

LOL, maybe I should have know that though?  :-\ ...but why the "sales pitch" accusations???

Regardless whether JTA is a real person or not, I think the posts provided clearly identified the thought process behind pushing OS/2 into a VM, and how that in turn would remove the 'hardware suitability' from the equation we all try to solve, all in a relatively self-contained package.

Anyways, it is good to have options while the standard blockers are being removed slowly, one piece at a time. 

The browser problem is the one thing, I fear, that has the real "stones" to hurt us badly. Superb efforts are ongoing to extend our viability, but I still struggle with why this hasn't become a prioritized deliverable for our platform - and by that I mean the apparent lack of official backing by the only commercial player in our space, that being AN.

Pages: [1] 2 3 ... 82