|
PureBytes Links
Trading Reference Links
|
Someone wrote:
> need the patch NOW! Bob Brickey stated several months ago
> that such a patch would be a trival matter to code. He designs
> trading software so I assume that he would know.
Richard Harrisson wrote:
> Why don't we ask our only good Uncle Bob Brickey, if he would
> make us all VERY happy, by providing the solution ??
>
> Thank you Uncle Bob !
>
> {There are about 1000 subscribers on this list . . . if we only
> paid $100-> each that would be say $100.000- which might be near
> right for 10 minutes of Uncle Bob's time.}
Robyn wrote:
> I think that's a great idea <smile>. On my part - I'd be
> willing to pay more than $100 to avoid the aggravation of
> having to change my software - rewrite all my systems -
> indicators - etc.
...and then in another message, asked:
> Finally - some people here have said that you're capable of
> writing a Y2K patch program for these programs. Are you?
Last Friday, I answered:
Yes, although different patches would be required for each version of each
program.
> If so - do you have any interest in doing it? Robyn
Maybe. Others have asked the same question. We are discussing some
considerations. I will post an answer later today.
-------------
We discussed the considerations Friday, but an Internet problem has had us
cutoff from the rest of the world much of the weekend. (The ATI and SciLink
lists have been out of service, because of that.)
As I have said before, the code changes required to fix TradeStation and
SuperCharts year 2000 problems are relatively trivial. I have no inside
information about Omega's situation, but I can imagine their programmers are
buried in TS 5 development, which probably is why they haven't released
fixes yet.
I can understand why many are worried, because like many of you, I have
waited years for simple fixes that have been promised, but never provided.
Even so, the year 2000 situation seems different, because the required
changes are not only simple, but not providing them could dramatically
impact Omega's business.
Anyway, regardless of all that, we took a serious look at what would be
involved in doing the job for them. This is the situation:
1. Different patches would be required for each version and build of each
program fixed. If all the different builds of all the different versions of
each product were fixed, merely obtaining and installing all those programs
would be quite a task in addition to finding and fixing the unique problems
in each. Of course, the project could be limited to specific products,
versions and builds, but that wouldn't solve the problem for everyone.
2. There could be serious consequences (damaged data files, etc.) if someone
attempted to use a patch on a product, version or build it wasn't designed
for.
3. Unlike the case with typical add-on products, the patches would have to
actually modify Omega's executable program files. That rarely is done by
third parties, because most people wouldn't know how, but also because:
a. Software users rarely own the software they use. In most cases, title
remains with the developer. Users merely have licenses to use it.
Executable program file changes in the case we are discussing would involve
modifying something that belongs to Omega. Of course, unlike modifying
hardware the belongs to someone else, the software modifications wouldn't
change anything Omega normally would expect to receive back. Still, there
are potential legal issues.
Omega's software license agreement states "You may not reverse engineer, de-
compile, or disassemble the Software..." It would not be necessary to de-
compile or disassemble the software. That only would be necessary where
someone is unable to read machine language. "Reverse engineer" is a strange
term. I suppose it literally means to engineer backward, to start with
something that has been engineered and to work backward to whatever the
engineers had when they started, which in this case must have been blank
computer screens. I don't know why anyone would want to do that or why
anyone would care if they did. Anyway, it wouldn't be necessary, but poorly
educated people might have all sorts of other ideas about what they think
the term means.
b. While there may or may not be legal liability related to the license
agreement, there is a serious technical issue. There could be serious
problems if there was an attempt to upgrade patched program files. Next
time Omega releases an upgrade, the setup program provided with it will
attempt to upgrade the files Omega previously supplied. If it instead finds
my handiwork, the result would be unpredictable. There might not be any
problem, depending on many things. However, there could be very serious
problems that could be difficult or impossible to undo.
A possible preventative would be reinstall Omega's original program files
before the next upgrade. However, that wouldn't insure there would be no
problem, because Omega might choose to fix year 2000 problems differently
than I did and my changes may have modified data files so they would be
incompatible with Omega's method.
So, though patching any particular version and build of any one product
would be easy, doing that for lots of products, versions and builds would be
a much bigger task, and even after doing all that, there could be nasty
upgrade problems in the future. We wouldn't be willing to assume the
liabilities related to those problems without signed releases from everyone
involved, and knowing the problems that could result, few probably would be
interested.
I continue to believe Omega will fix the problems, because it would be easy
for them to do, and also, because I don't see how they can stay in business
if they don't. If they don't, and everyone is left with dead-end products
and no intention to upgrade anyway, then we would have a different situation
. Then Omega will have acted unreasonably. Then it might make sense to do
the job.
-Bob Brickey
Scientific Approaches
sci@xxxxxxxxxx
|