XP Support (to clarify my earlier posting)


Ahh – A hornet’s nest I see before me!!   Let’s give it a poke <g>.

This posting is in response to the valid comments posted to my blog posting entitled “Windows XP Support” and to clarify the reasons for that posting a little more.

———————

Guys, you are of course correct and I knew that posting this direct from the official Revelation newsletter would provoke some clarification, and for that I am grateful.  However, the key question in this posting was whether your clients are aware of the issues?  At the risk of offending anyone, that point appears to have been missed by those of you commenting thus far.

This blog is read by both developers and users alike.  I think that all Revelation developers know the issues, risks and workarounds for ARev running on modern operating systems but the same is not necessarily true for end users.  Those organisations that have Revelation professionals on staff are relatively OK – so long as those Revelation professionals take control of the IT decision making process and actively avoid the potential issues befalling a lot of ARev systems right now.  I assume that you have put your necks on the block and taken ownership of your systems in such a way.

For those of you who do not wish to fall on your swords –

  1. How have you protected your clients against the potential and growing issues of running RevG and ARev on modern operating systems?
  2. How have you legislated against the Managing Director or another key decision maker deciding to purchase a wiz bang new 64-bit workstation?  Does he or she, really want to mess around with virtual machines, dual operating systems and the like – I don’t.
  3. How do you plan to support your ARev system for a sales team whose manager invests in the latest piece of technology to revolutionise his department, which demands 64-bit processing power and on which they blow next year’s budget on 64-bit machines.
  4. I could go on all day….

We cannot always take full control of our customers and demand what they will or will not use.  Often, sticking with legacy technologies will result in a loss of business because the legacy DOS system will be seen as the odd one out and the one causing the issue.

Could your business afford to lose your ARev system or your biggest client?  The Managing Director is never going to admit that buying a new 64-bit machine was his mistake.  The inevitable conversation is going to result in the ARev developer having made the mistake in not preparing for the inevitable move to a more modern technology.  Likewise for that sales manager who has big plans to modernise his sales team.

Failure to keep up with the times in IT often displays a lack of interest in the technology that has been written, a potential lack of interest in the developer’s client or their business in general and a perceived lack of willingness to keep up with the times and to invest in the future.  I know that this is not necessarily true and that many people love their old ARev systems and “if it isn’t not broke, don’t fix it”, but you can’t get away from the fact that things are only going to get harder.

Personally, I’m quite happy for people to carry on with their ARev systems.  It means that we can take each conversion project as they come along in dribs and drabs, rather than all at once.  As a salesman, it is also nice to have clients panicking (actually, I’m in two minds on that one) and opening cheque books with blank cheques because they are forced into doing something today because they need to work tomorrow.

This is a personal blog that consists of my views only and not necessarily those of Revelation Software.  However, I make no apology for using the official wording.  If I can encourage just one end user to think about the future of their ARev based system and to make a calculated decision in their own time, rather than a hurried, panicked and rushed decision, then my work is done and I will personally sleep more soundly.

I have tried to, and I believe that I have, given people good advice over the last 17 years.  My advice on this subject is to heed the warnings, modernise and make provision for your legacy RevG and ARev systems today.  Leaving it until tomorrow is inevitably going to result in a loss of business in one shape or another.  Maybe it’ll just be that next new sale as you are not GUI or can’t interface to something seamlessly, maybe it will be the loss of a key client to a competitor, or maybe (just maybe) it could sound the death bell for your business and your retirement fund.

Please, please , please if you are still using ARev please look beyond the technology and what you can ‘manage’ to make it run on – Think ahead of tomorrow and put a proper plan in place for your clients to safeguard their future and your own.  FWIW, we are seeing another increase in the number of conversions to ARev32, so more and more people are realising the growing risks and making provision for the future.

Please note that these are my personal comments and that they do not officially represent those of Revelation Software USA, Revelation Software UK or any other official Revelation channel.

Advertisements

Why’s my oinsight.ini file not working????


We recently had a support enquiry because the OInsight.ini file (located under C:\Windows) was not being picked up and the developer was therefore unable to change the Application Manager buttons to display the System Editor ++, rather than the old System Editor.

I’d always understood that the OInsight.ini file that OpenInsight used for these settings and others, was the one in the Windows directory. However, from Windows Vista and Windows 7, things are no longer that simple.

As Carl enlightened me, Vista and Windows 7 implement something called virtual file redirection, which means that the ini file the OpenInsight uses is not the one in C:\Windows – when it asks for the file Windows goes and gets it from the Virtual Store instead. It is Microsoft’s way of trying to stop people using ini files – they don’t like you using the registry these days either!!

Anyway, the *real* ini file that Windows gives to OpenInsight is stored in your user settings folder something like:

C:\Users\[UserName]\AppData\Local\VirtualStore\Windows\oinsight.ini

If you change that ini file, then everything should be fine and OpenInsight will display the right buttons and your other preferences/settings.

For the more technical and those who want to understand all of this in more detail, the following link will be useful:

http://windowsteamblog.com/windows/b/developers/archive/2009/08/04/user-account-control-data-redirection.aspx

Configuring OpenInsight 9.x for 64 bit Machines


In order to run OpenInsight version 9.x on 64-bit versions of Windows, some additional configuration of the default OpenInsight needs to be addressed.  These changes should be made only following a successful installation of OpenInsight.  The guidelines assume that you have a fresh installation of 64-bit Windows (not one of the Home editions) and also a fresh installation of OpenInsight version 9.0 or later. Depending on your chosen User Account Control settings in Windows, these may not all apply to you.

  • 32-Bit Java Runtime
    O4W and CTO both require a Java run time to run.  For compatibility reasons, you should download and install the latest 32-bit which is available from JRE (Java Runtime Environment).
  • Alternative Registry Location
    As well as the operating system’s usual 64-bit registry entries, 64-bit Windows also maintains a separate list of 32-bit registry keys for the purposes of maintaining compatibility with 32-bit applications.  As far as OpenInsight is concerned, these 32-bit registry settings are maintained under the ‘HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\RevSoft’ registry branch and all registry changes for OpenInsight should be completed under this branch.The registry settings for SYSPROG are:
      [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\RevSoft\OECGI2]
    “UserName”=”SYSPROG”
    “UserPassword”=”SYSPROG”
    “ApplicationName”=”SYSPROG”
    “ServerURL”=”localhost”
    “ServerPort”=”8088”
    “ProcedureName”=”RUN_OECGI_REQUEST”
    “EngineName”=””


    The registry is not an area that should be played with lightly and for this reason Revelation have created an updated registry file to assist in the configuration of OECGI2.  The file can be downloaded from the main Revelation web site at http://www.revelation.com/knowledge.nsf/07dbcbabb6b3e379852566f50064cf25/88e6dbc0988dec9385257566007831c5/$FILE/oecgi2%20vista64.reg. This file should be used in place of the OECGI2.reg that ships with OpenInsight 9.0.

Please also be sure to review and follow the OpenInsight 9.0 Workstation Installation Notes that now apply to the installation of OpenInsight on all versions of Windows.

>RCL4.DLL


>

I am still running into developers reporting issues with OpenInsight being left running in the task manager when OpenInsight is closed. This is mostly on Vista machines, but I thought it worthwhile to include another posting here dedicated to this issue. It will not be any surprise to you that this results in some undesirable behaviour. Revelation therefore jumped on this issue very quickly and the latest RCL4.dll file resolves that issue.

>Progress Bar under Vista.


>

http://www.youtube.com/get_player

Run the video above to see the Vista Progress Bar in action.

Well it looks like Sprezzatura’s Progress Bar article is having another run globally. Carl recently gave me a copy of his test form for the bar and I am pleased to confirm that it runs just as well under Vista with the new Vista looking Progress Bars.

The article was first published in SENL volume 4, issue 4 back in March 2007. The full SENL can be found at http://www.sprezzatura.com/senl/senl440307.pdf.