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 - Doug Bissett

Pages: 1 ... 59 60 [61] 62
Applications / Re: Whatever happened to...
« on: February 22, 2013, 05:35:54 am »
Hi Doug

OO3 does not work with IFE260 at all here - never gets onscreen. Checking the readme.1st file I found this:-

- Innotek Font Engine is required to run 3.2 for
  eComStation and OS/2. (Available by default in eComStation)
  You can download it from the following location:

That seems to indicate OO3 is built to use IFE 2.40

As you say IFE2.60 is better but can cause more hangs/crashes in my experience - which may be different to yours.

I use iFE 2.40 and have added pmshell.exe to the Applications - as well as deleting all mention of Mozilla apps - and find that the Desktops on 3 systems here all look much better with regard to font display. The only real moan I have is that long folder/application names do not fit on the dropdown menus eg click eCS button (on eComCentre) and here "File and Print Client Resource Browser" has the 's' overwritten by the right arrow head and half the 'e' is missing - as is the final 'r'.

I have also added ar5os2.exe to the IFE 2.40 applications and use ar5os2.exe as the "windows runtime" for OO1.1.5 for Windows. Font display in both OO1.1.5 applications and Acrobat Reader V5.1 is much improved and so far - touch wood (touches head ;-)  - no hangs/crashes.

Using IFE 2.60 with the above applications my system did suffer the odd hang/crash from time to time. I guess that is because 2.60 is a beta version... Would have been nice if it had got past beta before development stopped  :-(



IFE 2.60beta seems to work fine with OO 3.2, but all I have done, so far, is open a file to see if it rendered properly. It did. I don't use it with anything else, and would actually like to remove it completely, but I do use OO 3.2, and it seems to need it. I would like to see OO abandon IFE (any version), and start to use the same font support that the Mozilla derivatives are using. At least the source is available, so problems should be fixable (I don't know if that would actually work either).

Anyway, I will see what happens with OO 3.2, for a while. I don't plan on using it with anything else, since it seems to be unnecessary (at least on my system).

Applications / Re: Whatever happened to...
« on: February 21, 2013, 07:35:51 pm »

As regards font antialias: I suspect the Innotek Font Engine may have a use there. You would need to add Wordpro to the applications supported by the Font Engine in the Registry - see the Font Engine readme file for details.

I don't know about antialias, but some time ago, I tried to remove the Innotek Font Engine completely. Almost everything worked okay, except OpenOffice 3.2. Apparently, OO uses the code, and the Font Engine should NOT be enabled for OO (same as for the newer Mozilla derivatives). I have every application turned off, and would never dream of using it for anything, since it is so flaky, but it seems that it is necessary for some things to run. In fact, that reminds me that I did a new eCS 2.1 install, and forgot that the old 2.4 version of the font engine is still what eCS 2.1 installs. The 2.6 version always worked better for me, but i find that it makes so little difference, that it is just not worth enabling it for other things,

General Discussion / Re: Hybrid "64-Bit" eComStation
« on: February 18, 2013, 07:20:11 pm »
a) Store swapper.dat

I haven't seen any indication that swapper.dat ever gets used, when I have 1.5 GB, or more, installed. It may be possible to get it to be used, but I don't think I have enough programs installed to be able to do that, unless I run more than one virtual machine.

In fact, I have been using RAMFS to create a memory drive for the %TEMP% stuff, when I have more than 2 GB installed. I think that 2 GB would be the minimum to be able to do that, but I have had no indication that it causes a problem.

It might take a bit of fancy programming, but I think that modifying RAMFS to use memory above the (normally) accessible area, might be possible, and it wouldn't involve playing with the kernel.

Hardware / Re: New hardware that works with ECS2.X
« on: February 18, 2013, 07:00:07 pm »
Do a search on the internet before trying it. Years ago I installed my system with it and got sporadic traps. Took me months till I found out it was this driver. After that others told me this driver is known to sporadically trap systems. Maybe it was Eugene so probably there are some traces about

It seems that I don't have much choice. Nothing else (both Multimac versions, Genmac with various win drivers) will do anything more than get the IP address from my router, then the system hangs shortly after trying to use the network. RTGNDA will transfer about 40 GB, before having a problem. The bad part about that is, that when it does have the problem, the NIC won't even work in windows, until I pull the plug for about 20 minutes (apparently, the NIC will stay powered until AC goes away). I suspect that it is overheating, but I can't prove that. Anyway, once I get my stuff transferred to the machine, I won't need such large data transfers. Hopefully, it can be fixed in Multimac, but I will need to report the problem (actually add to an existing problem report). FWIW, I found a Google hit that indicated that Suse Linux has (had?) the same problem as Multimac, but Ubuntu Linux does not.

Hardware / Re: New hardware that works with ECS2.X
« on: February 17, 2013, 07:33:24 pm »
You can try rtgnda ( It may set zero mac to card, so need to uncomment [NETADDRESS] section in nif file and setup address manually... Another thing - it can`t be used as NETBEUI (pure netbios) server... NETBEUI client working fine... Up to 40 mb/s speed.... But it works not on all cards...

AHA! I knew about that one, but hadn't got around to finding it. I found some posts that said it was at HOBBES, but it isn't there. I got it at:

It needs the NETADDRESS thing, AND, it needs IRQ15OVR=YES when using ACPI.PSD with high IRQs.. It looks like I am in business.

Currently, I am doing a copy, using SAMBA, and it seems to be going as fast as any other link that I have. At least it isn't hanging the system.


Hardware / Re: New hardware that works with ECS2.X
« on: February 16, 2013, 05:23:05 am »
Realtek gigabit cards work very reliable,

If that was only true.

I have an Asus M3A78-EM motherboard (a few years old now, but still not bad). It has a Realtek 8168 chip on it. It died (even in windows). I tried an Intel PCI-e card, but whatever killed the 8168 also killed the PCI-e slot. I then got a PCI card, with a realtek 8169 on it. That works pretty good, with the Multimac driver, but it is significantly slower than another system with an Intel NIC, and the Multimac driver. It is even slower than my old Asus A8N-SLI system, with the NVIDIA Multimac driver.

Now, I just got a new lenovo ThinkPad L530. It also has a realtek 8168 chip (there was no indication of what NIC it had in it, when I ordered it - I did make sure I got an Intel WiFi adapter, which I haven't had any luck with either). I tried the Multimac driver (8169). It works, for about 2 minutes, then it hangs the system. I also tried the older 8168 Multimac driver. That killed it instantly, and it wouldn't even work in windows, until the next morning (whew!). Of course, this one works perfectly in windows, so I tried GENMAC. So far, no joy.

Setup & Installation / Re: eCS 2.2 YUM/RPM question
« on: February 01, 2013, 03:23:02 am »
That reads like it is already implemented in the installer. Do you have access to the sources? Or are you even the developer responsible for the installer?

I have no idea what will be in the eCS installer. No, I don't have access to the sources, and I am not responsible for it.

I DO have RPM/YUM installed on a drive that is not the boot drive, as installed by the existing installer (with no magic), and I see no reason for that to change (but stranger things have happened).

At the moment, I do not have a second boot system on that machine, so I cannot comment on what will happen if I try to share the RPM/YUM installation between two boot systems.

Doug, please do the things that you know to do. I would thank you if you turn your mind and let Alex and Joachim speak in that case. An option would be to use citations, marked as such.

I think you should actually READ what I post.

Setup & Installation / Re: eCS 2.2 YUM/RPM question
« on: January 31, 2013, 09:45:59 pm »
So far with RPM/YUM there has been no definitive answer to how it is designed to work.  So far the answer is 'maybe' it will go on a non boot partition or 'maybe' it has to be on the boot partition.

There is no doubt that RPM/YUM can be on a volume, other than the boot volume. IMO, it should NOT be on a boot volume, but it CAN be. Whether the eCS installer will actually allow it to be put on a volume, other than the boot volume, is yet to be seen (if it doesn't allow it, it won't get installed until AFTER the main install, if I install it at all - which is unlikely, except on my test machine).

The only unknown is whether two boot systems can share the information, successfully. If it is done properly, there should be no problem. If it isn't done properly, it could be somewhat interesting, to say the least.

Setup & Installation / Re: eCS 2.2 YUM/RPM question
« on: January 31, 2013, 07:01:44 am »
I already have rpm/yum on an alternate drive. When the new eCS comes out and I would install it on a second boot partition with rpm/yum in the same place as it is now I expect there might be problems because files would get overwritten and the database will get messed up. So I intend -not- to install rpm/yum but simply copy and paste the appropriate lines from the old config.sys to the new one.
And that appears to be the big problem - multiple OS/2 eCS boot partitions on the same machine using common applications installed on a partition that can be used by all boot versions.

It has been NO PROBLEM, for me, but I haven't tried it with RPM/YUM. I share almost everything, on a common drive, between boot partitions. Some of them are (in no particular order):
OpenOffice 3.2
Electronic Teller
Lotus Smartsuite
PMView Pro
Photo>Graphics Pro
GenealogyJ (JAVA)
APC UPS monitor
and  few more that I don't use much.

Basically, most programs can be shared between boot systems, with no trouble. Doing it that way makes it a LOT easier when the time comes to install a new version of eCS. Generally, you do need to re-install the program, over top of the old, using the new boot system. Sometimes, simply creating icons is enough. WarpIN makes it very easy to just run through your collection of installers, to get it done. The best programs store all of there configuration stuff in their own directory, so it can be used by any boot system. Not too far behind, are those that store config stuff in the %HOME% directory (which also needs to be on the common drive), although I find that that gets badly cluttered. The worst programs, are those that insist on storing configuration stuff on the boot drive, especially when they put it in the system INI files. Even that is not a real problem, it just means that you need to be more careful when installing the programs.

I suspect that RPM/YUM will keep all of the configuration stuff in it's own directory structure, but I am not sure how easy it will be to synchronize it between two boot systems.

Setup & Installation / Re: eCS 2.2 YUM/RPM question
« on: January 30, 2013, 06:20:39 pm »
If I want to install it on another Drive this drive has to be already created and formatted before the "real" installation starts, otherwise I will not be able to install ODIN and so on...

True, but that is very easy to do. In most cases, on a re-install, the alternate drive will already be set up, and formatted. If it is s new install, and the drive isn't already set up, you can do that when you set up the drive during install. Create all of the volumes, then the install drive is formatted. At that time, there is the option to format the rest of your drives (JFS, HPFS, etc. Not FAT32 or NTFS). Once they are formatted, you are free to use them.

Personally, I take the opportunity to select the alternate drive to contain the %HOME% and %PROGRAMS% directories too. Hopefully, the updated installer will also allow a user to specify the %UNIXROOT% directory at the same time, even if a user chooses not to use RPM/YUM. If that is done, and %UNIXROOT% is placed on an alternate drive, a user should be able to install RPM/YUM some time in the future, without messing up too many things. One of the reasons that I do that, is that I can share those directories between multiple boot drives. I am not sure what implications that would have with RPM/YUM (could be a horror show, if they don't do things properly), but everything else that I have tried works fine.

Applications / Re: Qpdf
« on: January 27, 2013, 01:45:19 am »
It looks like the FIRST time I open QPDFView, it puts entries into %HOME%, as I expect ("adds" entries would be more accurate). The second time I open it, it puts the same entries into the root of my boot drive. My boot drive is M:, and QPDFView is in W:\APPS\QPDFVIEW. The PDF file is in W:\DOWNLOAD. The working directory, in the program icon, is set to W:\APPS\QPDFVIEW. CUPS is on M:.

I will say that when it works, QPDFView is pretty good, although I do have a discrepancy about what the real Acrobat Reader , in windows, does, and what QPDFView does, when editing fields in a PDF file. I need to figure that out, and report it somewhere.

Applications / Re: Qpdf
« on: January 26, 2013, 12:10:34 am »
I found another problem with QPDFView. It has put two directories in the root of my boot drive: .config and .local. Normally, those things follow the %HOME% environment variable, which certainly does not point to the root of my boot drive.

Applications / Re: Qpdf
« on: January 25, 2013, 10:45:53 pm »
which cups do you have? you need very latest cups.dll from Paul, as older ones did not work with Qt Apps.

I thought I had the latest, but apparently the latest is only available in the ZIP file download.

11-03-12 10:41p       913,935    124 a---  cups.dll

(MM-DD-YY). So, now I can print ONCE, after a boot. I can use other apps to print through CUPS, but QPDFView only prints once, then it complains that is could not print. On the down side, if I print using CUPS (ANY program), I end up with one (of 4) of my CPUs stuck at 99.9%, for about 10 minutes, after the print is finished. Then, that stops. While it is stuck, I have a LOT of trouble doing other things. After it stops, everything seems to be normal again. I can find no indication of what is hogging CPU time. TOP doesn't show it, only the Pulse widget shows it.

Applications / Re: Qpdf
« on: January 25, 2013, 12:21:00 am »
cups.dll is used to support printing as it provides the cient side api's to talk to a cups server.

Hmmm. That might explain some of the odd occurrences that I see when trying to print using CUPS. I have this:
 6-10-12  6:57p       920,419    124 a---  cups.dll
        1 file(s)     920,419 bytes used

Directory of M:\cups\sbin

 8-31-11  6:19p       869,291      0 a---  cups.dll
        1 file(s)     869,291 bytes used

Which one is right? Neither one of them is in LibPath. Perhaps that explains why I can't print from QPDFView. AHA!, yes it does. I tried BeginLibPath to M:\cups\lib and it no longer hangs. It still doesn't print. It pops up a message box that says "Could not print <the file name>". Not extremely helpful, but better than a hang. Now, to try more things...

Applications / Re: Qpdf
« on: January 24, 2013, 09:28:39 pm »
If I try to open a pdf from another directory than that where qpdfview is installed it complains about popqt44.dll not found. So it seems to me that qpdfview doesn't look in it's own directory for its dlls. Is that correct and does it have to be placed in the path or at least do the dlls have to be moved to a directory in the path?

Two things should help. One is that the Working Directory (in the program icon properties) should be the directory where QPDFView is installed. The other is that you should have ".;" (dot semi-colon, without the quotes) in the LibPath statement, in CONFIG.SYS. That is usually close to the beginning of that line. Having the dot entry tells the system to look in the current path (the Working directory) for DLLs. Of course, if you try to use QPDFView from the command line, you need to put the install directory in LibPath, or put the DLLs in a directory that is in the LibPath.

Pages: 1 ... 59 60 [61] 62