Set Windows XP (Service Pack 2) compatibility mode on each legacy HMI programming executable, then verify three things separately: the application launches, a known project opens, and the controller connection works. The setting is stored per executable, so every program gets its own.
Legacy HMI programming software that will not start on a newer PC usually starts once its own shortcut is set to Windows XP (Service Pack 2) compatibility mode. The setting lives on the Properties dialog of one executable and applies to that program alone. Setting it is the first of three checks: after the mode is on, confirm that the application launches, that a known project opens, and that the connection to the controller works. The three checks fail for different reasons, so run them in order and record each result before changing another setting. Budget about 10 minutes for the settings and 30 minutes for the full check sequence on a two-application PC.
What compatibility mode changes
Compatibility mode is Windows presenting an older environment to one program: the Windows version the software was written for, plus launch behavior from that era. The same Compatibility tab carries related single-program settings, among them a reduced color mode, a 640 x 480 screen setting for software drawn for old displays, and Run this program as an administrator.
The setting is stored per executable. Two HMI programming applications on one PC take two settings; changing one program's mode changes nothing for the other. It also changes nothing outside the application: project files, the controller, the cable and the network keep their own state. That is why the checks below treat launch, project access and communication as three separate results.
What you need
- The workstation that runs the programming software, signed in with an account that can change shortcut properties.
- The exact shortcut or .exe you start each application from. A desktop icon and a Start menu entry can point at different executables, so set and test one launch path at a time.
- A copy of a known-good project file for the open check. The production original stays where it is.
- For the connection check: the controller, its cable or network path, and the protocol driver the project uses.
Set the mode on each executable
Close the application first; Windows applies the setting on the next start.
- Right-click the shortcut or .exe and choose Properties.
- Open the Compatibility tab.
- Check Run this program in compatibility mode for: and choose Windows XP (Service Pack 2).
- Select Apply, then start the application once.
- Repeat for the next application. The setting does not carry across programs, so every executable gets its own.
Start with Service Pack 2 on every executable. If a launch check still fails, change one setting at a time in this order: Windows XP (Service Pack 3) if your Windows version lists it, then Run this program as an administrator on the same tab. Windows also ships a guided helper, the Program Compatibility Troubleshooter, reached from Start > Settings > System > Troubleshoot > Other troubleshooters. It proposes the same kind of setting and can apply what it tested. Give each launch attempt about 2 minutes before judging it, so a slow legacy startup is not read as a failure.
Run the three checks in order
Each check answers one question about one application. Record pass or fail before touching the next setting.
Check 1: the application launches
Start each application by itself and confirm it reaches its normal working interface with no startup error. Test one at a time so a failure in one leaves the other's result clear. If a launch fails with the mode already applied, confirm the setting sits on the executable your shortcut actually starts, then move through Service Pack 3 and administrator mode, one change at a time.
Check 2: a known project opens
A successful launch is checkpoint one, and it is not proof a project opens. Open a copy of a known-good project and confirm the screens and configuration load; the production file stays out of the test. If the copy fails while the application launched fine, the file is the suspect. Recover a project that crashes on open before touching compatibility settings again (article:hmi-project-crashes-on-open-recover-it-safely). A project restored from an old archive disc can also carry a read-only flag that blocks opening; that has its own fix (article:hmi-project-backup-from-cd-r-will-not-open-clear-read-only).
Check 3: the controller connection
With the mode set and a project open, test the connection as its own job. Work through the physical path first, then the interface selection in the project, then the protocol driver. Keep the first test read-only or otherwise low-risk: do not download a project to a controller that is running a machine as your first test. If the path runs through an Ethernet serial server, that path has its own setup (article:program-an-hmi-panel-through-an-ethernet-serial-server).
Example: two legacy HMI programming applications on one Vista laptop
Inputs. One engineering laptop running Windows Vista, with 2 legacy HMI programming applications that must both work on it. The Vista compatibility list includes Windows XP (Service Pack 2), the entry this procedure uses. Each executable takes 1 compatibility setting, because Windows stores the setting per file. Each application gets 3 checks: launch, project open, controller connection.
Rule. Settings scale with programs: n applications need n settings. Checks scale the same way: 3 per application, run in order, and a check only counts once everything before it has passed.
Arithmetic. Settings: 2 applications x 1 setting = 2 settings. Checkpoints: 2 applications x 3 checks = 6 checkpoints. Time: about 10 minutes for the 2 settings and about 30 minutes for the 6 checkpoints on this laptop, at roughly 5 minutes per checkpoint.
Result. Both applications launch and both open a copy of the same known project: 4 of the 6 checkpoints pass. The first application then reaches its controller; the second does not, so 5 of 6 pass.
Decision. The compatibility mode is doing its job: every launch and every project check passed. Keep both settings and fix the connection on its own terms: path first, then interface selection, then protocol driver. The threshold to remember: a failed connection checkpoint with the first four passing is a connection fault; a failed launch or project-open checkpoint at any point is a mode or file fault.
When the mode is not the fix
- Launch still fails after Service Pack 2, Service Pack 3 and administrator mode: stop changing settings. Capture the exact behavior, the Windows edition and the software release, and take those to the software vendor's support. Leave system-wide compatibility and security settings alone until the vendor has had the failure details.
- The application runs but its dialogs draw clipped or oversized: that is a rendering fault, and legacy fonts are its usual cause. Clipped dialogs have a separate fix (article:fix-hmi-dialogs-clipped-by-legacy-windows-fonts).
- The project opens but will not communicate: check the protocol driver against the controller before tuning any serial settings (article:check-the-panel-driver-list-before-tuning-serial-settings).
Before the PC goes back on the floor
Write down which executables carry the mode and which entry each one uses, so the next rebuild or the next engineer does not rediscover it by trial. Keep the known-good project backup off the workstation. If this PC's only job is preparing project files for transfer on a flash card, the connection check gives way to the card workflow (article:send-an-hmi-program-update-to-a-customer-on-a-flash-card).
If the line also needs a status or notice board next to the machine, that screen is separate from the programming PC. Our shop-floor displays are built for that job, from shop-floor signage you can read from across the aisle: figure about 30 ft of viewing distance per inch of letter height when you size the board's text.
Recommendation: set Windows XP (Service Pack 2) compatibility mode on every legacy HMI programming executable before changing anything else on the PC. If a launch or project-open check then fails, change one setting at a time: Service Pack 3, then administrator mode. If only the connection check fails, keep both settings and troubleshoot the connection as its own job.
Questions
Does one program's compatibility setting apply to the others?
No. The setting belongs to the executable or shortcut it was applied to, so two HMI programming applications take two settings, and the Program Compatibility Troubleshooter's result applies to the program you ran it on. If one application launches and the other does not, set and test each one separately before comparing their results.
Should the mode be Windows XP Service Pack 3 instead of Service Pack 2?
Start with Service Pack 2, the entry this procedure uses. If the launch check still fails and your Windows version lists Service Pack 3 in the same dropdown, change that one setting and launch again. One change at a time keeps each new failure attributable to the change that caused it.
The application launches but cannot reach the controller. Is the compatibility mode at fault?
No. The mode shapes the environment the application runs in; ports, drivers and the network path sit outside it. With the launch and project checks passing, keep the mode in place and fix the connection on its own terms. Removing the mode mid-troubleshoot adds a second variable to the fault.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.