Author
Topic: Closed source parts of eComStation (Read 23394 times)

1] The touchpad does not work because the laptop has a shared ps/2 port and that is not coded for in OS/2. All I can really tell you about the touchpad is that Windows7 "sees" it as a *standard* ps/2 connected mouse and uses *standard* Windows7 ps/2 drivers: i8042prt.sys and mouclass.sys.

2] Not sure if you are suggesting "patching" the Dell E5500 BIOS. If you are you are definitely talking to the wrong person as I would not know where to start - and doubt that it would be of any use. The Dell supplied Windows2k/XP drivers do not work with genmac - nor do any from Broadcom - and I doubt "patching" the BIOS will help.

I'm not really interested in trying possible fixes for this laptop any more. I've spent far too much time on it already so it is up for sale.

there was no chance of getting the touchpad to work - who wants to carry an extra mouse around with them?

I have a Lenovo ThinkPad T510. That one has a BIOS setting to enable/disable the TouchPad. I disable it because I HATE those things, but it does work with eCS. The stickmouse works well, and I don't mind using it (for short periods), but I do carry a real, wireless mouse, to use for longer sessions.

I also have a newer Lenovo ThinkPad L530. The stickmouse, and Touchpad, both work. Unfortunately, there is no way to turn off that ANNOYING TouchPad (the windows driver has a way to do it). All that I was able to do, is cover it with a piece of heavy cardboard, to keep my paws off of it. I also have a real mouse tor that one. FWIW, I also installed PCLinuxOS on it. Neither one of those devices will work with that (I haven't tried too hard), so I need to use the real mouse.

More important, are things like support for the majority of NICs that exist today, and in the future. Without communication (especially wireless), nobody will be able to continue using eCS. It just won't do the job. It can't always do the job today, without wireless communications. There are keyboard problems, there are video problems, there are printer problems. Somebody had better start fixing all of them, or eCS will be as dead as IBM, and Microsoft, wishes it was.

I have to agree, especially on the wireless and wired network drivers I'd put higher priority on this then I would on the 4GB barrier.

Just as a real-use example, not long ago I set up a customized desktop machine. The machine needed to run a specific task 24x7 where it grabs information off the web and then feeds it to some old DOS-based apps which then feed the data to some custom hardware. The system also needed the ability for someone to push specific information to it in place of the web-based data. Originally the setup involved multiple computers (one computer receiving the data over a network and pushing it out a COM port and the DOS comptuer(s) running their apps receiving the data over the COM port and then processing the data to the custom hardware). With OS/2 I was able to consolidate it all into a single computer - running a few DOS boxes for the DOS apps, OS/2 apps for the network stuff, and a custom REXX script to sort everything else out. In testing it all worked out better then the original setup.

The biggest challenge I ran into was networking. Where this computer has to be located there is no direct ethernet connection but there is stable secure Wifi.

What I ended up doing is I set up the OS/2 computer to use a standard Ethernet card that has drivers. I then used a D-Link DIR-615 (cost of around $20) router and installed DD-WRT on it. I then set up the DD-WRT box to log into the Wifi signal and I have regular Ethernet cable connecting the 615 to the OS/2 box. It works like a charm.

Admittedly part of my challenge was that I decided to use a spare OS/2 Warp Connect license that I had unused sitting on my shelf for this test setup. I have no expectation to ever get Wifi working on Warp Connect, so this might seem like an insignificant example to use as an argument for good Wifi and NIC drivers. However in this case networking and being able to find a way to connect to a Wifi network was absolutely necessary for the setup. The 4 GB limit played no role in my decision to set up an OS/2 system.

I have to agree, especially on the wireless and wired network drivers I'd put higher priority on this then I would on the 4GB barrier.

<...>

Admittedly part of my challenge was that I decided to use a spare OS/2 Warp Connect license that I had unused sitting on my shelf for this test setup. I have no expectation to ever get Wifi working on Warp Connect, so this might seem like an insignificant example to use as an argument for good Wifi and NIC drivers. However in this case networking and being able to find a way to connect to a Wifi network was absolutely necessary for the setup. The 4 GB limit played no role in my decision to set up an OS/2 system.

Okay, if we're posting our (IM)NSHOpinons here, then I will share my experience.

I had never had a networking trouble with OS/2 that I could not resolve.

I'm putting the 4 GiB barrier resolving task the upper priority than the NIC drivers thingy, because the lack of the drivers for the newest NICs never had played a role in my decision to set up OS/2 systems.

To explain this I'll say that if we cannot substantively argue on the tasks' priorities, and we rollback to the stinky democracy, I will just give my vote to the 4 GiB task, and see what'll happen.

Logged

LIABILITY DISCLAIMER: this is how I understand and what I know, I may be highly inaccurate, or even completely wrong! There are no claims, promises, or guarantees about the accuracy, completeness, or adequacy of the contents of my posts. Think on your own!

The whole address space, on OS/2, that you can use with A LOT of processes (programs), is limited to 4 GiB.So, even if you have the swapping feature enabled and large enough hard disk, you cannot run 500 programs to allocate 500 GiB (one GiB per process).

You could if the swapfile wasn't limited in size and you could put up with the thrashing. In theory the limit is 64 TB minus kernel and hardware space. In practice I think the limit to the swap file is 2 or 4 GB.

Quote

While on Windows 32-bit, one program still cannot allocate more than 4 GiB, but you can swap on your hard disk and allocate 500 GiB with a lot of processes.

Generally Win32 can only use 2GB (3GB with the /3 switch) whereas OS/2 before Ver4.5 could only use 512MB (drivers such as HPFS386 cache could use higher memory) while v4.5+ can use the 512MB low area (minus shared s really like 300MB) plus memory above 1 GB which depending on the VirtualAddressLimit setting and hardware can be another 2.5GBs. Not every program can use the high memory and 16 bit programs are limited to the lower memory.In real life we could still link the Mozilla xul.dll while Windows first needed the /3 switch then had to go to the 64bit version to map out a full 4GBs.See http://www.os2voice.org/VNL/past_issues/VNL0708H/feature_3.html for a decent overview.

Quote

So, the trick is to put the swapfile not on the harddisk, but on the ramdrive, which would be able to map the memory above the 4 GiB limit using PAE without affecting the rest of the system.

So, that is the limit I am talking about. It could be overcomed by reimplementing the memory management subsystem in the OS/2 kernel.

I tried allocatting 4.5 GBs here but with only 1.5GB of real memory I gave up after an hour and half of disk churning. It would be interesting to test on a system with 4GBs of memory and also to test with the swapper on a PAE ram disk.Not being much of a programmer I simply modified allocmem to use high memory and not exit right away. Here it would allocate 900 MBs per instance and I tried launching 5 instances. Warp V4 froze pretty quick while eCS 2.1 thrashed for 1.5 hours before I reset the computer. So if testing be prepared for a crash. Here is the program.

I had never had a networking trouble with OS/2 that I could not resolve.

We can soon change that: purchase my Dell E5500 and see if you can get either wired or wireless nic working. Of course, getting both working would be ideal - but just 1, either wired or wireless, would be very good :-)

This is the 1st system that I have failed to get eCS (OS/2) networking to work on but it is also the most modern laptop that I've tried to install eCS on.

Yes, it would be nice to be able to use 4Gb or more of RAM - not sure what for though. I have a minimum swapfile of 2Mb and that never gets used so having a large ramdrive for a swapfile would currently be an exercise in futility.

I'd rather have connectivity and the 3.5Gb (or thereabouts) RAM limit if I had to chose.

Well about strategy - the following idea is not new - we talking about 10 years about this:

If you develop or maintenance a niche system, with I'll guess less than 10.000 users world wide (maybe much, much less) which has absolutely no relevance for any hardware manufacturers, you can't do the "universal thing" anymore. This OS can't run on any hardware. A first step would be to face it!

Trying to make the Universal OS is part of the problem and not the solution.

The solution is to focus on a small set of systems. Make eCS right for a couple of systems. One system, for each class, like

1 or 2 desktop PCs1 or 2 notebooks1 server

As the OS vendor you have than- great reference systems to show whats possible- easier support- much less development efforts- easier installation (in fact you don't need to install, you can clone the whole thing)- a chance to sell hardware with pre-installed software and make some additional money with hardware

To be honest this idea is not mine it comes from Apple while they played in a niche, a niche multiple times bigger than ours.

LIABILITY DISCLAIMER: this is how I understand and what I know, I may be highly inaccurate, or even completely wrong! There are no claims, promises, or guarantees about the accuracy, completeness, or adequacy of the contents of my posts. Think on your own!

The problem is that the hardware cycle is really too short for that to work. Apple could do it because they controlled the hardware specifications (which they were influential enough to do even at their weakest).

The turnaround time for a particular system model is AFAIK on the order of 3-6 months. That's just not enough time to develop the driver support, QA it and release before the system is obsoleted by the next model.

The problem is that the hardware cycle is really too short for that to work.

The turnaround time for a particular system model is AFAIK on the order of 3-6 months. That's just not enough time to develop the driver support, QA it and release before the system is obsoleted by the next model.

Alex, I think you're misinterpreting the proposal. The idea is to pick at least one model and develop all the essential drivers for it. It has nothing to do with the life cycle of that hardware. We all use really outdated hardware and know where to buy it, so that won't change then.