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 ... 76 77 [78] 79 80 ... 89
1156
Hi ivan,

...Now I need to find jpeg.dll, lcms22.dll, cupsim.dll and cupc.dll.  I assume the last two are to help with integration into cups printing but the question is which versions of all those.

Maybe you need to check if you have those DLLs in your libpath.

I find all but one of the DLLs you listed in my \usr\lib path, which is the target DLL path for RPM installer on my system. Only the cupc.dll is missing.

If I remember correctly, the cups-libs RPM package was installed along with the ghostscript RPM package. As well, the ghostscript-fonts RPM was another pre-requisite.

1157
Hi Andi,

...I'm pretty sure printing worked some times ago but now I get the same error message than you. Time to fill an issue I think.

Btw. at least font path may need slash instead back slash.

I tried your settings, no difference. This includes the fwd-slash instead of back-slash.

1158
Utilities / Re: PCL6 Printer driver
« on: March 25, 2017, 10:53:44 pm »
I have IMBPCL5.EXE here...what are you looking for?

1159
I have been using native GSView and Ghostscript for a number of years now. Even though Lucide has come along nicely I still experience pretty regular printing issues with it (see http://trac.netlabs.org/lucide/ticket/342)...so I rely on Ghostveiw/script to always come through with a good hard-copy output.

The current working setup is made up of:

1) GSView 5.0 (2012-01-07 release)
2) Ghostscript 9.04

I installed the current RPM package of Ghostscript, that being 9.18. I then modified the setups in GSView so re-point it to the RPM version of the install.

1) Working setup of GSView
"Ghostscript DLL:"
=> G:\APPS\GENERAL\GSTOOLS\gs9.04\bin\gsdll2.dll

"Ghostscript Include Path: "
=> g:\apps\general\gstools\gs9.04\resource\Init;G:\apps\general\gstools\gs9.04\lib;g:\apps\general\gstools\gs9.04\resource\Font;g:\psfonts;

"Ghostscript Options:"
=> -dNOPLATFONTS -sFONTPATH="g:\psfonts;g:\apps\general\gstools\gs9.04\resource\Font"

2) NEW setups of GSView
"Ghostscript DLL:"
=> G:\usr\lib\gsdll2.dll

"Ghostscript Include Path: "
=> G:\usr\share\ghostscript\9.18\resource\init;G:\usr\share\ghostscript\9.18\lib;G:\usr\share\ghostscript\9.18\iccprofiles;

"Ghostscript Options:"
=> -dNOPLATFONTS -sFONTPATH="g:\psfonts;G:\usr\share\fonts\default\ghostscript;G:\usr\share\fonts\default\type1"

This gave me a working display of the PDF, meaning, GSview has no problems properly rendering the PDF files. The only issue I actually have is the ability to print. Specifically, any attempt to do so produces the following error message:

=== START ===
GPL Ghostscript 9.18 (2015-10-05)
Copyright (C) 2015 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Unknown device: pswrite
  ./base/gsicc_manage.c:1086: gsicc_open_search(): Could not find default_gray.icc
| ./base/gsicc_manage.c:1706: gsicc_set_device_profile(): cannot find device profile
Unrecoverable error: unknownerror in .special_op
Operand stack:
    defaultdevice
Unrecoverable error: undefined in .uninstallpagedevice
Operand stack:
    defaultdevice
gsapi_exit returns 0
DosFreeModule returns 12
=== STOP ===

Because of the message above (...could not find default_gray.icc...) I included the matching directory in the Include Path setup, that being: "G:\usr\share\ghostscript\9.18\iccprofiles;". Still, this has had no impact, the error remains.

So I'm curious how have others proceeded in this migration step? Have you completely un-installed Ghostview? Have you made any other changes?

Thanks as always!

1160
Networking / Re: Samba 4.4.x Netdrive plugin for OS/2
« on: March 25, 2017, 03:42:51 pm »
...& a Samba 4.6.0 client (this one needed more source changes that the above)
smbcln46.dll and smbclient.exe:
http://smedley.id.au/tmp/smbcln46-4.6.0-20170312.zip

ndpsmb.dll based on Samba 4.6.0 is at http://smedley.id.au/tmp/ndpsmb-3.2-samba46-20170313.zip (needs smbcln46.dll from the above)

Feedback appreciated - Samba 4.4 is security fixes only now.

Cheers,

Paul

Took a stab at the move to 4.6 and thrilled to report a SUCCESS!!!

Thanks Paul for continuing this work and huge thanks to Greggory, as I had originally in my update process missed something which resulted in the NDFS not recognizing the updated plugin...reviewing your docs allowed me to proof things out a step at a time!

1161
Applications / Re: RsyncBackup/2 ready for testing !
« on: March 18, 2017, 03:15:19 pm »
Greggory,
Does your RsyncBackup create live backup/copy of a disk/partition (so disk=>disk copy)? Or is it primarily meant to create a ZIP backup?

I ask because I have been using dSync (dSync for OS/2, Version 0.1.6z  (c) 2001-2003 by MaDdEd-Ii) for a number of years now. It runs once every 24 hrs and simply syncs up my partitions...

Thanks,
-Dariusz

1162
Programming / Re: files (and directories) not showing up in WPS
« on: February 10, 2017, 04:31:41 pm »
Doug,

Was this a single filename? Or multiple ones?

The reason why I ask is that I occasionally see this with XWP 1.0.11, but I am literally missing the whole directory listing...in your case, given that EA was the culprit I will review the EAs of all files located in the "missing" directory, maybe that is actually what causes the symptom I am seeing?

1163
Storage / Re: Someone has seen this before os2.ini
« on: February 10, 2017, 04:28:17 pm »
Ivan!

...Who in their right mind uses that size boot partition for OS/2?  It is the boot partition not the dump space for things like HOME and PROGRAMS.

Well, back in the day, one could easily do this...so my OS/2 box, with an original install dating back to (I kid you not) around 1993-4 has been upgraded many many times, moved to at least 3 different hardware platforms and subsequently, as HD space become cheap and plenty, it made little sense to re-do the install to separate out the OS from the APPS.

So yeah, big 64Gig HPFS386 partition here, this the main OS and APPS partition...with bulk of DATA stored in other partitions. I live with sins of the past, today, absolutely agree, I would never merge the two...

1164
Applications / Re: Blue Lion Beta testing...
« on: February 10, 2017, 04:18:22 pm »
...My question was based on the problems a few people have mentioned here about eCS and 6 core AMD processors and the fact that most off the shelf machines come with Intel processors.

An ancient AMD Phenom II X6 here (1100T), but only workable with 5 cores, the 6th one causes the dreaded "Blue Screen of Boot Death"...LOL...mind you, not all the time, but too often altogether, to the point where attempting to boot with one is almost always a miss.

1165
Applications / Re: OpenOffice 4.1.3 Draw problem
« on: February 10, 2017, 02:53:36 pm »
I've got my system set to use VIRTUALADDRESSLIMIT=2560 setting.

Given how many HPFS386 partitions I have defined I found that setting this anywhere higher causes some sort of memory error during boot where the volumes are not "mounted"...yeah, strange error, but pretty specific to my hardware configuration.

1166
Folks,

Brief update on my part. Marcel Müller released an updated version of EXIFTOOL...it now handles the same date/time stamp EXIF content down to HH:MM:SS and creates a '~1, ~2, ~3...' filenames...so this now works very well.

If you are not looking for the option to put that information into your EA then Jhead is a great option. In fact, it gives you way more controls over the final filename formatting.

I exchanged a few emails with Elbert Pol and he ported the 3.0 version of Jhead over. I tested it, the app handled all the filename wildcard processing, so multiple files and formatting very well as well. Elbert was going to release this as a RPM package.

I never got a chance to test Paul's release since Elbert got in touch with me regarding the 3.0 release.

1167
Applications / Re: OpenOffice 4.1.3 Draw problem
« on: January 30, 2017, 04:24:31 pm »
Only one lock-up (hard crash) experience with AOO 4.1.3 Draw...my machine was running for a little over 6 days (24x7, I never shut things down unless I have to)...I just re-started FF38.x (usually about once a day, sometimes less, depending on how much browsing I'm actually doing) because it went down...I then read your post below and went to try it out => HARD..HARD crash...as in no response from anything, re-start switch was the only option!

Keep in mind though, I have my AOO configured to load into HIGHMEM, both the code and data segments...since that crash I reverted to just the code segment. I re-tried this and with FF 38.x up and running Draw behaves as expected...it comes up fine, objects can be created, re-sized, moved, destroyed, no problems.

Do you have the HIGHMEM feature enabled?

1168
It definitely has NOTHING to do with Turbo folders. It happens when Turbo folders is not used.

Agreed...currently i do NOT have TurboFolders enabled. When I discovered this issue in the latest drop of XWP I did enable TurboFolders to try to narrow this down to a particular combination of features, etc, etc...however, this had no effect.

As Doug mentioned, I also have seen this before. Previously though it occured very rarely (for me)...and when it did the WPS pretty much locked-up and CTL-ALT-DEL was the only workable solution.

This time around the WPS continues to work...the system is still very much 'alive'...however, the WPS filesystem folder functionality ceases to function. Subsequently, since one often works with files that means I pretty much have to do a re-boot as soon as this issue crops up. The frequency of occurence is much greater now, it was pretty rare before.

Also, it is worth noting that not only Xview exhibits this, all other views as well. It does not matter what other folder object I open, they all do open, but they are all blank.

1169
Web applications / Re: FF 38.x - problems invoking from within PMMail
« on: January 10, 2017, 03:44:16 pm »
Hi Pete,

...The firefox message url looks wrong. I would expect the url to look like

   file:///G:/APPS//TCPIP/PMMAIL/PMMAIL/TEMP/TEMP.HTM

That could explain why firefox cannot find the file...

Hmm...great point, while the copy of the copy of the error message itself is what I had actually shown in my post, the actual URL that's being issued by PMMail (or at least what FF attempts to load since that is what it shows in the URL bar) is:

file:///G://APPS//TCPIP//PMMAIL//PMMAIL//TEMP//TEMP.HTM

where as what you show (and it does work successfully here when invoked directly in FF):

file:///G:/APPS//TCPIP/PMMAIL/PMMAIL/TEMP/TEMP.HTM

So working through this I find that the only difference is the '//' vs '/' right after the 'G:' drive letter. The remaining directory separators can be either a single or double forward-slash (at least here in my testing either one works fine).

I will log a BUG for the FF team as FF17.x was working fine here (no need, see below info...).

EDIT => there currently exist two open Bugs (but one is a duplicate of the other):

1) Firefox 38.8.0 Beta 7 command line parsing error #176 (https://github.com/bitwiseworks/mozilla-os2/issues/176)
2) Problems with import messages from PM Mail3 #182 (https://github.com/bitwiseworks/mozilla-os2/issues/182)


1170
Web applications / FF 38.x - problems invoking from within PMMail
« on: January 10, 2017, 01:36:25 pm »
I recently moved (full-time) from FF17.x to FF38.x, so far it actually seems to have made my OS/2 machine more stable...I suspect that is partly due to the fact that I had moved to YUM/RPM and little by little have managed to move to the recent versions of DLLs (consistently, across many apps).

Anyways, I am using an older version of PMMail (2.00.1500) and whereas opening up any email in FF 17.x was never a problem, with FF 38.x I now consistently get an error message:

"...Firefox can't find the file at /G://APPS//TCPIP//PMMAIL//PMMAIL//TEMP//TEMP.HTM..."

My PMMail parameters are set as:
1) call FF 38.x => G:\apps\tcpip\firefox\firefox.exe
2) pass it the URL as a parameter => %s

In comparison, if there is a URL listed in the email body itself, highlighting it and openning FF still works fine...

Therefore, this begs the question: has the opening of a file changed with FF 38.x, because the TEMP.HTM file is certainly present in the location passed to FF?

Pages: 1 ... 76 77 [78] 79 80 ... 89