Digital Workshop

Hi all,

I have a legacy publication pair, one that sets up variables as an EDIT program and stores it in text files, and one that reads the information from the text files and displays the resources defined in these text files in full screen (identify a picture resource and associated text, then display this as a digital poster). The publications were written using OPUS 5 and run very happily in a Windows XP environment. When some of our customers upgraded to Windows 7, the EDIT program continued to run fine, but the display program would launch and then terminate without displaying anything. I resolved this problem by switching Windows 7 aero off (Windows 7 basic mode) and life was once again OK. I am not sure if this was a fix or a convenient workaround only.

Now some of our customers are starting to roll out Windows 8 machines, and the same problem has re-appeared (EDIT works fine, DISPLAY terminates - splash screen only), unfortunately, Windows 8 does not have the Areo stuff (at least that I can find) so I have not been able to disable this (I think Aero was thrown out for Windows .

I have upgraded recently to OPUS 8.12 and my development machine is now a Windows 8 machine. We are currently re-writing both apps, adding a database backend, but it will not be ready to roll out for a number of weeks yet. My question is if anyone knows any tricks in Windows 8 that I can setup as a stop gap until the new versions of our apps are released.

I haven't published the new apps yet in the OPUS 8.12/Windows 8 environment, so I am not sure if developing in a newer environment will resolve my problems. Although not impossible, it will be a pain to re-develop this app in my new environment.

Hopefully the knowledge base out there might be able to help with some Windows 8 wisdom.
Thanks in advance
Rick

Windows 8 -32 or -64?
Win 7 -32 / 64?

The main problem post XP wasn't Aero as such but the introduction of the new Windows Display Driver Model (WDDM) which had problems with graphics cards, aero and various older software.

You could try disabling DirectX in the publication options and see if that helps - but in reality, you need to publish software with a new version of Opus.

Mack

Hi Lar and Mack,

Windows 7 & 8 both 64bit.

I recompiled in our new W8 environment, disabling DirectX in the publication, but still get the same result
This one has me stumped.

There was a Post some time ago... about using compression during publication causing some problems for a Pub. May not apply here, I think flash or video was involved above maybe.

Doing some searching, came across these:

http://www.techsupportalert.com/content ... ations.htm


http://www.techsupportalert.com/content ... ations.htm
I assume Opus' Pubs are 32-bit for the installed and standalone EXEs.

There is other information out there that points to --- incompatible paths between pre-Vista and the Win 7/8 OSs, DLL issues, display resolution issues (app display too small) and display drivers issues.

Thanks Lar.

I had a read and it raises more concerns. Out of curiosity, I installed the DISPLAY program on my 64bit Windows 8 laptop and it worked fine. I'm thinking that Windows 8 environments might not always be the same - not having this control is worrying.

Hi all,
Thought I'd update the community on this problem. Have not totally solved it, but I do have a work-around. Some of this things that I have found might be useful to other authors.

After many very late nights, I found that the problem is associated with LogMeIn, or more correctly the Mirror driver that it uses. There are a few forum posts that have identified this problem in the LogMeIn community. Appears to have become a problem with Vista and carried through to Windows 7 and 8. There were technical reasons listed, but at 3am, I wasn't looking for explanations, just solutions (so apologies for not being able to elaborate more here).

It looks like LogMeIn installs it's own LogMeIn Mirror Driver as a display adapter. Once this is there, it stops my OPUS publications from running. It's easy enough to remove this driver - LogMeIn even supply a command line switch to uninstall it (...\logmein uninstallmirrordrv). As soon as this driver is gone, the applications work fine.

There is a lot of chat about why this driver is even needed, especially if removing it does not affect LogMeIn operations, fact is that it appears to re-install this driver (temporarily) when you have an active LogMeIn remote session. If my applications are running at the time of remote connection, then they continue to run fine, but as soon as you terminate it to do some maintenance, you cannot restart it. This is a problem.

The workaround that I have is to:
1. Commence a LogMeIn stealth remote session.
2. Once in, terminate my application.
3. Start Team Viewer Quick Support
4. Get the ID and Password
5. Terminate my LogMeIn session (thereby releasing the Mirror driver)
6. Remote in with Team Viewer and do my stuff, including restarting the OPUS application.
7. Terminate the Team Viewer session and re-establish a LogMeIn session.
8. Clean up the Team Viewer footprint messages.
9. Terminate LogMeIn

Now I know that logical solution would be to ditch LogMeIn in favor for Team Viewer, and that it exactly what we will do - problem is that we cannot do that just now.

This exercise has been frustrating, but it was nice to get somewhere close to a solution, or at least pointers to a solution. I suppose I wanted to document this so that if other OPUS developers see this strange behavior they might get some clues here.

Now onto installing DropBox - fingers crossed that it does not introduce it's own set of "challenges".

Cheers
Rick

Rick,
Thanks for closing the loop and sharing your results.