Home page Home page Home page Home page
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel
By Sprezz | Wednesday 14 April 2021 17:52 | 4 Comments

Like many Revelation consultants, we have a number of clients who continue to use decades old software under new, more modern technologies - specifically AREV32/64. A technology that was meant to provide a transition path to a more modern UI is frequently just used as a way to continue taking advantage of the massive ROI provided by Revelation Software - in this case AREV.

But sometimes, things go wrong. And this week we were bitten by a particularly pernicious bug that we hadn't seen before.

The client reported that suddenly, blank documents were being emailed to their customers rather than the order confirmations that they were expecting. Investigation was relatively easy - isolate the section of the code that creates the files and test this. The section of code in question simply executed a PDISK to redirect printer output to a file, produced the report, then PDISK PRNed to cancel the redirection.

Upon testing, it failed to produce any output, despite reporting that the redirection was successful. Following Occam's Razor we tried to reproduce the issue by issuing a PDISK at TCL, performing a simple LIST report to disk, then doing a PDISK PRN. Surprisingly, no disk file was produced. 

But looking at the subdirectory no file was created.

So we reverted to an older version of the software and tried again - regretfully with the same result. It didn't matter how far back we went, the error persisted. At this point it became obvious that this was not the issue that the client was facing - all had been well until the last upgrade - but it WAS an issue that we were facing in our testing. But our software was a direct copy of their system, so what could it possibly be?

We tried calling SETPTR directly, we tried different filenames and different extensions but to no avail. So it was time to roll out the big guns and deploy PROCMON, the stunningly useful utility from SysInternals available from Process Monitor - Windows Sysinternals | Microsoft Docs. We reproduced the lack of output with PROCMON running and examined the captured output. We filtered the output on process OENGINE.EXE and path containing ZZZZ.txt and saw 6 entries as below :-

The first 4 were as expected, but the last two were strange to say the least. The spaces in our directory path had been replaced with underscores - and strangely, Windows could not find a path with that name.

This provided us with a working theory - so we copied the system to a subdirectory with no spaces in the name and repeated the experiment. This time we saw the results we expected - a file containing output :-

and the PROCMON trace showed no errors

So it would seem that PDISK has been engineered not to work with subdirectories containing spaces in the path. 


  • I would agree, no spaces in the path, as the PDISK code was last updated in 1994. Windows didn't allow spaces in folder names until much later.
    It's a wonder that a program written in 1985 for filesystems that barely had subdirectories, and enforced an 8.3 filename, works 36 years later....

    By Blogger Mike Ruane, At 14 April 2021 at 20:39  

  • Completely agree! The fact that 30 year old code can still run a company is an AMAZING ROI!

    By Blogger Sprezz, At 14 April 2021 at 20:45  

  • Hi guys! I have a similar problem with PDISK and DIRECT_PRINT to file not working. No spaces involved in folder/path/file names. Seems to be Windows 10 related.

    I cloned a client's system to work on my home Windows 10 pro desktop. ARev32, OI 9.4, LH service 4.7.2. Net driver changed to all networks 2 and revparam files removed on the desktop copy.

    PDISK and DIRECT_PRINT to file will create the file but there is no content (zero length) when all is done. Works fine on my Windows 7 pro desktop.

    Anther thing is the ARev32 and OI debug windows always open to a default size and layout.

    Oddly enough I have a Windows 10 Pro VirtualBox VM that the clone works properly on. The only difference is the VM is still on Windows 10 1909 and my desktop is at 21H1. However if I update the VM to 21H1 PDISK still works. Windows size and layout persist between session.

    However if I do a fresh install of Windows 10 pro both 1909 and 21H1 the PDISK and DIRECT_PRINT to file fail and windows size and layout still default.

    Perhaps there is some setting I'm overlooking in Windows. The VM Windows are running the stock virus scanner and firewall. Disabling these makes no difference.

    Any thoughts?

    By Blogger Warren Auyong, At 18 August 2021 at 21:02  

  • Sounds like permission issues? Have you tried running procmon?

    By Blogger Sprezz, At 19 August 2021 at 07:48  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home

Pixel Footer R1 C1 Pixel