eCS 2.0 is out, but Flash 10 support (still in preview) is not working anymore due to licensing problems.
I've heard so many people complaining about this on the mailing lists, so I'm adding this post to make the workaround a little bit easier to spot on the net.
The solution is simple: copy your registration file over from eCS 1.2. The file is called ecsreg.ini.
...and please Mensys, give us another beta release (solving SMP problems would be best, but we can do without for a while).
2010/08/23
2008/12/22
How to find Software Subscription Services downloads
"Software Subcription Services" (SSS) is the name of the subscription that gives you access to the latest eComStation developments, both in terms of the base OS and the software that accompanies it.
If you subscribe to SSS, you have access to a lot of downloadable items, but it is not always easy to access them.
Here is a short tutorial with screenshots on how to access the downloads:
First of all, point your browser to the Mensys homepage.
You'll see a page like this:
Click on the highlighted link (Login) and insert your credentials, then click on the "Login" button:
You will be presented with a list of choices; click on the "Downloads" link:
Now you see a page with a list of the products you have bought that entitle you to download something. You can see mine here:
You are looking for the downloads provided by your Software Subscription Services, so you'll click on the corresponding link (red circled in the above screenshot).
You will finally be presented with the list of available downloads.
Please note two things about this listing:
- links in this list are dynamically generated, so they will expire after some time
- the link that leads to the "BetaZone" will give you more downloads with respect to accessing the BetaZone from the eComStation site, so I'd suggest giving it a try
If you subscribe to SSS, you have access to a lot of downloadable items, but it is not always easy to access them.
Here is a short tutorial with screenshots on how to access the downloads:
First of all, point your browser to the Mensys homepage.
You'll see a page like this:
Click on the highlighted link (Login) and insert your credentials, then click on the "Login" button:
You will be presented with a list of choices; click on the "Downloads" link:
Now you see a page with a list of the products you have bought that entitle you to download something. You can see mine here:
You are looking for the downloads provided by your Software Subscription Services, so you'll click on the corresponding link (red circled in the above screenshot).
You will finally be presented with the list of available downloads.
Please note two things about this listing:
- links in this list are dynamically generated, so they will expire after some time
- the link that leads to the "BetaZone" will give you more downloads with respect to accessing the BetaZone from the eComStation site, so I'd suggest giving it a try
2008/11/26
Does anyone know where does the little "Scanning Audiofile" box comes from?
This is a useful post I recently saw on the eCS mailing list.
Did you ever notice that, when you open a folder full of multimedia files (e.g. MP3s or OGGs), you get a little box saying "Scanning audiofile" for a few seconds?
I never had any grief with it, but here's how to disable it if you need or want it:
Here's a little how-to (courtesy of mspittel):
Did you ever notice that, when you open a folder full of multimedia files (e.g. MP3s or OGGs), you get a little box saying "Scanning audiofile" for a few seconds?
I never had any grief with it, but here's how to disable it if you need or want it:
Read ?:\MMOS2\MEDIAFLD\DOC\mediafldr.inf, section "Hidden features",
"Disable audio file checking".
Here's a little how-to (courtesy of mspittel):
1) Open C:\OS2\OS2.INI with INIEDIT and set "Settings - Safe mode" to OFF
2) Select CWMM in the "Applications" (left) pane
3) Select "Key - New Key" from the menus and create
mmClsDontCheckDrive (be careful with capitalization of this key)
4) Select the newly created key in the Keys - CWMM (right) pane
5) Select "Key - Edit key" from the menus
6) Type in abcdefghijklmnopqrstuvwxyz in the edit window
7) Click the "Write changes to disk" icon (the yellow one just to the
left of the green Cancel door in the right down corner).
8) Exit INIEDIT and you are done.
2008/07/19
Dynamically setting environment variables for a program without a .cmd script?
Say you need to set a few environment variables for program x. You don't want to clutter config.sys with more environment variables, and you don't want to reboot.
You also don't want to use a .cmd script to start the program. You'd like to simply have a normal program object that starts the program with a modified environment.
You may know that Rich Walsh' DragText program gives you, as a free bonus, the enhanced DTProgram class, which enhances your program objects with an "environment" page that does exactly this (among other nice things).
What you probably don't know is that this functionality is not in DragText, but it is in OS/2 (eCS) right out of the box. What DTProgram gives you is a nice user interface for this functionality.
So, how do you use it without DragText?
A post from Paul Ratcliffe in the Warpin-User mailing list sheds light on this:
You will need some rexx skills to make use of this suggestion, but it is indeed really nice to know!
You also don't want to use a .cmd script to start the program. You'd like to simply have a normal program object that starts the program with a modified environment.
You may know that Rich Walsh' DragText program gives you, as a free bonus, the enhanced DTProgram class, which enhances your program objects with an "environment" page that does exactly this (among other nice things).
What you probably don't know is that this functionality is not in DragText, but it is in OS/2 (eCS) right out of the box. What DTProgram gives you is a nice user interface for this functionality.
So, how do you use it without DragText?
A post from Paul Ratcliffe in the Warpin-User mailing list sheds light on this:
If you are creating a program object, then you can include the
environment variable(s) as part of the setup string e.g.
CREATEOBJECT="WPProgram|My Program|<WP_DESKTOP>|EXENAME=$(1)\whatever.exe;SET xxx=yyy;OBJECTID=<WP_MYPROGRAM>;"
Obviously you need to customize this for your own title, .EXE name,
object ID, folder location and environment variables.
You will need some rexx skills to make use of this suggestion, but it is indeed really nice to know!
2008/06/11
My disk is thrashing every 4-5 minutes and the system is blocked for a few seconds each time
Have you ever had this happen?
I was lately remembered about this (still unfixed) problem a few days ago, and I guess this is a problem many people are experiencing, but not everyone knows how to solve.
But first a little background:
The system INI files are updated very frequently during the normal WPS operation. Since they are critical to the correct operation of the WPS, the system consolidates all the mods to disk every 4-5 minutes. When it does this, the actual amount of work depends on the size of the INIs, how much they are fragmented, how many mods are there to consolidate.
Sometimes around Warp 4 someone at IBM decided it was more secure to make the OS write to the system INI files in write-through mode. What this means is that writes to the system INI files does not go into the file system cache, but instead go directly to disk.
This may seem a good idea at first sight, but in fact it isn't so. If you think about it, this means the system doesn't optimize writes (i.e. pages that are updated, but whose content is not changed, are written nonetheless to disk), and it also generally means that the system will spend more time writing to INIs, so that the risk of a power interruption during the writes is more likely instead of less likely. Also think this: if power is interrupted while the mods are in cache but are still not written to disk, you lose the last changes you made in the WPS. But if power is interrupted while the mods are being written to disk, you get corrupted INIs and you have to restore from a backup. So it is best to minimize the time dedicated to writing the INIs to disk, instead of forcing a timely write like it was done. Using the write-back cache is the best method to ensure both data consistency and that the INIs on disk are as much up-to-date as possible.
What happens to a lot of users (and I'm sure everyone hits it sooner or later) is that this non-cached process of writing INIs back to disk starts to become a nuisance when some kind of threshold is crossed (presumably on the size of the INIs). The system suddenly blocks while the disk is thrashing, it doesn't accept input for several seconds, than it starts behaving normal for another 4-5 minutes. The it goes through the whole process again, and again, and again... you get the idea. Very irritating.
Peter Fitzsimmons found a way to (securely) patch the system so that it returns to the old behavior of using write-back caching even on INI writes. Later, Carsten Arnold packaged Peter's patch so that it can be easily installed and uninstalled.
You find it here. Note that you need a reboot after applying this.
Also note that, since this package patches PMMERGE.DLL, which is a frequently updated DLL, you might need to reapply this patch from time to time.
I have been using this patch since a lot of years, and I have never had problems with it.
I was lately remembered about this (still unfixed) problem a few days ago, and I guess this is a problem many people are experiencing, but not everyone knows how to solve.
But first a little background:
The system INI files are updated very frequently during the normal WPS operation. Since they are critical to the correct operation of the WPS, the system consolidates all the mods to disk every 4-5 minutes. When it does this, the actual amount of work depends on the size of the INIs, how much they are fragmented, how many mods are there to consolidate.
Sometimes around Warp 4 someone at IBM decided it was more secure to make the OS write to the system INI files in write-through mode. What this means is that writes to the system INI files does not go into the file system cache, but instead go directly to disk.
This may seem a good idea at first sight, but in fact it isn't so. If you think about it, this means the system doesn't optimize writes (i.e. pages that are updated, but whose content is not changed, are written nonetheless to disk), and it also generally means that the system will spend more time writing to INIs, so that the risk of a power interruption during the writes is more likely instead of less likely. Also think this: if power is interrupted while the mods are in cache but are still not written to disk, you lose the last changes you made in the WPS. But if power is interrupted while the mods are being written to disk, you get corrupted INIs and you have to restore from a backup. So it is best to minimize the time dedicated to writing the INIs to disk, instead of forcing a timely write like it was done. Using the write-back cache is the best method to ensure both data consistency and that the INIs on disk are as much up-to-date as possible.
What happens to a lot of users (and I'm sure everyone hits it sooner or later) is that this non-cached process of writing INIs back to disk starts to become a nuisance when some kind of threshold is crossed (presumably on the size of the INIs). The system suddenly blocks while the disk is thrashing, it doesn't accept input for several seconds, than it starts behaving normal for another 4-5 minutes. The it goes through the whole process again, and again, and again... you get the idea. Very irritating.
Peter Fitzsimmons found a way to (securely) patch the system so that it returns to the old behavior of using write-back caching even on INI writes. Later, Carsten Arnold packaged Peter's patch so that it can be easily installed and uninstalled.
You find it here. Note that you need a reboot after applying this.
Also note that, since this package patches PMMERGE.DLL, which is a frequently updated DLL, you might need to reapply this patch from time to time.
I have been using this patch since a lot of years, and I have never had problems with it.
2008/05/06
Java 1.5x on eCS ???
OS/2 and eCS have a few choices when it comes to running Java apps.
You can use the IBM JRE, the GoldenCode JRE, or the Innotek JRE. Unfortunately, all of these choices are far behind the state of the art when compared to the reference implementation: Sun's JRE. Innotek's JRE is the most advanced of the three, being at 1.4.2_09.
Innotek has another interesting property: it is not a port of Sun's JRE, rather it is an adaptation of the Odin toolkit (Odin is OS/2's WINE) able to run a particular incarnation of the Windows JRE.
Michael Holzapfel experimented with a few more recent JREs, and found out that you can actually run Windows' JRE v1.5.0_07 using Innotek's Odin toolkit.
There is a thread on OS2world.com regarding applications that run with this "hacked" JRE.
You can use the IBM JRE, the GoldenCode JRE, or the Innotek JRE. Unfortunately, all of these choices are far behind the state of the art when compared to the reference implementation: Sun's JRE. Innotek's JRE is the most advanced of the three, being at 1.4.2_09.
Innotek has another interesting property: it is not a port of Sun's JRE, rather it is an adaptation of the Odin toolkit (Odin is OS/2's WINE) able to run a particular incarnation of the Windows JRE.
Michael Holzapfel experimented with a few more recent JREs, and found out that you can actually run Windows' JRE v1.5.0_07 using Innotek's Odin toolkit.
There is a thread on OS2world.com regarding applications that run with this "hacked" JRE.
2008/04/30
Firefox and Thunderbird together
One of the most frequently asked questions is "why doesn't Thunderbird start when I have Firefox open?" (you can exchange Firefox and Thunderbird in the question).
The answer is that you should have installed a build of both Firefox and Thunderbird that use exactly the same DLLs, otherwise you most likely won't be able to use them together. What this really means is that the author of the port should have compiled the packages roughly at the same time, using sources that are at the same level.
Obviously, this is not something you are in control of, unless you're able to do your own port. And sometimes you may have a reason to use applications at different levels.
The most straightforward solution is to use the RUN! package by Rich Walsh, which sets up all the environment variables needed to achieve your goal.
You simply copy the run!.exe program to the directory where thunderbird.exe resides, and rename it to something like thunderbird!lk.exe. You then change your program object to point to thunderbird!lk.exe instead of the plain tunderbird.exe and you're done.
You can apply this fix to firefox.exe too, just remember you don't need to apply it to BOTH: just one of them is enough.
The answer is that you should have installed a build of both Firefox and Thunderbird that use exactly the same DLLs, otherwise you most likely won't be able to use them together. What this really means is that the author of the port should have compiled the packages roughly at the same time, using sources that are at the same level.
Obviously, this is not something you are in control of, unless you're able to do your own port. And sometimes you may have a reason to use applications at different levels.
The most straightforward solution is to use the RUN! package by Rich Walsh, which sets up all the environment variables needed to achieve your goal.
You simply copy the run!.exe program to the directory where thunderbird.exe resides, and rename it to something like thunderbird!lk.exe. You then change your program object to point to thunderbird!lk.exe instead of the plain tunderbird.exe and you're done.
You can apply this fix to firefox.exe too, just remember you don't need to apply it to BOTH: just one of them is enough.
Subscribe to:
Posts (Atom)