Ready for all those slow down questions?

benchtestresultsOne of my hottest topics when talking to people is performance.  Everyone wants their systems to run faster and faster, or at least as fast as possible.  So, when a user’s machine suddenly begins to run slower, the support lines usually light up and we need to know the reasons why.

Microsoft have been one of the first organisations to go public on a slowdown that will be introduced as part of updates that they are currently rolling out to just about every Windows machine.  This is a necessary update to address a very serious CPU vulnerability that could leave sensitive data open to access by hackers.  If you and your users are running the latest Windows 10 updates, then you will most likely not notice much of a change.  It’s said that the percentage slowdown on the latest Windows 10 operating system is in the single percentage digits, so somewhere between 1 and 9%.  When we are talking milliseconds, most users will not notice.

However, for people running older Windows 10 versions, Windows 8, Windows 7 and anyone mad enough to still be running older versions of Windows, the performance hit will almost definitely be noticeable, with talk of performance hits of up to 30%.

Now, that IS some significant hit on our valuable time.

RevUS will shortly be pushing out a formal announcement and I’ll share that with my readers.  In the meantime, I feel that it will be very worthwhile for all technical support and account managers who are involved with supporting and managing OI based systems, to read the following articles:

I’d like to thank Mike Ruane for giving me a heads up on this important issue that is sure to have our users emailing and phoning us when their OI based systems begin to run slower.  Naturally, the best advice (as always) is to make sure that your systems are being deployed to properly patched Windows operating systems and that you are running OpenInsight 9.4 or later with the Universal Driver 4.7.2 or later.

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.

Running ARev – Don’t get get caught short on time!!!

With Microsoft having now withdrawn support for Windows XP and more and more workstations being purchased with windows 7, we are seeing ARev users frantically trying to make the next move to keep their systems running on these new operating systems.  Whilst some people fight to find workarounds, others are hastily looking at shortened ARev32 conversion projects.

Don’t get caught out and find yourself explaining why you have not made the move to ARev32 or made alternative provision for the future.  Give me a call or drop me an email to discuss the future of your ARev system before time is against you.

Outlook made me feel 2 inches tall :(

Outlook PST Compact Now routine window.
Outlook PST Compact Now routine window.

The developers amongst you will probably laugh at my stupidity and realise how small I felt over the weekend with my Outlook system, but other users like me that are used to working with OpenInsight’s self optimising database and other simply ‘set and forget’ technologies, this might be a useful posting.

I have been experiencing a number of issues with my laptop over the last few weeks.  The fan was running a lot more than usual, Outlook, Office and a number of other applications (including IE for some reason) were constantly reporting as ‘not responding’.  Then I found that Office wanted to regularly recover and check files and then I began to receive a number of blue screens of death, system memory dumps, etc.

I considered blowing my machine away (I’ve not done this for a few years now), but I asked my support colleagues for some advice first.  Their reply was the usual – check for malware, run another AV check, remove any unwanted files, compress my outlook file, etc.

Now the last of those items got me thinking.  My Outlook .PST file was 6.4Gb and I was having trouble backing it up to removable media sources.  In addition, my Outlook calendar was no longer working.  Furthermore, I deleted over half of my email and still the .PST file remained at 6.4Gb.

I therefore ran the SCNPST application that resides in the Outlook 2007 program folder and after sometime it reported an issue which I opted to have the routine fix for me.  Checking the .PST file, I found that it was still 6.4Gb and reviewing the Outlook menus I found the ‘Data File Management’ option under the ‘File’ menu.  I have no clue why, but I decided to double click on the entry for my main .PST file and a window popped up with a Compact Now button – Oooo Interesting.

With nothing to lose I hit the button and the machine went into a 13 hour long compression.  Not something that you want to begin at 09.00 on a work day and fortunately I was playing around with this on a Saturday morning.  Anyway, 13 hours later my .PST was reduced from 6.4Gb to just 675Mb.

I rebooted the machine and launched Outlook to see if it would still run.  It did, I breathed a sigh of relief and called it a day.

I have used my machine off and on during Sunday and all of Monday in the way that I usually work.  During today I have not heard the fan kick in once, I have had not one ‘not responding message’ and whilst I have not yet run my resource heavy video programs, the machine is running very nicely indeed.

So the lesson for today, is to have your users check their Outlook .PST files on a regular basis (I’m yet to know how 2010 will behave) and compact them.  My experience that was space was being allocated for every received email and that space did not ‘appear’ to be freed up when email was deleted and the file was just needlessly getting more and more bloated.

I should point out, that further research online indicates that I was not alone in running a huge Outlook.pst file and there are plenty of references to both the SCANPST (and SCANOST) utility for fixing issues and the compact utility.  I am not sure how systems behave on Windows XP and the forthcoming Windows 2008, nor with Office 2010 and later because my experiences were on a laptop running Windows 7 Ultimate and Office 2007.  However, this posting outlines the issue and resolution that worked for me.  I am not saying that this will be true for everyone, but it is certainly something worth thinking about if you are an Outlook user with a huge Outlook.pst or Outlook.ost file or where you are having issues like mine above.

I hope that some of you find this useful.

You can also watch my YouTube video related to this posting – Click here.

Application ‘Not Responding’ on Windows 7

Since moving to Windows 7 ultimate I have had occasional instances where some of my applications get flagged up as “Not Responding”.  I have also been asked about this several times over the last few weeks and a formal support request this morning prompted a discussion internally.  As a reminder to myself and for future reference, I thought that I’d write this blog posting.

If the offending application then tries running a long process (one that will run for more than 5 seconds, I believe), Windows 7 gets excited and reports the application as ‘not responding’.  This notification is normally through a discreet note at the top of the window and sometimes a more noticeable message asking whether to close the application or wait.

Fortunately, my OpenInsight 9.2.1 runs very quickly on my Windows 7 laptop and I don’t run into the issue too much.  However, if you (or your clients) are seeing this with your OpenInsight applications please keep the following in mind:

  1. The issue appears to be down to a process that is running (looping) for more than 5 seconds and Microsoft picks this up and flags it as a possible ‘non responding’ program and informs the user accordingly.  Despite the warnings, the process continues and the application usually gets flagged as responding again once the process has finished.  However, if you get the message popup on your screen and you click cancel, Windows 7 will try to terminate the application and this ‘could’ cause data loss or other nastiness.
  2. To manage your user’s expectations, simply make sure they are aware of this Windows 7 behavior and advise them to leave the application to run for a short while.
  3. Make sure that you are using one of the later versions of OpenInsight and the latest Universal Driver.  If configured correctly, this should ensure that your OpenInsight application is running as optimally as possible.  If in doubt, give me a call and book a health check wit hone of the developers.
  4. Most importantly, make sure that you code to address this Windows feature.  In OpenInsight, this can be as simple and easy as using a YIELD( ) within your programs that are likely to take any length of time (more than a few seconds).

Yield ( ) checks for pending events in the Windows event queue and executes them.  It then returns control as soon as the event queue is empty.  All pending events will be executed, including OpenInsight and Windows events.  It is therefore good practice to handle process dependent conditions (such as a CLOSE event0 after a Yield( ) call.

Example syntax for Yield ( ) is:

done = FALSE$
 ReadNext ID Else done = TRUE$
 Until done
 * Allow for an event, such as CLICK
 * Process ID record

Legacy Applications
It is usually best to address this issue within your OpenInsight application and thereby maintain control.  However, for legacy systems there is another (which I would consider a last resort) option which makes use of Microsoft’s Application Compatibility Toolkit.  You can get further details about that by clicking here.

Protecting your sensitive OpenInsight data.

Sometime ago, Kevin Ruane wrote an article on hiding your Linear Hash data from workstations, this prevented direct access to the data inside .LK and .OV files (Revelation’s Linear Hash data files).

At the time, this was just another useful benefit afforded the Universal Driver for users running Revelation based systems. However, in more recent times we have seen many headlines of high profile individuals and organisations loosing client and other sensitive data – headlines that no organisation can afford to deal with and that often lead to lasting damage to the organisation’s reputation.

If that was not reason enough to take data privacy seriously, organisations now have requirements to protect and audit access to data and this is becoming a more and more common request. For instance, compliance with industry security standards like the PCI DSS (Payment Card Industry Data Security Standard) is now a must have for anyone handling credit card information through their online systems or otherwise.

Revelation has published an update to the original article which covers one method to prevent unauthorised access to OpenInsight’s data held inside .LK and .OV files. Working with OpenInsight 9.2+ and the Universal Driver 4.6 over a Windows 2008 Server and Windows 7 workstation environment (so nice and contemporary) this new article details how to use strict NTFS permissions to achieve peace of mind for developers and end-users alike. After all, if your users can not directly read or change .LK and .OV files, you can audit and protect access to the data using controls that are internal to your application.

The full article can be found on at

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:


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: