Olusegun, and all other "dreamers".
First of all, let me second much of what Tom already have told you.
Window-Eyes, as well as a number of other software you have come to rely
on through the years, have been developed to run on Windows machines.
Windows machines have their way, or ways, to do things. An Android,
Linux, IOS, or whatever other OS you might fancy, they all will do
things their own ways.
To hope for a Windows Screen Reader to be ported into Android, just
because you need thing on the screen read out to you, would be a
daydream deemed to never happen. The car you use every day, is
manufactured for running on the roads. it can run on any road, but it
has to be in contact with the underlaying surface, that is the pavement
of the road. The airplane you travelled by, last month when going for
your vacation, is designed to run in the air. The ship that brought your
new cellphone in from Asia, well it is designed to float on water. When
did you travel by airplane or ship, going down the highway outside your
door? They are all made to fill a given purpose, in a given environment.
True, some enventive persons have attempted to make a "one-for-all"
transportation facility; which could take you on land, in the air, and
cross the sea. But why have we never got one of them in our yard?
Because they are neither practical, nor functional. Because they are
even worse than all the hazzle of today's changing from one means of
transportation to the other.
The few times we see things that are told to be cross-platformed in the
electronic world, it only works this well. And certain features simply
won't be portable, due to the whole layout and construction of the
underlaying OS. A Windows program, for instance, will never run under
old DOS, due to the fact that Windows has a graphical interface, DOS did
not.
Olusegun, you said you don't have programming skills. I could almost
tell, due to your dreams. Let me then take a couple of your minutes, to
introduce you to but a few of the rooms in the maze-like programming hotel.
A program code, is much like a recipe. It holds a number of lines, each
giving an instruction for the computer to carry out a certain task. This
code has to be readable for humans, or you would have some kind of a
time in trouble-shooting it. That is why, most programmers make use of
what is known as a programming language. These are kind of
interpretters, between you as a human, and the 0's and 1's of the
computer's inside.
You might have heard someone speak German, another time you heard a
person speak Greek. None of them were comprehendable to you, unless you
happen to speak their actual language. They even differ rather, from the
English language. So does Spanish and French.Likewise inside the
programming world. One programming language is rather different from
another. And sometimes you can instruct one language to perform one
task, and the same cannot be performed in the other programming environment.
To give you one example of such differences, which I ran into recently,
in the attempt to import some of my code from one programming language
(VBS) into another environment (AutoHotKey, or AHK).
In VBS, we have an instruction named EVal, which will calculate a
mathematical expression. You could for instance say:
EVal( 2 +3 *4)
When running this code, it will perform the following activity, inside
the computer:
Add 2 plus 3; gives us 5.
Multiply the 5, with 4; and we get the result of 20.
Now, what happens if we ask Autohotkey to perform the same calculation?
That is, it does not even have a single instruction for a calculation,
but with some triggering we may be able to have it calculate. Problem
is, that Autohotkey calculates from right to left, and our expression:
2 +3 *4
will be handled as follows:
Take 4, multiply with 3; and you get 12.
Take the 12, and add 2; and the final result goes into 14.
Really, if the rest of our code now has to rely on the result of this
simple calculation, you who are a business person, soon can see the
tremendous difference we would come out with. Or, would you think that
it doesn't matter if we get 14, or 20, as our end result?
OK, this was - believe me - a VERY TINY and insignificant example of
what happens when we attempt to port one single line of coding, from one
environment to another. And yes, it is all on a Windows machine. What
issues we could have run into when trying to run similar pieces of code
on other platforms, I will let everyone's imagination come up with.
I have been a programmer for some three decades, have learned a couple
of languages, and am currently in the process of investigating a bit on
further alternatives for my projects. Even so, I see that you cannot
perform everything in one environment, but often are much better off, in
letting each environment do what it is best at. Yet i can assure
everyone, that such a thing as simply taking the code from one
environment, and introducing it into another; well, that has been the
dream of all programmers out there, for several decades. Neither can it
be done electronically, or automatically; nor can it be done very easily
by a human. And again, I am just talking on one and same platform. To
migrate any code from a Windows machine to an Android device; I am not
sure if it even is fully possible. But of course, feel free to drive
your car into the lake, give full gas, and hope to reach the other side
in half an hour. :)
As Tom pointed out, the best deal would be to look at the behavior of
one product, under its rightful environment, and then try to "imitate"
the behavior with your fresh coding directly on a device under the other
environment. To the user it might seem and feel much the same, but it
definitely won't be, under the hood. Why is that so?
Once you have finished writing, troubleshooting and bug-fixing your
code, you will "compile" it. Let's compare that to the baker, who first
mix all the ingrediences for his bread, let it sit for a while, and now
puts it into the oven. Once the bread comes out, you cannot - and never
will be able to - extract the milk, yease, flavor, and sugar. It will
not be possible for you to pick out the grains, even the whole ones,
from the bread - and spread it on your field, hoping for some crops next
fall. It is baked, and baked it will stay.
Same goes with your compiled code. you might be able to tell what "is in
it", or that is, what it performs. But you will not be able to reproduce
the code, based on the compiled .EXE file. If I took your bread to a
lab, and had them analyze it carefully, I might be able to bake
something that comes close. But unless you let me have the recipe, I
will never be able to learn the full secret of your tasty loaf. Again,
if anyone spend numerous hours on observing, analyzing and
re-engineering the performance of Window-Eyes, they might be able to
construct something that has a similar look and functionality. But
unless they can get the actual code from VFO, they never will be able to
come up with a re-initiated Window-Eyes.
And, how likely is it that VFO is going to let anyone have the code?
Well, how likely is it that VFO even bothers to look at the code? The
day they decide to give their screen reader, be it Jaws or some totally
new product, a real brush - the best thing they can do is to start all
from scratch. Attempting to read through the tens of thousands of lines
the code for a screen reader must consist of, trying to understand and
comprehend what the former programmer has had in mind - why they did
this, how come they did it this way, what made the necessarity for the
code to look such a way; Oh, can I tell you from experience, it is just
about hopeless. You often will be far better off, saving yourself tons
of frustration, in observing the behavior of a product, and then write
something imitating, all from scratch.
Does a screen reader really hold all that many lines of coding? Well,
you all have been enjoying apps for your Window-Eyes. Though certain
apps are rather small and simple, holding only a few lines - most of the
apps you have enjoyed holds thousands of lines. A well functioning app
under WinEyes, would likely be anything from 2000 to 10000 lines in
length. And that is only an app! - Now, go ahead and imagine all the
functionality of the screen reader itself.
Will we ever see Window-Eyes coming back to life? I would suggest that
to be far from realistic.
Will we see anyone building a similarly functioning product, with all
its features, layout and "behind-the-scene" performance? If so, their
might be legal issues to the suff. Or have you all forgotten about the
court-case between Jaws and WinEyes a handful years back? Wasn't that
due to the one climing that the other had "stolen" a minor
functionality? What do you think will happen, should anyone try to
"steal" the full-fledged functionality of the screen reader???
If all of this had been bypassed, would it even be possible to have a
WinEyes on an Android, or Apple device? Doubtfully. Especially so, due
to the Android and IOS being all that different in both functionality
and design. Furthermore, you again will run into legal issues, as the
IOS is all that owned by Apple, whereas Noone and yet Everyone seem to
own Android in all its flavors. Both the platforms already have their
screen readers, on Android you even have several choices of such
assistive software.
And for everyone who has tried one of these touch devices, you will know
the feeling is rather different from what you are used to on the
computer. Though we might want same smooth operation as WinEyes gives on
the computer, I am not sure I would be very helped out with a WinEyes on
my cellphone. A sailor doesn't get much help from good tires, no matter
the brand, does he? To him a good compas, and great navigational skills
is of far higher value.
So, please, stop dreaming, and get realistic. I know, you might not have
been aware of the big differences in platforms, but now you have been
made aware.
On 8/21/2017 1:07 AM, Tom Kingston via Talk wrote:
> Olusegun,
> In reference to your previous message, no one has cracked JAWS.
> They're cracking the authorization code scheme. They're not getting
> access to one line of code for the program.
> Regarding Office for Android and iOS? Those programs were not ported.
> The definition of porting a program is to move it from one platform to
> another platform. For lack of a better term, full blown operating
> systems and mobile operating systems are very different platforms.
> Porting a Windows program to Mac or vice versa is one thing, but
> porting a Windows program to any mobile OS isn't going to happen.
> Slimmed down versions of Office were written specifically for Android
> and iOS. Having the code is of course of enormous help, but virtually
> everything works differently on each platform.
> Microsoft has tried to do this in the Visual Studio development
> environment, i.e. supposedly having the ability to write
> cross-platform mobile apps for Windows mobile, Android, and iOS, and
> then be able to test run them on virtual machines. But everyone in the
> programming world agrees that it's a poor substitute to say the least
> as it will often miss bugs that show up on a real Android or iOS
> device. And note that cross platform development is either for full
> blown operating systems or mobile operating systems. There is no do it
> all in one fell swoop option. Of course Windows mobile apps are fine
> because they're being written on their native platform.
> There is also platform independent ways of developing programs, which
> always cause accessibility problems. But these are for Windows, Mac,
> and Linux, not mobile operating systems. Well, they probably do exist
> but don't work. I've seen the discussion a thousand times and the
> answer is always if you want to develop iOS apps do it on a Mac with
> their iOS developer, develop Windows apps on Windows, and if you want
> to develop Android apps it's considerably more complicated because
> there is no parent OS for Android. This is why new mobile apps are
> almost always written for iOS first and slow to emerge on Android. And
> if that's not enough, the open source nature of Android makes it more
> difficult to develop for because virtually every company who uses it
> feels compelled to fiddle with the core operating system, just enough
> to make it harder for developers, i.e. an Android app that works fine
> on a Google device may or may not work just right on any other Android
> device.
> So full blown operating systems and mobile operating systems are two
> different species.
> Regards,
> Tom
>
>
> On 8/20/2017 6:03 PM, Olusegun -- Victory Associates LTD, Inc. via
> Talk wrote:
>> Tom wrote in part:
>>
>> "It's virtually impossible to crack a big low-level program like
>> Window-Eyes. And even if someone could there's no such thing as
>> porting it
>> over to Android."
>>
>> First, I'll give up on Windows before doing the same with Android. With
>> Android being an open source project, I choose to be somewhat optimistic
>> that anything is possible if not now, perhaps before too long.
>>
>> Second, I can SURF the web on my Shiny, Ancient & Modern Android
>> toy! In
>> fact, I'm beginning to do it so much better with great results in
>> Android
>> land than in Windows. Once I grasp a better use of this Android
>> tablet I
>> have here on my desk, all my Windows computers will have their graves
>> dug.
>> I'll stick them in their respective graves as soon as the hard drive on
>> which they reside die naturally. May be that's another five years from
>> today, but it won't make a difference for me. I don't want them to be
>> resuscitable.
>>
>>
>> Third, I wish I were intelligent enough to get into programming!
>> Sadly, I'm
>> not. Else, I shall have attempted to take on the project myself if
>> nothing
>> more, but for experimental purposes.
>>
>> Fourth, Excel, Word and Powerpoint have crept into Android land!
>> These were
>> once exclusively Windows preserves. My haunch is that if these are
>> portable, anything is possible with a screen reader as well. Who
>> knows? V
>> F O could read this and elect to CORNER my thought process by
>> introducing,
>> you guessed it, Shark for Windows--did I say Shark? Sorry, that
>> should have
>> been Jaws, but you get my drift! Sounds silly, but I want you to laugh
>> anyway!!
>>
>> Sincerely,
>> Olusegun
>> Denver, Colorado
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>> _______________________________________________
>> Any views or opinions presented in this email are solely those of the
>> author and do not necessarily represent those of Ai Squared.
>>
>> For membership options, visit
>> http://lists.window-eyes.com/options.cgi/talk-window-eyes.com/tom.kingston%40charter.net.
>> For subscription options, visit
>> http://lists.window-eyes.com/listinfo.cgi/talk-window-eyes.com
>> List archives can be found at
>> http://lists.window-eyes.com/private.cgi/talk-window-eyes.com
>>
> _______________________________________________
> Any views or opinions presented in this email are solely those of the
> author and do not necessarily represent those of Ai Squared.
>
> For membership options, visit
> http://lists.window-eyes.com/options.cgi/talk-window-eyes.com/trailerdavid%40hotmail.com.
> For subscription options, visit
> http://lists.window-eyes.com/listinfo.cgi/talk-window-eyes.com
> List archives can be found at
> http://lists.window-eyes.com/private.cgi/talk-window-eyes.com
> .
>
_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/talk-window-eyes.com/archive%40mail-archive.com.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/talk-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/talk-window-eyes.com
