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 - rudi

Pages: [1] 2 3 ... 8
Hardware / Re: Raspberry Pi and eCS?
« on: 2012.06.25, 08:31:45 »
I have a RPI

Interresting. I guess I will be able to order mine later this week. But they estimate 14 weeks for delivery :-\  However, I already ordered a CuBox, which is a bit more powerful and will arrive here sooner. I'm aware that there are still a lot of software problems with that one, but that is just part of the fun... Can't wait to start playing with this little toy ;D

Hardware / Re: Raspberry Pi and eCS?
« on: 2012.05.30, 14:21:59 »
Could eComStation run on it?

He's joking, Isnt' he ? BTW, I recently ordered a similar piece of hardware. While waiting for the delivery I start to make myself familiar with Linux. After all these years with OS/2 I guess it's time for me to try something different and this type of stuff looks quite exciting...

Utilities / Re: Change cCS blob at bootup
« on: 2012.05.24, 08:29:36 »
eCS comes with BrandLDR.

ISTR that not only the text, but also an attribute for each character is stored within OS2LDR. Thus it is possible to also change the fore- and background color of the message. Does BrandLDR support this as well ?

Hardware / Re: TRAP d Intel DH55PJ
« on: 2012.04.04, 08:38:30 »
it has two EHCI adapters, and no others. USB 1.0, and 1.1, work fine when using only the USBEHCD.SYS  driver (two of them).

The USB specs allow a "2.0-only" configuration in case there is an integrated hub that can handle 1.x devices. Some Intel hardware is known to do exactly this. However, the crappy OS/2 USB drivers did not work correctly in this scenario. Lars has implemented some fixes. So using his driver (from Hobbes) will increase the chances for getting this to work...

Hardware / Re: SNAP GAMODE on VirtualBox and 1366x768
« on: 2012.03.26, 15:37:11 »
Oops, obviously I didn't read your initial posting carefully enough... Anyway, yes, I'd think that the
resolution should show up. But I cannot tell for sure, I'm using the display driver from the OS/2
guest additions and I enabled "1440x900x32" as described.

Hardware / Re: SNAP GAMODE on VirtualBox and 1366x768
« on: 2012.03.26, 07:52:24 »

My goal is to obtain a 1366x768 resolution on the eCS 2.1 VM.

ISTR, that you have to add the required resolution to VirtualBox before you can use it
in an OS/2 guest. On the host run:

vboxmanage setextradata "Your VM name" "CustomVideoMode1" "1366x768x32"

Then try again to set the resolution in SNAP (or whatever video driver you use).

Windows running as a guest can use that 1366x768 resolution without issues.

This is a different story. AFAIK, the guest additions for Window dynamically resize the
guest's desktop whenever you change the window size. Something not possible with

Hardware / Re: eCS v2.1 and OS2AHCI.ADD where?
« on: 2012.02.24, 09:09:29 »
I understand that in AHCI mode the disc data transfers are much higher than in SATA compatibility mode.

I'd say that is a modern myth. AFAIK, AHCI really has an advantage when you have multiple disks. This is because the data channels on AHCI operate completey independend i.e. without master/slave devices sharing the same controller hardware. So it's ideal for RAID setups, which we usually don't have in OS/2.

Applications / Re: odin 0.8.3
« on: 2012.02.24, 08:58:13 »
Thanks for the information about the libc064.dll file.  The new file should be placed in the ecs\dll subdirectory, I assume.  Is that correct?  What about having both the libc063.dll and the libc064.dll file in the same ecs\dll subidrectory?  Or will odin just ignore the libc063.dll file?  Thanks again for all your help and information.

The concept of the libc versioning is that an officially released higher number package (064) will contain all (officially released) lower numbered DLLs (063, 062, 061, 06). However, these lower numbered DLLs are only forwarders to the main (higher number) DLL. Thus, if you install 064 in the way it is intended, applications linked against earlier versions of libc (063, 062, 061, 06) will effectively use 064. In some situations (plugin based software with modules from different different vendors) it even is essential, that only a single version of libc is used.

The devices I'm testing definitely have the string present for at least some of the fields - lspci on linux confirms that.
At first I thought the problem was related to libusb/usbcalls however the device report from usbresmg.sys also shows the string error

I've seen that before. I seem to remember, that it happened on some devices, that were already claimed/initialized by other drivers (USBKBD, USBMOUSE). Could it be that you have USBPRT loaded and that this driver feels responsible for your printer ? Or is the printer in reality a multifunction device that is partially handled by existing device drivers ?

Networking / Re: JetDirect/Port 9100 support
« on: 2011.12.24, 09:56:35 »
then you will have to use CUPS..

Or try this:

Hardware / Re: Graphics card
« on: 2011.12.23, 08:38:22 »
It maybe my system or setup, but vlc, mplayer, kplayer all skip

It's not your setup. All these apps do a very poor job with respect to this. I don't know, if it is related to their general design or the OS/2 output modules. Somehow I have the feeling it's related to the latter...

And I would have to disagree with you on the comparison between SNAP & WO

The only difference between the two is the set of supported hardware. WO supports a somewhat greater variety (ATI, Matrox, nVidia, 3dfx) but only for now really antique card models. SNAP overlay can be used with a little bit less ancient card models by ATI, Intel and partially S3. Some ATI cards can be used with both WO and SNAP overlay.

BTW, SNAP overlay fails here on Intel graphics when the resolution is larger than about 1680 x 1050. Anyone else seeing this ?

Article Discussions / Re: SMplayer version 0.6.9 beta 3
« on: 2011.12.10, 12:10:03 »
  I tried Michael's suggestion of C:\\...\\...

Qt 4.7.x (not only on OS/2) has some changes with respect to the handling of INI files. Especially, the use of single backslashes is deprecated and may yield unexpected results. Forward slashes or  - as mentioned above - double backslashes should be fine.

Setup & Installation / Re: RPM packager
« on: 2011.11.01, 08:12:44 »
RPM/YUM and other ported tools aren't free and you pay it under eCS licence and if the developpers would realy work for free like I do, I think that eCs could be sold at a lower price and many more people could buy it !

Netlabs developpers do not work "gratis".

I think you have a completely wrong idea about what Netlabs is. Primary, it's a site that host projects. Most of them have nothing to do with Mensys. There are three kinds of projects: Private, sponsored and free. Private projects are those, for which a company (like Mensys) pays for. That is for example ACPI and USB. The source code for those is usually not publically available. Then there are sponsored projects. These include Qt and Java. Projects of that kind are considered to be too large/complex to be handled by programmers in their spare time. Thus at least the lead programmer (like Dmik, who BTW is one of the most capable programmers I know) is payed to dedicate a specific amount of time to the project. Individuals as well as companies (like Mensys) are free to sponsor something they consider as useful or important. But that doesn't usually mean that they decide the direction in which the project will progress. AFAIK, Mensys has not indicated any interest in RPM/YUM. So this falls in the 3rd category: it's a free project and nobody is paying for it "under eCS licence".

Also note, that there are actually people (like myself) who from time to time contribute to sponsored or even private projects. Gratis.

Article Discussions / Re: Qt version 4.7.3
« on: 2011.10.13, 09:11:23 »
The old didn't have the path in Path and Libpath but had it listed in qtsys.conf in MPTN\etc.

%ETC%/qtsys.conf is no longer used. It was an OS/2 specific invention that - AFAIK - is valid only in 4.6.x version. Here is, how it works now:

The file qt.conf is searched in the specified order in following locations:

1.) in the (Qt-) resource data of the executable
2.) in the current directory
3.) in the directory where QtCore4.dll was loaded from

Then the "prefix" value from qt.conf is appended to the directory where qt.conf was found. This becomes the base directory for all the other stuff like "plugins", "translations", "imports", etc. Note that the names for these subdirs can be overridden - even with absolute paths - in qt.conf as well.

In case no qt.conf could be found, the directory where QtCore4.dll was loaded from will become the base and the subdirs will be assumed to use their default names.

The standard setup uses a directory structure like this:


The Qt DLLs reside in %QTDIR%/bin. Thus qt.conf located in the same directory and found by rule 3.) must contain ".." as prefix value.

As I said rudi it was an extra dot in the path statement in the conf file for the new Qt4 version, a conf file I took as being correct but it wasn't for our situation.

So I assume you have changed the directory structure without knowing the implications. This is exactly the type of problems that this new RPM/YUM/FHS stuff is supposed to avoid. Not sure if it does...

Pages: [1] 2 3 ... 8