• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu
Menu

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.

Show posts Menu

Messages - djcaetano

#1
I am looking for Windows version of OpenChat IRC Client for years now. I once had it, but I lost it and was never able to find it again. Too bad. OpenChat is the best IRC client ever. :)
#2
Programming / Arduino UNO on eComStation
2012.06.29, 05:51:12

  Hi there!

  I have just bought an Arduino UNO board and started playing with it under Windows. For those that doesn´t know, it is an "open-source electronics prototyping platform". Not only that, it is *very* easy to use: http://www.arduino.cc/
  The board is connected to the PC by USB port and the driver shows it as an COM port. The software is open source and is part Java based, part native C (source available: http://arduino.cc/en/Main/Software ) and is available for MacOS X, Windows and Linux (both 32 and 64bit). Linux version seems to be just Java and some JNI .so to allow COM access. The software is a simple C compiler (GCC based, I believe) which is able to upload the program to Arduino board.

  I was wondering if this kind of board will ever be usable under eComStation... :)

  Regards,

  DJC
#3
I used Adept BBS for a long time... today I was trying to set it up again and I discovered SIO.SYS (1.6d, my only 16 port registered version) hangs solid while eComStation is booting (latest ACPI), it doesn't matter if I am using APIC or PIC mode. I've tried SIO2K shareware and it works, but only allows a small number of virtual modem ports. Anyone knows if I can overcome this limitation, since SIO2K is now "abandonware" and registration is not possible? even for more virtual modem ports (I just changed it to 8 and it works).
I've never registered SIO2K because it refused to work in my previous machine. Damn! :( It would be nice to register it though.
Regards,

Daniel Caetano
#4
Quote from: ydario on 2012.02.27, 18:41:43
really weird, OOo installation does not depend on drive, I'm pretty sure ;-)
Which path did you use on  on D: ? file system?

  Hi Yuri,

  Path was: D:\PROGRAMS\OO

  Regards!
#5
Quote from: aschn on 2012.01.31, 22:45:16
I don't understand the excitement about YUM, RPM or WarpIN or not using them. If it works, we should be happy -- if not, just feed the bugtracker. I don't see any chance to avoid any of them.
My opinion: I see the reasons why porters of ix software switch to a system that eases the dist part. We (I'm more a user then a contributor/developer) should be happy if there's anything new available in these years at all. BTW: RPM/YUM works well for me. I can imagine how much work developers will save themselves by having made that change (from WarpIN or anything else to RPM/YUM).

  Indeed, I do share your point of view. :)
#6
Quote from: Pete on 2012.01.31, 19:55:18
I seem to recall from a previous yum/rpm discussion on this site that ported software will continue to be offered in zip packages as well as yum/rpm - and that seems to be the case so far. I also seem to recall there was talk of repacking into Warpin packages as well.

   ZIP yes. But I do not like to mess with ZIP files, unless really needed. :)
  About WarpIn, unfortunately it will depend on third parts (besides the developers).

Quote from: Pete on 2012.01.31, 19:55:18
As long as that happens then I will continue to use either zip/Warpin packages.
If porters decide to stop supplying zip/Warpin packages then I will have to rethink my choice of operating system.

  I was thinking that way. But I believe I was overreacting. WarpIn is a way better solution for the end-user, but I ported some software back in the day... and tried to port a lot of different ones. What I know is:

   a) It is *a lot* of work...!
   b) It is almost impossible to get the source maintainer to include our modifications (or hacks) to make it work on OS/2 (which generates a lot of double work each time a new version comes out).

Quote from: Pete on 2012.01.31, 19:55:18
I'm not sure what you are referring to when you say "I also hate the need to add dozens of paths to LIBPATH" but maybe we just use different software...
I don't think that I currently have any software that includes specific gcc/libc packages - certainly lots that requires gcc/libc packages and they all seem to be working fine. However, I have seen mention in a couple of ngs that some older software requiring libc063.dll does not work with the version supplied with libc064 package. Not sure what software is involved but I either have not used it(those) recently or do not have the(those) package(s) installed.

   WarpIn requires you have some discipline to install libraries always at the same place (no one seems to agree where each piece of software should be installed). Since some packages install them on eCS/DLL, others on OS2/DLL (and so on), this *may* generate a lot of duplicity. Sometimes a library is updated, sometimes an old library is provided as a stub to a new one... this brings problems.
   About adding things to PATH/LIBPATH, think on VLC... think on SDL, think on FFMPEG, think on CDRECORD... just to name a few. Ok, one can put all of them in the same /DLL and /BIN directory... but then, we will be using Linux path structure, with different path names. What is the point against RPM/YUM in this case?

Quote from: Pete on 2012.01.31, 19:55:18
A simple way of avoiding gcc/libc*.dll hell is to decide to stick all those dll files into 1 directory. On an eCS system that should be [BootDrive]:\ecs\dll and for OS/2 I suggest [BootDrive]:\os2\dll. That directory should be in the LibPath - fairly close to the start of the line.

  Just as I said above...

Quote from: Pete on 2012.01.31, 19:55:18
Another thought: Any time you update gcc/libc dll files you should reboot - just to make sure that the file(s) replaced are not already in memory which will cause problems if you try to run an app requiring the updated file(s).
No, Sorry but I am not convinced of the necessity of yum/rpm at all.

  I am sorry I am such a BAD English writer. I did not said it is necessary. I said "if you can't beat them, join them".
  Instead of moan and do all the hard work (getting the ZIP file and so on), I am giving YUM/RPM guys a chance. And I am complaining what I think is missing.

  You are fighting the wrong guy. I am not advocating RPM/YUM. I am just saying I realized it is not that horrendous thing at all. It is worse than WarpIn from a user point of view? In some aspects, YES. But it is not (for me) a reason to depart from OS/2. And if I will have to live with RPM/YUM, then I want the developers to know what I think is missing.

   Regards,

   DJC
#7
Quote from: DougB on 2012.01.31, 19:23:40
RPM/YUM is a HUGE step backward, and I, for one, will not accept that.

WarpIn is a no-go because many developers will not use it anymore. This may be an unfortunate decision, but it seems I will need to live with it.
What I am trying to point out is what it makes it bad... and CAN be corrected. I was not intending to start "we like" x "we do not like" discussion again.

Anyway, using RPM in a plain clean install (and installing with WarpIn only what is missing) brought no problems and everything installed through RPM *and* WarpIn is working as it should, without conflicts. Besides the messy Linux directory structure and the "you must know package names" thing, I really had no problem with RPM.
OTOH, installing the YUM/RPM package on a system with lots of software already installed *did* revealed a lot of problems, mostly with duplicate and incompatible DLL versions.

Regards,

DJC
#8
Quote from: Pete on 2012.01.31, 16:42:59
Sorry but I'm not in favour of yum/rpm myself.

  I am not also. But I am being realistic. Those who port software will use RPM/YUM. So...

Quote from: Pete on 2012.01.31, 16:42:59
Also the only thing that seems to make it difficult to keep track of gcc and libc dll packages is the lack of information provided with the software that requires them.

    No, there is also incompatible libc versions, there are programs that are packaged with their own versions of (sometimes buggy) libc which bring problems to other programs if LIBPATH statement is not correctly ordered... etc.
    Most cases of "this program works here but not there" are examples of this situation.

    The "root" of the problem is the need of ported software. We should never need to use ported software on a day-by-day basis... But they are what we have to work with (almost no native software is developed nowadays) and make them understand "what OS/2 is" and "how we like to work" is very difficult (and demands lots of work)... We do not have the human resources to do it. So, the idea is reduce the porting difficulties, so more software can be ported and more bugs can be solved in a reasonable amount of time. The number of OS/2 developers is falling year by year... we should keep that in mind.

     I would like to REMARK: I *do not like* RPM/YUM... the same way I do not like using CDRECORD or FFMPEG. But with proper user interfaces (DVD Toys and AVxCAT for instance) they are quite useable. I *hate* UNIX file structure. But I also hate the need to add dozens of paths to LIBPATH and trying to discover why this ported program is not working in my machine if it works on every other machine in the world.

     Between using RPM/YUM or not using updated software at all, one has to choose between bad and the worst. In that case, I choose bad (RPM/YUM). It has a sour taste, but it is better than famine.

    Regards,

    DJC
#9
Quote from: jdeb on 2012.01.31, 03:13:45
That little guy was hungry for some OS/2 Kernel.  ;D

  Well, since it was dead... I believe NT kernel acts like some kind of poison. :P
#10
http://www.os2world.com/content/view/21385/2/
QuotePosted by Eugene Gorbunoff - Friday, 27 January 2012


New poll. .. .

  I think RPM is not really a "definitive" barrier. It´s not that difficult, provided some additional software (non-existent at the moment). I believe many users are troubled because they feel they are loosing the control of their systems, leading to a lot of problems when something goes wrong (and they often do, and that´s the reason why I do not like Linux).

  Anyway, since "let´s get back to WarpIn" is a "no-go", lets stick to the user interface problem: RPM/YUM user interface is poor. I often have to copy/paste yum commands from Wiki pages to install packages, and this is not something I would call "intuitive".
  RPM/YUM would be a lot more interesting with a eCoMarket-like interface. Even more interesting if a daemon stay running and verifying now and then (once a day?) if there are updates to the installed packages - and ASK the user if he wants to install them.

   Another interesting eCoMarket feature is keeping a local copy of installed packages, so this local repository could be burn to a CD and used in future installations when on non-internet connected computers.

   RPM/YUM for OS/2 should be provided with a tool like WarpIn Package Manager, which can easily show *every* file installed in *which* folder and *what* icons were created by each installed package.
   
   I liked a lot RPM/YUM do know WarpIn database (when I tried to install new Odin I received the message "Hey, uninstall current ODIN installed by warpin first!"... but this could be improved with a dialog "Odin was previously installed with WarpIn. Uninstall it first? [OK] [Abort]". Also, it would be nice if the "rpm/yum" updater daemon checked what WarpIn packages are already available in RPM format and asked the user which they would like to migrate to YUM/RPM and do it silently.

   I know it is impossible to do it for all applications ever provided in WarpIn format, but this should be done at least for more popular WarpIn library and application packages.

  Also, a simple guide of HOW one could package an application using RPM/YUM (or even how one can convert a WarpIn package script to RPM/YUM) would be nice too... the many developers adopt RPM/YUM, the better will be its acceptance (keep in mind how hard is to keep track of all gcc*.dll and libc*.dll these days).

   Well, these are my remarks about the topic. I understand the reasons why developers would like to move to RPM/YUM and UNIX directory structure... OTOH, I do understand why long time die-hard OS/2 users do not want to use a tool (whatever it is) which makes their beloved operating system as clumsy as a Linux distribution.

   Regards,

   DJC
#11
Quote from: jdeb on 2012.01.26, 15:45:17
There are a few motherboards out there without video but all of them come with sound. The sound quality on today's boards are actually very nice and non problematic. Even if you decide to buy a board with on-board video and add a card (Ati X300 or X800 series are good for eCS) the BIOS will default to where the monitor is plugged into. That used to be more of an issue years ago. Windows 7 runs much better with a discrete graphics card in my opinion... however,  the new Sandy Bridge CPU's have stunning graphics built into the CPU. Additionally,  Blonde Guy has some nice pre-built eCS systems if money is not an issue.
http://www.blondeguy.com/products.html

  I´ve not tested it on eCS (this specific computer doesn´t boot eCS), but when running Windows 7 the Sandy Bridge integrated video produce very good graphics for desktop (not sure it is a good chip for 3D games) but makes the CPU/Chipset as hot as hell. I´ve bought a PCIe ATI X850 and I am very happy with it on that computer. I hope soon I can install eCS there.
#12
USB / Re: iPod Mini and eComStation
2012.01.24, 01:13:46

  Oddly enough, after installing latest ACPI drivers (which otherwise works flawlessly with /VW option in the nForce2 machine) the computer just hangs when iPod is connected to the USB port.
#13
Quote from: jep on 2012.01.20, 12:58:01
Had exaclty the same problem...
I placed the HOME and the Programs folders on D: but OpenOffice didn't start after I tried to install it to D:\Programs.
Solution:
Install it to C:
e.g. C:\Programs\OpenOffice... that is.
//Jan-Erik

  Thanks Jan. Installing to C: did the trick.
  Weird.
#14
Hobbes Archive / Re: Installing PMFIX.ZIP
2012.01.24, 01:06:52
Ian Manners sent it to me and it worked like a charm.
CDRWSel: try applying just the SYS3171 fix.
#15
Hobbes Archive / Installing PMFIX.ZIP
2012.01.23, 18:28:28

  Holger Veith published two fixes for PMMerge, one regarding message queue and another adjusting the behavior of default font size on message boxes. The fix about default font I was able to apply without problems, but the message queue fix reports that the verification failed. Since I am using the correct version of PMMerge, I run out of ideas.

  Anyone was able to install this fix?

  Regards,

  DJC