TED, RE: your analysis of Vertex in post 7051,
Even though you offer the disclaimer that these are only your
opinions, much of that is lost on the reader by the time they get to the end or after your message is repeated on several other threads. You have assumed Vertex is using a "jump" technique by inserting invalid OPcodes into the program and then go on to describe the difficulties with such a method. But if that is NOT what Vertex is doing, the opinions you put forward are still with the investors, potential investors, or even prospective clients in search of a solution.
The invalid OPcode is a good technique where you limit the
amount of code that you overlay within the executing program
to 2 bytes. That certainly is necessary if you don't know
the type of instruction that you are "hooking" as it could
be a two byte instruction. Perhaps if you recognize that
you will only want to insert a jump on a Storage to Storage
instruction you have 6 bytes to utilize, plenty of room for
a Load and BALR combination to take you elsewhere. There
are also more extreme techniques such as SVC subsystem
screening for the LOAD, LINK, ATTACH, and XCTL Supervisor
calls so that a product can have control over an executable
load module in main memory before the program begins
execution. This is currently used by some date simulation
products to replace the Store Clock instruction at execution
time. And there is this tantalizing tidbit from the BMR
website: "If the computer hardware is smart enough to
understand object code, cannot a program imitating it in
many ways do the same? Software interpreters existed
decades ago". And I'm sure there are tricks of the trade
that you and I haven't seen before. Well, at least that I
havent seen anyway.
Now I do know for a fact that Vertex 2000 does not insert
invalid opcodes in the proram to generate program checks. I
simply asked them. Unlike our friends at IVXR who made wild
claims and havent produced any technical details, the folks
at BMR software are quite approachable. I have emailed
several querries off to info@bmrsoftware.com and i have
received back very prompt and very detailed responses. I
have not yet asscertained the true technique used for
'jumping' but I have received a response telling me that
they do not use the method you described.
As for what happens to the bigits when you PACK an
instruction. I assume that Vertex inserts a 'jump' before
the PACK instruction, and then probably does some form of
software emulation of the hardware instructions, so that it
is able to reinsert the correct bigits when it subsequently
unpacks the data.
Most of you reading this are unaware of this fact, but I
know TED personally, in fact I spent 4 years working for him
directly, so this is certainly a case of the wag ever so
delicately trying to tail the dog. I held you in the
highest regard back then and I still have the utmost respect
for you and your opinions. However, I must say that I am a
bit underwhelmed of your treatment of Mr. Bemer and his
work. I agree that a 'cutesy' name such as Bigits doesnt
exactly scream out Rocket Science and Doctorates, perhaps he
just wanted some name recognition after all these years. Do
you recall someone in your past creating a Trace Print
Routine(TPR) module after his own initials? You did know
that didn't you? I know that you typically treat others
with respect and you've probably crossed over that grey area
between fun and games with FBN and the seriousness of y2k,
as well as the fragile nature of some investors who look
single handedly to you as the 'techie' advice for investment
decisions. Please be a bit more sensitive to the potential
damage that you can cause by misinformation based on
assumptions and by belittling someone's efforts at helping
to solve this tremendous problem.
I know that you are a purist who would like to see every
one expand everything to 4 digits. But I'm sure that
budgetary constraints and timing constraints are going to
cause a lot of folks to look for alternatives. Certainly
any solution including complete expansion, may have
drawbacks and by all means point out those drawbacks based
on the facts, but please take off your FBN hat every now and
again and be TEDennis and treat others with the courtesy and
respect that you normally would. Perhaps you may receive
and unsolicited reply or two to some of your concerns.
As for my take on the solution, I'm still trying to come
to terms with the non 'human readable' aspects of the data
after it has been modified. I suppose this situation also
arises in anyone advocating 'program encapsulation'. But I
am a firm believer that solutions without requiring the
source code are possible, are being developed, have been
piloted, and will be used.
Respectfully yours, (as always)
wishing you and yours a white sedona xmas,
tom rusnak (lower case as always)
|
