Posts Tagged ‘32-/64-bit’

Is it possible to have more than one zenon version on my engineering station?

Thursday, November 14th, 2013

Many COPA-DATA Partners & System Integrators are facing the same challenge. They have to support the projects of various end customers. Most of the time these projects are maintained in different zenon versions.

For the engineering interface – the zenon Editor – that’s not a challenge because it is able to load any older project backup downwards to zenon Version 5.50 (Already mentioned in my Blog entry from the 31/10/2013).

What happens in detail when a zenon project in the Editor is upgraded to a new Editor version?

The process always follows the same steps, independent of the zenon versions. Option A: A project backup from previous versions is restored into a new zenon version.

  • The Editor recognizes a zenon project backup from previous versions; this information is stored in the project.ini file of each project.
  • The user is asked to adjust the project version to the new Editor. This is necessary because there might be changes in the database backbone of the Editor, like a new version of the MS SQL Server.
  • Afterwards the user is prompted to enter a target folder for the restored project. It is recommended to use a new folder rather than the project folder of the original project. The default folder for zenon projects is always C:\Users\Public\Documents\zenon_Projects.
  • Afterwards the project conversion is complete. The original backup file remains unchanged so it is always possible to go back to the previous zenon editor version.

Option B: Via the Option “Insert existing project …” a project of an older version is inserted into a workspace.

  • Again the Editor recognizes the previous project version and asks the user for confirmation of the conversion.
  • The only difference to option A lies in the fact that the zenon Editor automatically generates a backup of the project in the previous version before the conversion takes place. This backups are easily recognized, there naming uses the following Syntax: “before converted to …”

This backup can be found in the project tree under “Backups”. So there is always an easy way back into an older version.zenon Compatibility

How to convert a project from version 5.50 into zenon 7?

In principle, the same steps are necessary. Only that for projects of Version 5.50 a two-step conversion is necessary. First from zenon 5.50 into any zenon 6.xx version and then into any zenon version of generation 7.

But how can I handle the Runtime systems and how can I test my project locally on one and the same physical environment?

In principle the answer is easy. The various zenon versions can be installed in parallel on the same system. The zenon setup sees that every version gets its separate folder / registry keys etc. For the operator, we deliver the zenon Startup tool in which all the zenon versions are automatically included. Just select the appropriate version, start the registration process and run the corresponding Editor or Runtime.
The Editor offers a setting for the compiler through which the engineer can choose for which Runtime version the zenon project should be compiled. The compiler then automatically creates the Runtime files in the correct version.

zenon Compatibility

Can I also only convert parts of my project into a new Editor version / a new zenon project?

The best way to only convert parts of an existing project into another is to use the XML export / import interface of the zenon Editor.

  • This XML interface is kept compatible with the various zenon versions. This means one can export his tag list or screens out of an older version like generation 6. Afterwards, simply import the XML file into an Editor of generation 7. zenon sees that everything is converted correctly.
  • The XML files can be used as a kind of external database / library which is version independent.
  • The zenon import / export interface is designed in a way that with a new version there are only new objects or attributes added to the XML format. The old items are kept and always readable for a newer generation of the Editor.
  • The same strategy is followed for example with the zenon API (the programming interface) -> it is always kept compatible.

 

32- / 64-bit systems – are they compatible, or do I need to use the same technology for all components?

Friday, November 8th, 2013

Since zenon Version 7.10, our product has been available in a 32-bit & 64-bit edition. Some might be confused where the difference is or how this effects an application. This blog entry is designed to solve some of these mysteries.

32-64-BitThe setup provides both editions automatically. So there is no add-on or separate edition to purchase or install. The setup automatically recognizes if the computer is a native 32- or 64-bit system and installs either one or both editions of zenon. Or, in other words, on a 64-bit machine the user is free to choose which edition he wants to run. Simply choose the corresponding button in the zenon Startup Tool.

On a 64-bit machine you will now find two installation folders; one for 32-bit components and one for 64-bit components:

  • C:\Program Files (x86)\COPA-DATA\zenon 7.10 SP0
  • C:\Program Files\COPA-DATA\zenon 7.10 SP0

The version independent files are compatible with both versions and can still be found within:

  • C:\ProgramData\COPA-DATA\zenon710

The following components in zenon are available in a 64-bit version. The rest, for example the drivers, remain as a 32-bit component, but they are automatically loaded into the 64-bit environment:

  • Editor
  • Runtime
  • Process Gateway
  • Webserver
  • zenon Services

As the two versions are kept completely compatible by COPA-DATA there is not much more a user needs to take care of.

  • It makes no difference if a zenon project is designed in a 32-bit Editor and later opened in the 64-bit Editor (or the other way around).
  • Choose freely between Editor and Runtime. Use your maintenance Laptop based on a 32-bit technology, use the Remote Transport to copy and run the project on a 64-bit based server machine.
  • Also, it is not a problem to have a mixture of both editions in the Runtime. Run the server projects on a 64-bit technology while the still use a 32-bit environment.

So keep it simple, choose the technology that fits your environment best and enjoy zenon!

Process dumps of 32-bit processes on 64-bit operating systems

Thursday, June 20th, 2013

64-bitSometimes it is necessary to snapshot the state of a process into a process dump file in order to analyze it in the debugger afterwards. Even if this is usually straight forward, creating process dumps of 32-bit processes on a 64-bit operation system could have some traps. Not paying attention to the architecture of a process could lead to unuseable dump files. This article tries to bring some light into this topic.

Background

As with processes, there are 32-bit and 64-bit dump files. Now it’s the case that usually the process architecture of the process which intiates dump file creation determines if a 32-bit or a 64-bit dump is created independently from the process which is actually dumped. The reason why this could happen is, that on 64-bit operating systems 32-bit processes run in a type of 32-bit Windows emulation, called Windows-on-Windows64 (WOW64). So therefore also 32-bit processes have a small 64-bit part, making them seamlessly integrate into the totally 64-bit operating system. So if a 64-bit dump file from a 32-bit process is generated by mistake, it will contain some user mode-parts of this WOW64 emulation.

Rude awakening

What happens on opening a 64-bit process dump of a 32-bit process in Visual Studio at home depends slightly on the version of Visual Studio. Visual Studio 2012 tells you immediately: “Debugging a 64-bit dump of a 32-bit process is not supported, please collect a 32-bit dump of a 32-bit process.” With former versions of Visual Studio debugging can be started without any problem but in call stacks you will only see some lines containing “wow64cpu”. In this case you will notice that you have to delete your dumps and visit the site a second time to get new ones.

The simple solution

As mentioned already, the solution is rather easy. If you create your dumps with Task Manager, WinDbg or ADPlus, you only have to use the 32-bit version of these programs. You will find them in C:\Windows\SysWOW64 or C:\Program Files (x86)\… respectively. Please check in the Task Manager if the “*32” is added to the process name. So if you mind that the initiator process of dumping and the investigated process have the “*32” suffix, nothing should go wrong anymore. And the opposite way around, if your investigated process is a 64-bit process (no “*32” suffix in Task Manager), use a 64-bit dumping initiator.

Learn about zenon on www.copadata.com

 

How about using ActiveX-controls in 64-bit zenon?

Wednesday, June 12th, 2013

64-bitIn some projects ActiveX-controls are used for custom GUI objects rather than creating them from standard zenon screen elements. Usually these ActiveX-controls are written in VB6 or C++. All these ActiveX-controls are 32-bit components and cannot be used in 64-bit applications out of the box. But under some circumstances it takes only some simple modifications to make them run in 64-bit aswell.

Background

ActiveX-controls in principle are DLLs with a standardized COM interface. So they are in-process COM-servers and are loaded directly into the host application process. Now, fact is that generally a 64-bit application is only able to load 64-bit DLLs. So 32-bit ActiveX-controls cannot be loaded by 64-bit zenon. To make this possible, the 32-bit ActiveX-control must be ported and compiled into a 64-bit DLL.

Bad news

Unfortunately the previous VB6 is not able to generate 64-bit output. So there is no way of bringing a VB6 ActiveX-control into 64-bit zenon except by rewriting it completely in C++ e.g. If it is absolutely necessary to keep them, one must stick to 32-bit zenon even if the used platform would offer using the 64-bit version. The same is true of course, if you do not have the source code at all and only have the 32-bit binaries.

Good news

If your ActiveX is written in C++ and you have the source code, you can easily introduce a second x64 configuration into the project and compile a 64-bit AcitveX-control then. Usually there are no or only minor changes necessary in your source code that make it run again in 64-bit. And please don’t forget to also register 64-bit ActiveX with regsvr32 afterwards. 32-bit and 64-bit ActiveX-controls are registerd in different registry paths, even if they have “the same control” with the same CLSID and name.

Visual Basic for Applications version 7.1, 32Bit and 64 Bit

Wednesday, June 27th, 2012

Introduction

The next version of zenon will be available in 32 and 64 bit. Therefore the included Visual Basic for Applications package will be upgraded from the 6.5 (32Bit) to 7.1 (32 and 64Bit). When using the 32Bit version of zenon none of the existing code needs to be modified, workspace and runtime projects can stay the way they are. But to take full advantage of the available memory and hardware the 64 Bit version is obviously the better choice.

Changes

When using the 64 Bit version of zenon, VBA 7.1 will also run in 64 Bit mode. To differentiate between the 32 and 64 Bit version quite a few keywords, defines and declarations have been introduced to VBA.

Any existing API declarations have to be modified in order to be used in 64 Bit mode. For example the API-function “FindWindow” (which can be used to find a window by use of its class name and window name) used to be defined like this in a 32Bit VBA project:

Private DeclareFunction FindWindow Lib "USER32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As Long

Whereas the 64 Bit version of this declaration needs to be:

Private Declare PtrSafe Function FindWindow
Lib "USER32" Alias "FindWindowA" (ByVal lpClassName As String, ByVal lpWindowName As String) As LongPtr

NOTE: The 64 Bit declaration will work for the 32 Bit version mode of VBA 7.1 as well.
Since Microsoft currently does not include a 64Bit version of the “Microsoft Common Controls”, objects from this package cannot be used in the 64 Bit mode. This  package includes the CommonDialog-Controls often used for “File-Open” and “Color-Picking”-Dialogs.

Additions and mixing

Microsoft introduced two new conditional compilation constants: “VBA7” and “Win64”. The VBA7 constant can be used to determine whether the project is running under VBA7 or on an older version. This constant is useful for backwards compatibility, and prevents the requirement for separate
“pre-7” and “7”-versions of custom created classes.

#If VBA7 Then
'Use VBA7 functionality
#Else
'Stick to old VBA solution
#End If

The Win64 constant enables a separation between the 32 and 64 bit version of VBA and can be used to ensure that code is only executed when VBA runs in the correct mode.