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 ... 37
1
Utilities / Re: Where do I find SciTech Display Doctor?
« on: August 16, 2019, 10:19:45 pm »
I forget if the free reg code is in that release or not, but here is what I have saved:

Code: [Select]
The SciTech SNAP Graphics product is no longer being actively
developed, and at least portions of the source code will be made
available under an open source license.  There will no longer be
any future versions of SNAP Graphics available from SciTech.

If you would like to use the latest SciTech release on your
computer, please use the following free registration code to
unlock the product:

Name: Free OS/2 Code
Code: 9F98-2AB9-9195-CC

Please enter the code exactly as shown above (including case).

2
Applications / Re: AVxCAT 1.5.1.4
« on: August 16, 2019, 02:29:13 pm »
Hello Remy,

New screenshot to update older one :D

Ohh...great reminder, time to upgrade...I was still using the 1.4.x version here.

What is the recommended version of ffmpeg for this release? I find 4.0.0x on Hobbes...that appears to be the latest one.

3
Events / Re: ArcaOS 5.0.4 is out!
« on: August 05, 2019, 09:02:10 pm »
Here, I get,
Code: [Select]
[H:\tmp]yum list firefo*
Installed Packages
firefox.i686                         45.9.0-2.oc00                 @arcanoae-exp

firefox-highmem.i686                 45.9.0-1.oc00                 @netlabs-exp

grrrhhh...LOL, so just when I thought my RPM/YUM was finally working it goes awry!!!

Well, could be just an ID10T error, but it would appear the CLI 'yum list firefo*' produces a different result than my GUI ANPM does.

1) CLI:
Installed Packages
firefox-highmem.pentium4                45.9.0-1.oc00                installed
Available Packages
firefox-highmem.i686                    45.9.0-1.oc00                netlabs-rel

2) ANPM: (by selectively looking at all AVAILABLE packages in the arcanoae-exp repo)
Shows the firefox 45.9.0-2 in arcanoae-exp

Even then the above is somewhat inconsistent within ANPM itself, b/c when using the SEARCH function only the i686 version of firefox/firefox-debuginfo/firefox-highmem 45.9.0-1 come back.

Anyways, that's a different discussion though. One way or another, I am able to see 45.9.0-2, so maybe Andreas or Mike you guys are running into something similar to the above behaviour when searching for the packages?

4
Events / Re: ArcaOS 5.0.4 is out!
« on: August 05, 2019, 05:36:49 am »
Hey Mike!

...So maybe the issue is that the latest 45.9.0-2.oc00 has not been released?

No it's not. Yum List firefo* now show the following - see GRAB1101.jpg...

Oh boy, you are right and I totally missed the fact that the original question/issue was with the firefox core as opposed to firefox-highmem package.

the firefox-highmem is the only firefox package I see, the other one is not showing here either.

5
Events / Re: ArcaOS 5.0.4 is out!
« on: August 04, 2019, 06:04:05 pm »
I think only the testers got authorization (password) back when the repository was setup.

...may have been at some point in time, although doing this check today shows the earlier 45.9.0-1.oc00 release available in their REL repo as well, which means it should be readily accessible by all who have a current and active subscription:

Code: [Select]
[G:\mptn\etc\samba]yum list firefo*
Loaded plugins: changelog, downloadonly, ps, replace, verify
arcanoae-rel         | 1.9 kB  00:00
arcanoae-rel/primary |  13 kB  00:00
local                |  951 B  00:00
netlabs-exp          | 2.9 kB  00:00
netlabs-rel          | 2.9 kB  00:00
Installed Packages
firefox-highmem.pentium4                45.9.0-1.oc00                installed

Available Packages
firefox-highmem.i686                    45.9.0-1.oc00                netlabs-rel

So maybe the issue is that the latest 45.9.0-2.oc00 has not been released?

6
Mail-News / Re: Security fixes for Mozilla
« on: July 21, 2019, 09:05:53 pm »
Hey Dave!

The build process leaves some of the DLLs readonly and a readonly DLL can't be marked.
As I said, the binaries, both Firefox.exe and ffturbo.exe take care of setting BEGINLIBPATH and LIBPATHSTRICT so no worries about DLL conflicts.
I regularly run SM, TB and FF without any scripts or RUN!

Indeed, that was the issue. I am correcting this right now. I know you said this already, but thanks for pointing this out again, never hurts for this type of stuff to be re-iterated!

7
Mail-News / Re: Security fixes for Mozilla
« on: July 21, 2019, 09:03:14 pm »
Always manually unload any turbo's (if loaded), close FF/SM/TB, unlock the specific DLL now (just to be sure), and ATTRIB -R the specific DLL (if read-only)...

...aha!!! I forgot about the read-only flag...indeed sir, there it is.

...Execute the matching ATTRIB +R later, if that's the issue. Probably, according to the OS/2 command HELP [rc_number_of_HIGMMEM], i.e. "HELP 5".

What is neat about this, and I had absolutely no idea after all these years, is that the program RC actualy translates to a system SYSxxx value. Of course that would rely on the code logic to actually pass this to the output w/o it being changes, but I never actually thought to check that, thank you for pointing it out!

André, one last thing though, what DLLs for FF are flagged as high-mem load eligible? No, I do not like a pre-made script doing this type of stuff for me, I do it by hand and that has always worked reliably here. This is mostly due to hold old my install is and how many numerous upgrades it has gone through, etc. etc. etc...

8
Mail-News / Re: Security fixes for Mozilla
« on: July 21, 2019, 06:45:00 pm »
Hi André,

Despite of disk full-error, here each installed member of the non-legacy Mozilla family now has its own copy of those FF/SM/TB DLLs. No RPM, so no RPM to accidently unmark DLLs marked to use memory > 512 MiB. I'm pretty sure moving the DLLs did make sense, and I would be overdoing it when I'd move those DLLs to a LIBPATH directory. And I don't have to delete all duplicate DLLs after each update.

InsTurbo should support both setups, with or without optionally (ab)using BEGINLIBPATH in case you've got several installed copies of DLLs.

Disk space is cheap now, so no problem there. I worry more about the DLL conflicts between the RPM and non-RPM stuff.

Since I do not have multiple versions of the Mozilla products in use, only run FF actually, I do not use the BEGINLIBPATH and simply invoke the program by executing it's EXE.

For now I marked the regular DLLs code-high and updated to the new turbo-07 release. I looked at the script you wrote but do not know REXX enough to understand all the pieces, can you tell me which DLLs do actually mark for load-high?

I see the following reference in Dave's CHANGES file:
25-05-2019 -v0.7 Support loading the NSPR and NSS DLLs high for SUa2 release of Mozilla

...so far now I attempted to mark high the matching files:

Code: [Select]
[G:\apps\tcpip\firefox]dir ns*dll

The volume label in drive G is OS2.
The Volume Serial Number is 45B6:75C3.
Directory of G:\apps\tcpip\firefox

 5-04-19  12:34a    137493           0  nspr4.dll
 5-04-19   2:04a    500726           0  nss3.dll
 5-04-19   2:04a    270578           0  nssckbi.dll
 5-04-19   2:03a     72331           0  nssdbm3.dll
 5-04-19   2:03a     74803           0  nssutil3.dll
        5 file(s)    1055931 bytes used
                 157243400 K bytes free

[G:\apps\tcpip\firefox]highmem -c ns*dll
Error: "nspr4.dll" cannot be opened, rc=5.
Processing module : nss3.dll
Processing module : nssckbi.dll
Processing module : nssdbm3.dll
Processing module : nssutil3.dll

Not sure why nspr4.dll failed, repmod didn't have any effect, I suppose I will try again after a re-boot in case something's still holding it:

Code: [Select]
[G:\apps\tcpip\firefox]repmod nspr4.dll -u
Unlock module 'nspr4.dll'
Locked OS/2 module unlocked successfully

[G:\apps\tcpip\firefox]highmem -c nspr4.dll
Error: "nspr4.dll" cannot be opened, rc=5.

9
Mail-News / Re: Security fixes for Mozilla
« on: July 21, 2019, 02:17:50 pm »
Hi Dave!

https://bitbucket.org/dryeo/mozilla-os2/downloads/firefox-45.9.0.en-US.os2-Pentium-m-SUa2.zip They're packaged as Firefox but have the nightly theme.

Thank you again for keeping up with these things.

Alright, so I replaced the AMD Phenom II version you did for me with this SU2 Pentium-m drop, the CPU usage is visibly more spikey, yet the browser actually appears more responsive after prolonged usage, which is ultimately a good thing as that brings stability.

I do have a question regarding the DLLs you included in your distro, and I'm not talking the standard XUL.DLL stuff, but the remaining DLLs which are also available through the RPM package install, they are:

Code: [Select]
Directory of G:\apps\tcpip\firefox

 5-04-19   2:03a    228225           0  freebl3.dll
 5-04-19  12:34a    137493           0  nspr4.dll
 5-04-19   2:04a    500726           0  nss3.dll
 5-04-19   2:04a    270578           0  nssckbi.dll
 5-04-19   2:03a     72331           0  nssdbm3.dll
 5-04-19   2:03a     74803           0  nssutil3.dll
 5-04-19  12:34a     12300           0  plc4.dll
 5-04-19  12:34a     10733           0  plds4.dll
 5-04-19   2:04a     74081           0  smime3.dll
 5-04-19   2:03a    110309           0  softokn3.dll
 5-04-19   2:04a    117247           0  ssl3.dll

What's the best approach to managing these? And by that I mean: do I replaced the previously installed RPM package DLLs with your versions, or do I leave them in the Firefox install directory, but if I do, will they conflict with any other apps that will of course pull them from the RPM install (that being \usr\lib...)?

In comparison to the Phenom II build, these DLLs were included in that release, so I continued to use the RPM package ones.

10
Applications / ZOC startup error...
« on: June 20, 2019, 03:47:14 am »
It's been a while since I actually had my ZOC 4.15 up and running...to be honest, probably some 4 yrs ago (or longer) when I replaced the battery in my APC UPS and needed to re-set the battery constant.

Well, as it happens here I am again...NEW UPS battery and my APC box is stuck thinking it's still got a bad battery. This is a known issue (SmartUPS 1500) and the fix is to connect through a terminal and issue some commands to re-set the internal UPS microprocessor to a default/NEW battery status.

The alternative is to drain the UPS by discharging with a series of 100W bulbs, which I'm not really crazy about.

OK, so back to ZOC...LOL, starting the darn thing up produces the following in my POPUPLOG.OS2:

Code: [Select]
06-19-2019  21:00:00  SYS2070  PID 0066  TID 0001  Slot 00af
G:\APPS\COMM\ZOC\ZOC.EXE
XFRCEPT->OSYSOS2.os_MuxSemMgr
127

Does anyone have any ideas what this is caused by?

Given how many changes have occured on my system over the years I have no idea what may be impacting ZOC today.

Thanks!

11
Applications / Re: New verssion of VLC
« on: June 09, 2019, 05:55:34 pm »
Are people not using a cmd file to start vlc? Here I use,
Code: [Select]
set BEGINLIBPATH=K:\vlc2\usr\local\lib;%BEGINLIBPATH%
vlc %1 %2 %3
which is located in K:\vlc2\usr\local\bin.

Yup, you bet I am:

Code: [Select]
SET BEGINLIBPATH=G:\apps\multimedia\vlc2\usr\local\lib;%BEGINLIBPATH%
G:\apps\multimedia\vlc2\usr\local\bin\vlc.exe %1

For my part, this became a FF issue...once the browser was down and memory released VLC was OK.

12
Applications / Re: New verssion of VLC
« on: June 09, 2019, 02:47:13 am »
Hmm...yeah, belly-up here as well, all I get is this:

Code: [Select]
06-08-2019  20:28:53  SYS3171  PID 01ba  TID 0001  Slot 00fe
G:\APPS\MULTIMEDIA\VLC2\USR\LOCAL\BIN\VLC.EXE
c0000005
1ffba4ec
P1=00000001  P2=0012f770  P3=XXXXXXXX  P4=XXXXXXXX 
EAX=00150160  EBX=0012f76c  ECX=001502c4  EDX=00000020
ESI=0012f7b0  EDI=0012f838 
DS=0053  DSACC=f0f3  DSLIM=ffffffff 
ES=0053  ESACC=f0f3  ESLIM=ffffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:1ffb9e92  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:0014ffec  SSACC=f0f3  SSLIM=ffffffff
EBP=0015002c  FLG=00010202

DOSCALL1.DLL 0002:0000a4ec

I'll try a re-boot...FF has eaten up a boat-load of memory...so maybe that's not helping?

13
Internet / Re: Kompozer and/or Nvu
« on: June 08, 2019, 02:23:34 pm »
Nvu 1.0 (20050629) still works here, now Kompozer on the other hand is a slightly different story. Initially upon 1st attemp it appeared to try to start up, the main window flashed and it went away afterwards.

As Dave suggested I was guessing there is some sort of incompatibility between it and FF45.x that I'm running. I went to CLI and started the *cmd that my WPS objects points to, which is:

Code: [Select]
SET LIBPATHSTRICT=T
rem the following may only 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

...well, strangely enough that came up fine. So what I seem to have here is KompoZer 0.8b4pre (20100331).

Further on, as I attempted to re-start it again it still flashed and went away...however, re-starting the very next time made it come up just fine. So literally on my machine here, for whatever reason, I have a repeatable cycle of:

1) 1st start - main window flashes and app dies
2) 2nd start - full app comes up
3) 3rd start - back to 1st start behaviour
4) 4th start - back to 2nd start behaviour

LOL...go figure!

14
Networking / Re: Samba 4.9.0 based client
« on: June 05, 2019, 04:52:49 am »
...
LOOK BELOW !!!!!

still cannot believe, please don't wake me up!

I kept trying every variation of settings in smbfs parametres, and now I've found it needed the "workgroup" specification in the Workgroup field, and nousers/nopassword in the login table.
..

Ahh....this is so easy to overlook...sorry I did not catch this earlier. On my network I have mapped all the static IP addresses for each machine to a hostname. The same HOSTS file has been deployed on all the networked PCs, so when I want to access my NAS box I simply point to "NAS" everywhere. This way at least I have a single source of the name to IP address mapping and if things ever change I do not have to chase around all different places to update the stuff.

In parallel to this I re-named my workgroup to "HOME".

Well, congrats...glad to hear you are up and running now!

15
Networking / Re: Samba 4.9.0 based client
« on: May 30, 2019, 03:45:05 am »
...
Logs will help us understand what's happening.

Create a file ndpsmb.dbg in the root directory of the drive where netdrive is installed. Restart ndctl (or reboot).

try and access your windows 10 share - and after, send me a copy of ndpsmb.log (not sure where this will get created on a Warp 4 install).
...

On my machine (Warp 4.52 install) this goes where "SET LOGFILES=" in my CONFIG.SYS points to.

mauro:
Can you post the specific versions of the installed components you have?

I have been almost exclusively using NetDrive to access all of my LAN shares, that's across Linux based NAS box, Win7 and Win10 machines. It is working fine for the most part, there is an annoying problem with the shares just "going away", a NDCTL re-start usually fixes that though...never been able to pin-point what causes that issue though.

Anyways, happy to give you a rundown of what I have here:

Code: [Select]
Samba Client Versions:
File system NDFS32 Version 3.028
Plugin file G:\UTIL\NDFS\NDPLUGS\NDPSMB.DLL]
Plugin Vendor netlabs
Plugin Revision 3.05.0
Plugin Date/Time 3 Jan 2019 15:59:04
Plugin Build Machine ARCAOS-D0C2
Plugin Language Code en
Plugin File Version 3.5
Plugin Description NDPSMB - SMBFS NetDrive External Plugin Build 20180916
Commandline utilities Version 3.0.37-eCS 1.0.6-565
EVFSGUIVersion 2.5.RC7-[2014-11-14]

I picked up this handy dump from the EVFSGUI utility. The NetDrive itself is version 3.1.6.876.

The support packages I have deployed (to specifically give NetDrive the Samba plugin functionality) are:
1) samba-client.i686 - 4.9.5-1.oc00
2) heimdal.i686 - 7.6.0-0.oc00
3) heimdal-libs.i686 - 7.6.0-0.oc00
4) ndpsmb-3_5_0-GA-20190103.wpi (which was a AN test build, maybe a GA by now?)




Pages: [1] 2 3 ... 37