• 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 - Fahrvenugen

#1
While it was already released as a binary for free, I'd love it if the source code to Innoval's Post Road Mailer were released.

#2
Hi,

I havn't done a fresh install of eCS in a while, but I think during the eCS 1.2 install there is an option to have it not install the dialog enhancer / eCS menu / eCS visual / desktop enhancements and stuff.  I seem to recall doing this on one machine and ended up with the standard Warp 4 desktop in the end (with of course all the updated drivers found on eCS)

#3
As I recall, virtual com ports in sio2k have to be set up in  a configuration file that you tell sio2k to load within the config.sys line(s)

Its a little confusing to figure out (read all the .txt doc files that come in the zip to figure it out), but it can be done.  I recall one time when testing I managed to get something like 200 virtual com ports configured and able to accept telnet connections (incoming) via vmodem and sio2k.

If my memory is correct (its been several years since I played around with this) one thing I did run into with this - DOS and Windows apps couldn't recognize this large number of comm ports, however OS/2 apps in general could be made to work.

#4
Hi,

I've run Procomm Plus in OS/2 dosboxes for years without any difficulty - I've always had good luck with it.

I've also run the Windows 3.x version of Procomm Plus (both the 2.x and 3.x versions) within a WinOS/2 session without any difficulty.

As for BBSes, you'll probably find that Major works fine in Dosboxes.

One thing you may want to consider is running Ray Gwinn's SIO2K drivers, you can download them from Hobbes

http://hobbes.nmsu.edu/h-search.php?key=sio2k&pushbutton=Search

It handles Comm ports a lot better then the stock OS/2 drivers.  Note - these drivers are shareware, however as far as I know there's no way to register them (if anyone knows differently then please correct me). 

The other thing about SIO2K drivers - it'll handle up to something like 256 comm ports (either real or virtual ones)

And it also comes with VModem a little app - which turns any virtual Comm port into a virtual telnet modem.  This is great for a BBS since it makes it possible to turn any BBS (whether it is set up for this or not) onto the net as a telnet-accessed BBS on the net.  No phone lines needed.

Another BBS package out there which has a native OS/2 build is Maximus BBS.   Originally a commercial product, about 7 or 8 years ago it was released as free (and the source got opened up).  I'm not sure if the open-source version has been built on OS/2, however I know the 3.0.1 version was released as "free" at around the same as it was made open source (registration no longer required).  Its on Hobbes:

http://hobbes.nmsu.edu/h-browse.php?dir=/pub/os2/apps/comm/bbs/maximus

Note, there was also a Y2K update for the OS/2 stuff, for some reason it isn't in the Hobbes archive, but can be found here:

http://www.os2bbs.com/file_f/bbs/MAX301P2.ZIP

#5
I seem to recall back when ecs first came out, I think there was an option to just install Warp 4.52 or eCS (since eCS essentially is a Warp 4.52 license with the additional eCS stuff added on).  By having the eCS license this allowed you to use any of the eCS specific stuff on after a base 4.52 install (unsupported of course)

I wonder if this would still be a possibility - not that anyone would expect that Mensys would  provide support for such a thing, but for anyone who needs Warp 4.52 with a few of the eCS 2.1  additional items (like ACPI, Flash, etc), if you could purchase a eCS 2.1 license, install a base Warp 4.52 setup, and then just add in yourself the few extras (again, this would be unsupported and meant for the people who really know what they're doing, or people who don't know what they're doing and just like taking risks with their system).  From a licensing standpoint I think as long as you've got the eCS 2.1 license you should be okay doing something like this, but perhaps someone more familiar with the license can clarify.


#6
Agreed - I am guessing that in order to do what you're trying to do you're going to either

1 - have a working and installed copy of OS/2 to create the disk images that you'll need for your virtual pc, or

2 - you'll have to use the stuff on your install CD to create some install disks, and then modify Disk 1 with the updated drivers that you need (the same way that it was updated for the warpdoctor site that was referenced earlier).

#7
Hi,

Are you working from the all-floppy version of Warp 3, or from the CD version which came with the 2 install disks?

If you're working from the CD version, then the XDF issue isn't really an issue - install disks 0 and 1 were both shipped in the standard FAT format by IBM, and the rest was on the CD.  It wasn't until you got to Disk 2 of the floppy version that you started getting into XDF.  However you'd still need a way for a VM to read disks 0 and 1 (assuming you're installing to a Virtual PC of some sort)

If you've got an installed copy of Warp, you should be able to use dskxtrct to extract the .dsk image for disk 1 to a folder on a hard disk.  Then you can use the content of that folder (Disk 1 was just a collection of files - there wasn't anything in the boot sector on it - that was all on Disk 0)

The easiest way to get Warp 3 to install (I actually just about a month or so ago had to do a fresh Warp 3 install on a modern PC - the biggest challenge was getting the boot partition correct - it can't be too large a size or else it won't boot - but it can be done) is to build an updated and bootable Warp 3 instal CD using UpdCD:

http://xenia.sote.hu/~kadzsol/rexx/sajat/updcd.htm

If you're using the all-floppy version of Warp 3, the best thing to do is boot up into Warp (version 3, 4, eCS will all work) with the XDF driver loaded in your config.sys and then each floppy can read as a standard floppy.  You can then copy the floppy contents to a hard disk with the standard copy or xcopy command and build a CD install version.  Somewhere I've got instructions on how to make a CD install version from the floppies, but I don't recall all the specifics right now.  If needed I can try and dig that out (it is essentially the directory structure that needs to be correct, ensure that the CD drivers get loaded upon boot, and to use the version of the installer that looks to the CD instead of floppy).

#8
Setup & Installation / Re: RPM packager
2011.09.07, 17:12:59
Quote from: dmik on 2011.09.07, 14:00:39
Quote from: Fahrvenugen on 2011.09.07, 07:44:55
So yes, I do know what I'm talking about - moving applications from one folder and / or drive letter to another, using drag and drop.  And yes, it does work for many OS/2 based applications.

I didn't say that this does not work. You probably don't remember, but I said that this will only work for simple apps with no dependencies. This is not the case for modern apps we provide. Even a trivial kdiff3 utility needs the Qt4 runtime. Packing the Qt4 runtime with each application will increase its installed size by 40-50 MB even if the application itself is 500 K. This is insane and this will create an incredible mess of DLLs on your system.

So essentially from what you're saying this isn't all that different from apps which use the OS/2 system DLL's, emx DLL's, the Libc dll, etc.  The apps will need to be able to see the libraries they use.

Quote
Quote
I've used this technique to test apps before using them in production.

You don't need this technique with RPM. You can safely install/uninstall as many times as you want. Uninstalling the application will bring your system to the exact state it had before installing (except that the configuration file in /home/user, if any, will not be deleted, but this can't harm).

I understand what you're saying, but in a production environment I wouldn't deploy an app until properly tested on a system set up for testing stuff. But this has little to do with RPM / YUM though - it would apply equally for any application regardless of how it is installed.

Quote
I've also used this to deploy apps that run from a network share - set them up on my local machine, copy the app over to a network share, then add an object for the app to all the desktops available on the network (and doing this involves a single command).
Quote
You don't need network shares to deploy apps this way with RPM. And this gives you significant benefits.

Thank you for your appreciation.


On this point, I think you're not fully understanding me.  I'm not talking about deploying and installing an app from a network share on individual workstations.  I'm talking about having the app sitting on a network share and running it directly from that share.  The app does not get installed locally on the workstation - it sits on the network, and can have multiple workstations running the same app (accessing the application EXE's and DLL's through the network).

The reasons for this can be multiple.  For security, you can easily control what apps can be run on what workstations and by what users based on the user login and the groups the user is a part of.  If an update or change needs to be made to an app, you only need to update / change / fix the app in one place and everyone gets the update (no need to patch multiple workstations like you would in an environment where the app is installed on multiple workstations).  You can also (using remote boot type setups) run with diskless workstations if you want (similarly to how Workspace on Demand works) and have no local machine storage for anything other then a swap file, no local hard disk (other then for a swap file - improving both central management, site security, centralized site backup, etc).

Admittedly running Linux ports from a network share in this manner may not work within the FHS / YUM / RPM model.

I hope this provides a little insight into what I'm talking about with regards to running apps from a network share.  Thanks for your replies and the continued discussion!

#9
Setup & Installation / Re: RPM packager
2011.09.07, 07:44:55
Quote from: dmik on 2011.09.06, 20:51:59
Quote from: Fahrvenugen on 2011.09.06, 19:14:29
I disagree -  I drag and drop entire OS/2 based apps all the time and rarely have a difficulty.  This is one of the features of OS/2 that sets it apart from  other operating systems - it easily allows you to do this - move around either data files or entire apps without breaking things (and it even updates your shadows and objects properly) - all due to the OO technology built into the system and WPS.

We do not speak about WPS here, we speak about moving applications from one folder to another on the hard disk.



Yes, that is exactly what I often do.

I'll install an app into a folder on the hard drive and later drag it to another folder on the same drive and it'll still work.

Or I'll drag it to another drive with a different drive letter, into a different folder, and it'll still work.  And all the objects on the desktop for that app get updated too.

So yes, I do know what I'm talking about - moving applications from one folder and / or drive letter to another, using drag and drop.  And yes, it does work for many OS/2 based applications.

I've used this technique to test apps before using them in production.

I've also used this to deploy apps that run from a network share - set them up on my local machine, copy the app over to a network share, then add an object for the app to all the desktops available on the network (and doing this involves a single command).

Anyways...

Please understand that I'm not trying to attack or be overly critical of RPM / YUM - I'm just trying to offer a view of some of the ways that - as an OS/2 / eCS user - ways that I currently use the OS.  I'm also understanding more that RPM / YUM is one of those things that is ultimately up to the end user if they want to install and use in the first place.  Those who want it can use it, those who prefer not will likely not use it,  just as developers who prefer to distribute their installers with ZIP / IBM Installer / WarpIn / Feature Install / a plain old REXX script / etc will likely distribute with their choice of installer.


Dmik, also please don't misunderstand me.  I do appreciate all the work that you and other developers are doing to keep the system relevant and useful.  I admit that I do share some of the concerns that have been expressed, and as a result I likely will be one of the more cautious users when it comes to RPM / YUM. However I also don't want this to be a deterrent to development.  Each user will have different needs and comfort levels when considering introducing new software on their system(s).  Just as some users will have DOS and WinOS/2 support installed and some users won't install it, some will install Java and some won't, I can see YUM / RPM falling into a similar category.

#10
Setup & Installation / Re: RPM packager
2011.09.06, 19:14:29
Quote from: dmik on 2011.09.05, 03:30:22

It was never possible to move the program to a different location with drag & drop on OS/2 (except very trivial programs that don't have entries in config.sys and don't have WPS objects).


I disagree -  I drag and drop entire OS/2 based apps all the time and rarely have a difficulty.  This is one of the features of OS/2 that sets it apart from  other operating systems - it easily allows you to do this - move around either data files or entire apps without breaking things (and it even updates your shadows and objects properly) - all due to the OO technology built into the system and WPS.

Admittedly it doesn't work as easily on ported apps - mostly because ported apps often rely on configuration files which define the app locations.  In those cases, it not only requires drag and drop of the app, but also updating the config file(s).








#11
Setup & Installation / Re: RPM packager
2011.09.02, 18:27:23
Dmik,

I do want to thank you for trying to explain the reasoning for YUM / RPM / FHS.  However a few things have still left me with questions in my mind that just don't make sense of what you're talking about.  To begin:

Quote from: dmik on 2011.09.01, 22:10:04
Quote
Windows does not use FHS.

I don't use Windows. Windows is unmanageable. Mostly because it has nothing like RPM. However, I'm being frequently asked by some friends to reinstall their copy of Windows every several months because it is screwed, or because there is a virus, or because it is screwed and there is a virus. If they succeed in convincing me to help them I install them Ubuntu (or suggest to buy a Mac). Even my blonde girlfriend has Ubuntu installed and feels pretty much happy with it (it's been working for years on her notebook w/o any maintenance, just like OS/2 actually). So Windows is a bad example.

I understand your dislike of Windows, but reading the above seems to suggest to me that you're trying to say Windows gets messed up due to a lack of FHS and / or RPM, or gets viruses due to a lack of RPM, or both.  

Of course there are viruses, malware, spyware, etc - which can infect Windows.  However I doubt it has a whole lot of anything to do with a lack of FHS or RPM.

But setting that aside dmik, one thing I'm confused abut is the mixed message we're getting.  In one message you say:


Quote
I can only repeat again that RPM has noting to do with FHS. Without FHS we will have to a) invent our own FHS and b) maintain a huge amount of OS/2-specific patches in every program ported from Linux which will be the constant source of bugs. Neither of these things will make programs better serve the user's needs. They will only be sucking our resources resulting in less software and bigger release delays. This makes no sense. Please stop aching and better learn to think different.

Okay, so part of this is to make things easier to port apps from Linux.  No difficulty there, I can understand that.  I have used ported apps on OS/2 quite a bit and I can see the value in using ported apps.  And RPM doesn't need to be linked to FHS or the file system layout.

But then in another message you say:

Quote
Yes, RPM will dictate you the FS layout for all system components it manages (and for applications by default, unless the application developer makes the application relocatable and enables this function when packaging it with RPM). The dictatorship in the area of some system components is what you already have though.

So according to the above quote, yes - RPM does have something to do with the file system layout - it'll dictate the layout for what it manages.

If I understand, RPM has "nothing to do with FHS", but "RPM will dictate you the FS layout for all system components it manages"

Can you please explain what seems to be 2 opposite statements?  Thanks.

Ivan,

Quote from: ivan
That may sound hard but I have a business to keep running and making money.  Anything that messes with the computers has the potential to stop the business and is so discarded out of hand - we aren't playing with computers, they are essential to the business.

I have to agree with you here.  For those of us who do use OS/2 as part of our jobs, where our livelihood (or a business or organization) depends on OS/2 and our knowledge of how it works, how it is set up, and how to fix it if it does happen to break (fortunately this is rare with OS/2), introducing a significant change in the file system structure - regardless of the technical reasons for that introduction (even if the reasons are sound and make sense to developers) - presents a significant risk.  I'm not saying that FHS / RPM / YUM is a bad thing.  I just share your view for caution - especially on any production system.



#12
Setup & Installation / Re: RPM packager
2011.09.01, 19:48:15
Quote from: dmik on 2011.09.01, 03:42:28
Fahrvenugen, RPM is capable of replacing all of them.



I'm sure RPM could replace all of them, just like Warpin can replace ZIP, the original IBM installer, and Feature Install (at one point Warpin's goal was to replace all the old installers).  But the reality is that unless someone goes through and repackages all this stuff in RPM (which would seem a silly and pointless waste of time IMHO), it won't replace all of them.  RPM/YUM will just become yet another installer you have to put on your system just so you can install the stuff packaged with RPM. Does that mean I'm rejecting RPM / YUM?  Not at all.  I'm just pointing out that it what it'll mean to me, as someone who uses and supports OS/2 / eCS.

Quote from: dmik

What you say about OS/2 and its in-the-middle approach was true in the past. It cannot remain like that now. (Well, it can, if you install it on an old 486 PC, load it with old programs made in 1992 and will *not* ask us about modern software and all the fish). You cannot also remain an expert in the changing world if you don't change with it. The compexity is being constantly increased; if you want to deal with it, you have to move to a next level. Or leave it.

I can't speak for others, but part of the reason I keep OS/2 around is because of this approach (and yes, I also use Windows and Linux on a daily basis).  If I want the latest and greatest cutting edge stuff, Linux and / or Windows fits the bill.  But when I want something that works well - as well as it did 10 to 18 years ago and have it use some of the same standards as it used back in 1994 when I installed my first copy of Warp 3, I get that with OS/2.  Furthermore I know that when I get OS/2 or eCS up and running, it'll generally "just work" (true, it might take some time to get it up and running depending on hardware, but once it is up my experience has been that things just keep working...  one machine I set up to run some specific tasks recently ran for over 2 years without so much as a reboot, until a power failure and bad UPS battery brought it down).

I know this feedback has little to do with porting current software and such.  But it can perhaps explain why there is so much discomfort with this proposal. 
#13
Setup & Installation / Re: RPM packager
2011.08.31, 23:16:19
Hi,

For me, having RPM or not having RPM available on the OS/2 / eCS platform really isn't all that significant one way or the other.  In the end - RPM is just another app from Linux that can get ported.  In fact an older version has been on Hobbes for a while:

http://hobbes.nmsu.edu/h-search.php?sh=1&button=Search&key=rpm306&stype=all&sort=type_name&dir=%2F

What I see is more significant (for me, at least) is the fact that I'll need to have 1 more thing to add to eCS installs in the future to make them work.

Right now when I do a fresh install of OS/2 or eCS, I find myself setting up several different installers just to be able to install stuff.

1.  Zip / Unzip (this is more then an installer, as I use it almost every day)
2.  The original IBM installer - for those older apps which use it but don't always seem to end up having all the needed DLL's to make it work (such as Embellish, the old Netscape 4.6.1, which leads to...)
3.  Feature Install (which is why I installed Netscape 4.6.1 ion the first place - I have a  few things built on FI based installs that I often install)
4.  WarpIn (for all the WarpIn stuff, obviously)

With this talk, it looks like I'm also going to need to add RPM / YUM on to this list.

As for the discussion about wanting to have control over what gets installed where and knowing exactly what is installed - I definitely am the type of user who wants this level of control.  I want to know exactly what is happening with a software install.  For this reason, my preferred installer is plain old ZIP and a text file containing info on what is needed.  This I find gives me the highest level of control. 



#14
Setup & Installation / Re: RPM packager
2011.08.29, 18:46:47
Forgive me if I'm missing something, but I thought it had been pretty much established that the current preferred installer for eCS is Warpin.

#15
Rexx / Re: Detecting french accents
2011.08.22, 18:18:11
Thanks, that's the type of thing I have been looking for!