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

Pages: 1 ... 6 7 [8] 9 10 ... 28
106
Hardware / Re: Battery and Thinkapad r52
« on: 2012.03.18, 17:02:16 »
Quote
While the latest ACPI doesn't help much (actually it might make it worse),

Not in my experience. I have a Lenovo ThinkPad T510, an IBM ThinkPad T43, and an Asus M3A78-EM motherboard, with quad core Phenom processor (desktop). All of them run much cooler (and therefore more efficiently) with ACPI 3.19.15. Versions earlier than 3.19.11 (actually 3.19.13) don't do power reduction without some sort of outside program, and you do need to enable throttling with ACPI 3.19.15, or it doesn't do it either. The installer puts the wrong path in the ACPI Power Manager icon, it is actually in the eCS\BIN directory. Run that, and you can enable the throttling, as well as change other things (probably not recommended unless you understand what you are doing).

I also have an older IBM ThinkPad A22e, that does not do ACPI, so I use APM with it. The (new) battery is good for about 2 hours, while the 15 month old T510 (using ACPI 3.19.15), is good for about the same time. Windows 7, claims that it will do about 3.5 hours, but that is only true if you don't actually use it. The battery goes down a lot faster when you do use it. Windows also powers off more stuff than eCS can (the CD/DVD drive goes off until you press the open button, twice). I suspect that there are some other things that eCS doesn't even know about, like the media card reader, and the Express card slot, that do not  get powered off. It also will not power off the screen.

Yes, the battery does get used up faster in eCS, but the actual difference to what windows will do is not as much as you might expect. The new ACPI power saving is much more effective on multi-processor systems because part of what it does, is turn off all but one CPU when the processing power isn't needed, then it turns them back on when it is. My T43 (single processor, running in an SMP setup) can be made to save more power if I use the old SETGETSTATE.EXE program to slow it down. It appears that the new ACPI does not use that method.

Quote
Are there any differences between OS/2 and Ecs concerning APM?

No. APM hasn't changed for many years. It also doesn't do as much for power saving as the latest ACPI does. The main advantage of APM, on my A22e, is that hibernation will work with it. I can't get suspend/resume (never mind hibernation) to work with my T510. Actually I think it does work, but it won't turn the screen back on, so it is difficult to tell. The suspend/resume, and hibernation, is done by the BIOS in the A22e, all it needs is drivers that can do what they are told.

107
Hardware / Re: Battery and Thinkapad r52
« on: 2012.03.17, 23:47:45 »
I am not sure if the thinkpad r52 can do ACPI or not. If it can, you should use the ACPI stuff from eCS Software Subscription, if possible. The old APM really does not do any power saving, so everything runs at full power, and that will drain the battery faster than you might expect. It should not hurt the battery, as long as you don't let it get to less than 25% most of the time. Going lower, every once in a while, doesn't hurt either, but doing it all of the time will shorten the battery life.

Since it is a new battery, you should drain, and recharge, it a couple of times, before you trust the numbers. It is possible that there is still some residual battery data left from your old battery.

108
Hardware / Re: eCS v2.1 and OS2AHCI.ADD where?
« on: 2012.03.15, 00:07:41 »
Quote
I also used the OS2AHCI community version at hobbes os2ahci_v0-1-4.zip (2011/09/16) and worked very good for me.

I couldn't get it to work for more than about a minute, without trapping, on either of my systems. The "official" version 1.22 works perfectly on my Lenovo ThinkPad T510 (even with hyperthreading enabled), and it takes about 4 hours on my Asus M3A78-EM motherboard, with quad core Phenom processor, before it traps (more analysis to do with that).

Quote
What would be a good test that can be done under eCS to show some results of the HDD performance to compare it with AHCI enabled not enabled.

I think you would need to be very careful about comparing numbers. If you write a test to specifically show the advantages of AHCI, I am sure that it could be made to look extremely fast. On the other hand, sequential I/O in a single thread, probably won't show any difference. If you read the docs, very few programs (if any) are written to take advantage of the features of AHCI, and it would be pure coincidence if two, or more, programs happened to do something together to make the advantages actually help. Repeating something like that would be impossible, and I doubt if a user would notice the difference, without using some very fine timing measurements. On the other hand, AHCI does open the door for more overlap in I/O processing, if somebody wants to take advantage of it and write I/O routines that can use it. Some very heavily I/O bound systems may see some speed increase, if multiple programs happen to overlap their I/O a lot. In most cases you will see very little difference, and file system cache will hide any difference anyway (it is so much faster).

IMO there are three reasons to use OS2AHCI:
1) To test it to make sure that it works in as many cases as possible (see 2).
2) To support those systems that do not have any other option (apparently, there are already a few of them).
3) So that you don't need to switch the BIOS every time you boot another system that does (or doesn't) use it.

In my case, I have Win7 on my Lenovo ThinkPad T510, and the machine arrived with AHCI enabled. I was able to switch to Compatibilty mode in the BIOS, and eCS worked fine (in this machine, it is one, or the other). WIn7 was not very happy about that, but it is possible to convince it to use the old IDE mode. Once I got eCS 2.1 installed, with AHCI (due to a bug in the installer, the AHCI driver is not installed, unless you install using AHCI), I got Win7 to work with AHCI again, and all is happiness.

On my Asus machine, I have WinXP, which knows nothing about AHCI. Apparently, you can find a driver to make it work, but that seems to be a lot of messing around, with no guarantee of success. The Asus BIOS can be left set to Compatibility, and it will switch to AHCI mode if the AHCI driver is loaded before the Dani driver. Since I get a trap, after a while, in AHCI mode, I have decided to use the Dani driver, and worry about AHCI when I find some time to test it. If I switch the BIOS to AHCI mode, the dani driver, and WinXP, won't work.

The bottom line is that using, or not using, the OS2AHCI driver depends on a lot of things (not the least of which is the BIOS support). In a "production" machine, you are probably safer to stay with the Dani driver, unless there is some reason not to. At this time, it would be good for as many people to try it as possible, just to shake out the bugs. Someday, there may not be an option, so it would be good to have AHCI working properly. You may also want to use it for convenience (see my T510 scenario, above). The last consideration, IMO, would be whether it is faster, or not.

109
Hardware / Re: eCS v2.1 and OS2AHCI.ADD where?
« on: 2012.03.14, 18:08:30 »
Quote
I found them, at last, on the EDG Beta site.

What is that site? The only way to get the "official" OS2AHCI is from the eCS 2.1 install CD, or from the betazone (accessible by your Software Subscription). The latest version is 1.22, and it does work better than the one on the eCS 2.1 install CD. It still traps after about 4 hours, on my Asus M3A78-EM motherboard, with quad core AMD Phenom processor, using the "/s /n" parameters. It looks like the problem may be related to operating my SATA DVD writer, but I haven't pursued that any further, yet.

OS2AHCI 1.22 works great on my Lenovo ThinkPad T510, using the "/r /s /n" parameters.

Be aware, that there is a bogus version 1.4 floating around, and it doesn't work very well.

110
Networking / Re: GEN MAC news?
« on: 2012.03.04, 04:32:05 »
Quote
The Broadcom BCM5704  vid:14e4  dev:1648.

Ivan, it seems that most, if not all, of the Broadcom BCM57xx devices use the same driver, so it is quite likely that your device will work with GENMAC. I added your device to the GENMU_TEST package at:

ftp://genmac@ftp.os2voice.org/

If it asks for a password, use the word "unsupported" (no quotes, and lower case). If it does work, I will add it to the GENMU package, and it may be possible to get it added to the GENMAC installer that comes with eCS 2.11 (if we are quick enough).

111
Applications / Re: Where are Open Office source files?
« on: 2012.03.03, 22:26:59 »
OpenOffice has turned into LibraOffice. Look it up.

The basic OpenOffice for eCS is the windows version, and that part is free, and available from the OpenOffice web site (if it still exists). The additional stuff to make it work properly in eCS is NOT free. You need to buy it if you want it (OpenOffice 3.2 is included as part of eCS 2.1, so if you have that, it is on CD #3, or you can download it from the Mensys login site). The additional stuff is also not (L)GPL, and the source is closed AFAIK.

FWIW, you can do your own development on what is available for windows, but I think it would be a big job.

112
Networking / Re: GEN MAC news?
« on: 2012.03.03, 00:46:04 »
Hi Paul.

I would assume that anything that does actually work with GENMAC will be considered to be "supported", even if it needs to be run in "UNSUPPORTED" mode. So, new things that we have no support for, at the moment should be listed here, preferably with the product name, the vendor ID and the device ID, as described by the PCI program, when possible. Of course, if a new driver can also pick up something that is currently supported by GENMAC, that is very good.

My current requirement is for a Realtek RTL8191SEvB wireless LAN controller. [10EC:8172].

113
Article Discussions / Re: Making ATMs Accessible
« on: 2012.03.01, 19:43:41 »
Years ago, I played with Backtalk:

http://hobbes.nmsu.edu/download/pub/os2/apps/speech/btalk201.zip

(hope this comes through properly). It actually worked pretty good, especially after adding the available dictionary (mentioned in the docs). It should work even better today because of the faster processors (I must try it again).

114
Hardware / Re: USB3
« on: 2012.03.01, 19:34:00 »
Quote
Since I tested this, it is now a must have... (fast backup, fast application start etc..) 

Hehe. You young pups are always in a hurry   :)

Quote
the trasnfer is so slow on OS/2 mainly due to... bad FAT32 support

I agree that FAT32 is not very good (even in windows), and NTFS is likely to remain as it is (not usable by OS/2). USB (including USB 3.0) is slow, and there isn't much that can be done about that. It is the nature of the beast. There are other approaches that make a lot more sense, like eSATA, and NAS devices with gigabit interfaces. Better support for eSATA should be possible (hot plug, and eject), and most real NAS devices do have support using SAMBA. You do need to avoid the devices that need a special windows driver, but that is nothing new.

Quote
until we get good FAT32 or NTFS support, improving drivers will not change much in that case...

Don't count on either one getting better. If you need compatibility with windows, and OS/2, you probably need to put up with FAT32. If you are using the devices in windows only, NTFS is the answer. If you are using them in OS/2 only, JFS is the answer. In all cases, USB will be slow.

Years ago, Carbon Based software had a driver that would create a drive, using the contents of a ZIP file (a demo is on a CD that came with warp4). Using compressed data on a USB device should be faster than using plain data (now that processors are fast enough to keep up to the compress/decompress requirements), just because there is less data to transfer over the interface. There would, of course, need to be support for other operating systems, if there is to be any compatibility. Of course, if it is a ZIP file, other systems do have support for them, as long as the base file system is compatible.

Portable WiFi devices could also answer a need for portability, and compatibility. N adapters will run at 300 Mbs, under ideal conditions, and they should be compatible with the standard network requirements (probably SAMBA). In that case, it doesn't really matter what the underlying file system is. This is, of course, just a NAS device. Cost to the consumer, is the big drawback, currently.

There are probably other possibilities, but I think there are a couple of drivers that could form the basis of using a ZIP file as a drive. ISOFS essentially does that with ISO image files (although there is no write capability). There is also AEFS, which creates a secure (password protected) drive out of a bunch of files on the HDD. It does have read/write capabilities. I know that the source for ISOFS is available. I am not sure about AEFS. If the AEFS source is available, it is probably not too complicated to change the storage file(s) from encrypted stuff, to being a ZIP file (possibly even encrypted), which should be compatible to other operating systems. The base file system would still have the restrictions mentioned earlier, but data transfer would be faster because there is less data to move across the slow interface. Of course, zipping ziped (or otherwise compressed) files probably won't make much difference.

Any other thoughts?

115
Networking / Re: GEN MAC news?
« on: 2012.03.01, 18:33:22 »
Quote
The problem for many current users of eCS on laptops is reduced functionality today from the lack of wireless on many laptops.

I agree that this needs to be one of the top priorities, and I know that it is being worked on. It is just slow going.

Quote
In some cases, a quick fix may be available under the "obsolete" GenMac framework.

Nobody has had any new success (that I have heard about) with GENMAC, for a couple of years now. There may be some older devices that haven't been tried yet, but it seems that GENMAC is missing something that is needed for newer devices. GENMAC is unlikely to get fixed, unless somebody can do some serious hacking, and Willibald Meyer (the author) has expressly forbidden distributing any patched versions of his work. On the other hand, if anybody does come up with a patch that works, we can distribute the patch.

Quote
Many of the other applications are nice too

Applications don't seem to be too much of a problem. The QT project seems to have opened a lot of doors.

Quote
efforts should be geared towards solving the critical issues

Now that is where some disagreement comes in. What are the "critical" issues? You mention two projects, that are being worked on (as high priority) by some of the best OS/2 programmers anywhere. It is slow going because there are not enough people to do the work, and those who are working on the projects need to do other things too.

Then we have the guy who decided that being able to run games is high priority. He seems to have made good progress, for a while, but recently there has been nothing from him. I am not surprised by that, but I do question the wisdom of trying to build a games interface, when we don't have an adequate video driver to be able to use it (a video driver is also in the works, under the Panorama project, now with SNAP merged, but apparently no acceleration planned because nobody knows how to do that).

Quote
I therefore argue that it is important to solve short term critical problems (if easily fixable), and WiFi is such an issue (alongside Flash and Java)

This is another problem. "easily fixable" is something that a user can assume can happen. I have heard that WiFi is likely to be a 6 month project, AFTER the basic wired problems are sorted out. I would guess that we will see the first WiFi support in about a year (unless some big breakthrough happens - might be sooner -  or we lose the guy who is doing it - might be never). ACPI is progressing nicely, now that there is a new team working on it. however, it looks like the easy parts are done, and the more complicated parts are left to do. You mention Fn keys. IMO those are not as important as getting devices to properly configure. It is most frustrating when you know that a device isn't working, because it doesn't get an IRQ, but there is nothing that you (as a user) can do about it, other than report the problem with the proper supporting information. But that too is part of the problem (and I am as guilty as anybody else). Problems must be reported, or they won't get fixed. Of course, part of reporting a problem, is testing potential fixes, and reporting the results accurately, and in a timely manner. That, in turn, means that the average OS/2 eCS user needs to become a bit more technical, so they can report problems properly. It is not helpful to report that widget xyz "doesn't work". You need to explain what it does, or does not, do, and how to make it fail, so somebody who can do something about t has half a chance to be able to recreate the problem. You can't fix something that works, and if you don't know how to make it fail, and what to look for, you have nothing to fix (or, you can spend days trying to figure it out - time that could be put to better use).

The bottom line is, that the users need to step up to the plate, and help out as much as they can. Find a project to work with, and do what you can to help out. Of course, the developers also need to help the users by suggesting ways to test things, and how to report what they need to know to recreate problems. It is a two way street.

From an earlier post, from one of the guys who does a LOT of the porting work:

Quote
One of the things the OS/2 community really SUCKS at is providing feedback....

This needs to change, quickly. Feedback can be both positive, and negative. Positive feedback needs to be short, and to the point. Negative feedback requires usable information so the problems can be fixed.

Overall, the people who are doing the work, are doing a great job. They need to be thanked. There are not enough of them, and they are overworked, so they can use some help. Just try to be sure to help, and not hinder, them (this may also be part of the problem - people are afraid to "help" in the wrong way).

116
Networking / Re: GEN MAC news?
« on: 2012.03.01, 07:37:33 »
Quote
One of the things the OS/2 community really SUCKS at is providing feedback....

Well, yes, but somebody else will do it...

Quote
I wonder what  Mensys or Ecomstation are thinking about (not solving the problem will make useless all their other great work...).

I know that Mensys is very aware of the problem, but they can't do it all either. The ball got dropped when Willibald pulled support for GENMAC, and it was far too long before Mensys picked it up (but somebody else could have done it sooner, if they were interested). On the other hand, I have heard that the eCS community didn't have the tools that are required to do the job, until about the same time that Mensys got the ball rolling, so starting sooner may not have helped anyway. I have done what I can do to try to prolong the usefulness of GENMAC, but I don't know enough about it to fix problems with the driver. All I can do is guess about what might work, and help others install what should be the right parts to make it work. Unfortunately, it seems that GENMAC is just not capable of running modern NICs (especially wireless NICs). Problems with ACPI (some of which are fixed with the latest version) don't help either (in fact, that is, apparently, where the emphasis was placed recently). For Mensys it is a balancing act, and they need to make decisions about what comes next. There are a limited number of programmers who are willing, and capable, so they need to be used to the best advantage (not to mention a restricted budget). It is a tough job to make those decisions, and I don't envy them. Somebody will always be upset, and second guessing the decisions won't help anybody.

Quote
We are pointing out a problem which must be solved, by a workaround or a real solution.

The workaround was GENMAC. The real solution is Multimac. Unfortunately, it seems that there is a gap in coverage that we will need to live with. GENMAC is past the end of life, and Multimac is not ready to do general device support.

FWIW, there are still devices available that you can plug into a working wired interface, and connect to WiFi with them. I have two such devices, that are quite old now, but they still work well, even though they are G devices, not N (just another workaround).

117
Networking / Re: GEN MAC news?
« on: 2012.02.29, 05:54:33 »
Quote
Updating or rethinking genmac is necessary.

It doesn't matter how necessary it is, it looks like it will never happen. Willibald Meyer (the author of GENMAC) has steadfastly refused to release his work, so we have no starting point, other than to start over. The Multimac project is that restart point, but far too few people are working on the project, and those who are working on it have other things to do. Meanwhile, we are falling badly behind, and GENMAC seems to have run out of steam.

We don't need rainy days. We need more, competent, programmers who are willing to do some serious work, for very little, if any, compensation (other than the eternal gratitude of eCS users). It would also help, if those who can't program, would help in other ways. Much testing needs to be done, and work on documentation (including translation) can be done by those who can't program. Monetary donations to those who do the work are also appreciated.

118
Applications / Re: odin 0.8.3
« on: 2012.02.26, 18:33:12 »
Quote
It seems to me that it would be desirable if the newly released versions of odin would contain, or at the very least be accompanied by, easily installed versions of the required latest dependencies.

There has been a LOT of discussion about using a *NIX type of installer (see the RPM/YUM thread). Believe me, you really don't want multiple copies of basic system DLLs, or things like ODIN, at various levels, on your system, in different places. That is a phenomenon known as "DLL HELL". It is bad enough as it is since we need to maintain multiple versions of various DLLs. The only reasonable way to be able to manage that nonsense is to keep them all in one place, and have only one copy of each. The eComStation group has decided to put those things into the \eCS\DLL directory (which makes sense). Since the older versions of OS/2 don't have that directory, the files should go into \OS2\DLL. Any other copies of system DLLs  (GCC Libc) that exist anywhere else should be removed, or moved to one of those locations. There is nothing worse than trying to figure out why a program quit working, only to find that some other program has added a DLL somewhere where it isn't supposed to be (like in the ODIN directory structure). We still have the problem where a defective DLL gets produced (like the original Libc064.dll), and that is made worse by the forwarder DLLs that link calls to earlier versions to the defective one. That breaks a lot of things, but it is not as difficult to figure out what to back out, when it happens.

True, the whole thing is not "perfect", but nobody has yet come up with a better solution. It would help if those who have been packaging the GCC, and Libc, dlls into WarpIn packages would do it consistently. The current packages overlap, and conflict with each other sometimes, and that doesn't make it easy for those who package other things in WarpIn to be able to verify that prereqs are installed, or not.

You also need to remember, that these large install packages eat internet bandwidth, for those who are limited, and are pretty well unusable by those who are stuck with dial up connections. No package should ever contain anything except the package itself. Your proposal to just add the "required parts" adds large amounts of data to these downloads, that should not be necessary, especially if the user already has the required packages.

Quote
The warpin package manager seems to work pretty well when it works.

It does, but many people who package things with WarpIn do not do it properly. For instance. The ClamAV 0.97.3 package does not create the ClamD icon properly. It leaves out the program name in the icon. It also just adds a new UNIXROOT to your CONFIG.SYS, which can be deadly, and is completely unnecessary, since ClamAV 0.97.3 doesn't even use UNIXROOT.  ClamAVGUI does not make use of the information available about where ClamAV gets installed (when installed by WarpIn). One that does work pretty well, is the PMMail installer, but it isn't perfect either. Another problem with WarpIn is that some people just don't want to use it. That is okay , but in most cases, they had better know what they are doing, or they can create problems for themselves. The same is true of RPM/YUM, but RPM/YUM will create it's own problems for you (when I first installed it, SAMBA quit working because RPM/YUM decided that UNIXROOT should point to a different place). You can extract the files from either packager, and put them where you want them. Then, you can spend more hours figuring out why they don't work. At least extracting files from a WarpIn archive is as simple as extracting them from a ZIP file (use WPIView). When you try to extract things from an RPM package, you may find a lot of stuff that has nothing to do with the part that you want, then you need to sort that mess out.

I expect that we will end up using multiple installers, eventually (actually, we already do). RPM/YUM needs a LOT of work to make it user friendly, but it seems that those who are porting Linux software seem to think it cuts down on the work required to do the ports (it probably does, but it sure increases the work required by users). It has been my experience, that most Linux ports are not useful anyway, but others probably disagree. If those who are working on RPM/YUM would put their time toward fixing more basic problems, we would all be better off.

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

I don't know about "much higher", but AHCI seems to be good, when it works.

Quote
I found that the OS2AHCI.ADD file was never copied to the boot drive in the C:\OS2\BOOT folder.

Yeah, there is a bug in the installer. It should be fixed in the upcoming 2.11 version, from what I understand.

Quote
So, what is my path forward to get AHCI functional? Second, is the AHCI speed enough to warrant all this work (I know that I have not spent much time on this yet so I can not complain, really. :-) )?

It is pretty simple. Once you have the OS2AHCI.ADD file where it is supposed to be, these two lines control what happens:
Code: [Select]
BASEDEV=OS2AHCI.ADD <add parameters here>
BASEDEV=DANIS506.ADD /!BIOS

If OS2AHCI loads first, and it can find devices that it can control, it takes the device, and controls them. DaniS506.ADD takes any older IDE type devices that OS2AHCI doesn't want (if any - you do need one of the very latest versions of Danis506 - comes with eCS 2.1). Reverse the two, and DaniS506 will take the devices it can control, and OS2AHCI gets whatever is left, that it can control (if any). If you read the docs (<boot drive>:\ecs\DOC\OS2AHCI\README) you should be able to figure it out.

Of course, that doesn't tell the whole story. On my Lenovo ThinkPad T510, AHCI works great with /s /r /n. The BIOS must be set for AHCI for it to work in AHCI mode. On my Asus M3A78-EM, with quad core Phenom processor, and Maxtor 6L250S0 disk, The BIOS can be set for not AHCI (whatever it says), and the AHCI driver will still work. If it is set for AHCI, it will work only in AHCI mode. Actually, AHCI works for a few minutes, in either mode, then it traps. I have a newer disk to put into it, and I am hoping that that will fix the problem (but I wouldn't be surprised if it doesn't). Currently, I am using Danis506$ on the M3A78-EM, but part of that decision is because I have WinXp on it.

One other consideration: If you have a windows, older than VISTA installed, you will need to jump through hoops to find, and install, the AHCI driver. Then, depending on how the AHCI BIOS setting works, you may need to change it in the BIOS at each boot, if all systems can't use AHCI. Some machines will switch modes automatically (like the M3A78-EM), while others will only work in one mode at a time (like the T510), without changing the BIOS setting.

120
Networking / Re: GEN MAC news?
« on: 2012.02.21, 07:11:33 »
Quote
Any news about?

http://svn.netlabs.org/genmac/ticket/8

I doubt if you will get any response there. That project was opened a couple of years ago, when there was a slight chance that Willibald Meyer might open source GENMAC. He never did, so that project is dead.

Pages: 1 ... 6 7 [8] 9 10 ... 28