Hi Shaun,
Well, fortunately for us Windows user account management has largely
improved thanks to the fact Mac OS and Linux have been giving them some
serious competition over the last few years. As a result with User
Account Control and new user management systems Microsoft has been
trying to get developers and users into using the home directory rather
than sticking files in other places where they don't belong. For a Linux
user like myself saving settings, personal files, and even installing
programs locally in my home directory is nothing new. However, for
Windows users who have not had that experience it is going to be a bit
of a learning curve figuring out what goes in home and what belongs in
system directories.
As for using old languages I think we've talked that issue to death. It
comes down to personal preference, and some developers simply have no
desire to learn a new language and new techniques to become fully
Windows 7 and UAC compliant. In some cases I can understand the reasons
behind the developer's decision even if I don't agree with it from an
end user perspective.
For example, even if Jim Kitchen started learning Visual Basic 2010
tomorrow it would be a massive undertaking to convert all of his text to
speech games to Visual Basic 2010. There are too many changes between VB
6 and VB 2010 to easily convert them. As a result all of his games would
require a rewrite from scratch which is a huge undertaking. Even though
as an end user I'd love to see this happen the reality is its too much
work to be practical for Jim, and I can't blame him for not wanting to
do this when he is still running XP as well as a number of other VI users.
A lot of audio game developers are in the same situation, and we have to
ask ourselves if the work involved is worth the effort in upgrading
everything from scratch. A lot of developers say no, because the work
involved is too much to be practical for them.
The advantage that new developers have, such as myself, is that I didn't
have a bunch of titles written in VB 6 etc when I got started so I had a
lot more of a choice what language or languages to use. Plus I already
had C and C++ in college and was in the process of upgrading my skills
to C# and VB .NET which meant I already knew the newer languages and
didn't have to learn it after the fact. That makes a big difference when
we are talking about upgrading to Windows 7 or Windows 8 from a
programming standpoint.
As to your comments of Windows 8 those are way off. Sapi 5.5 is Sapi 5
compatible, is a standard Windows COM component, so I don't know where
you get your information that it doesn't work. I've done some early
testing with my own games and Sapi 5.5 is not that much different from
5.4 from a programming standpoint.
Now, it is true that accesssibility has changed in Windows 8 but its
nothing new. Windows 7 uses both MSAA and the newer Microsoft UI
Automation API. the only difference here with Windows 8 is that
Microsoft UI Automation is now the default accessibility framework for
Windows and developers are encurraged to use it rather than MSAA on
Windows 8. This requires a fairly recent screen reader to use it, but
people running Jaws 13, WindowEyes 7.5, etc already have basic support
for Microsoft UI Automation as screen reader developers are switching
over to it anyway for Windows 7, and will carry over to Windows 8.
Cheers!
On 3/10/2012 2:37 PM, shaun everiss wrote:
I aggree, if windows security ran like linux security we wouldn't have
a problem.
Most stuff works and thats fine.
I have not experimented, but I guess I could try the home folder rout
though since windows never natively handled it right before its going
to be a heck of a learning curve.
As it is ie as well to the protections it has in xp has a protected
mode that does not impact accessability software or at least nvda
anyway.
Then there is the performance lag, its a bit of a non reason to have
it enabled.
Its why in a lot of oses stuff like visuals and a lot of security is
disabled, well all that causes issues because ms have never writen
anything, ok besides msse maybe in the security department that
doesn't have some issue or other.
Dark, seriously the win7 interface is not that bad, takes a bit to
learn, the win8 interface now thats a major jump but I'm sure I will
grow to like it.
Ofcause it doesn't help that game devs though on the way to changing
have been for the last 10 years have been using old languages, vb6 and
older for example for their games.
Dotnet and c++ programming is still new for us really, with only a few
titles round the place.
Hopefully bgt will eaven that score some.
However with that all going for it, we still have a large persentage
of our games, in fact bat 1-2% of our games that are converted most
are still using old code.
Some will change but not all.
Some can't be bothered and some have other reasons not to upgrade.
And then there is the effort to transfer, most stuff by mainstream
standards is quite simple and therefore I'd imagion the willingness to
port just for a new os may not be there for maybe the smaller devs,
I'd feel the same.
And it sounds like with win8 in nay case that every old concept of
accessability is out the window, msaa, mirror drivers and it appears
even sapi, as I have had some people online saying sapi on games
doesn't work at all.
So the entire market will change.
The vm seems to be the only way to get games going.
Though since the ms vm will have the same code on it that could become
a security risk for game devs since you could happily share codes even
for hardware because the os id would be the same for the vm unless I
am not getting it right.
One things for sure, we are going to have to radically change
everything and I am not sure if we can or at least can fast.
---
Gamers mailing list __ [email protected]
If you want to leave the list, send E-mail to [email protected].
You can make changes or update your subscription via the web, at
http://mail.audyssey.org/mailman/listinfo/gamers_audyssey.org.
All messages are archived and can be searched and read at
http://www.mail-archive.com/[email protected].
If you have any questions or concerns regarding the management of the list,
please send E-mail to [email protected].
