I have an error 285 when two old application try to communicate using DDE. I have the sourcecode but can't compile because it uses DAO.
What is the best way of debug the DDE communication and sort this error?
I have machines with Windows 10, Windows 7 and Windows XP (very old machine). I value solutions that use .net (VB.net or C#) since Visual Basic IDE (Visual Basic 6) can only run on Windows 7 or early OS. I understand that DDE is a very old tech, not supported by Microsoft. See "Please feel free to stop using DDE" blog post (2007)
Related
I need to install Microsoft XML Parser 4.0 from Inno Setup.
How can that be done?
I was given a task to embed MSXML in the installer of ours. It's a proprietary piece of software our company makes (for accounting, it uses XML to store and exchange data). Apart from modern systems It's also going to be installed on many old systems using Windows XP.
I'm using Inno Setup 6.1.2.
Also, is there a quiet mode of installation as an option? So the users won't have to click anything and just be notified that MSXML was installed?
Did you Google this?
https://silent-install.net/software/microsoft/msxml_parser/4.30.2107.0
Eg:
msxml.msi /qn /L* "%temp%\XML Parser 4.30.2107.0.log" /norestart ALLUSERS=2
If you look at the Msiexec (command-line options) it does say the qn switch will display no user interface.
Somewhat of an aside, the requirement of installing both on XP and on 'modern' systems may create a conflict that you or your installer will have to resolve.
From Installing and Redistributing MSXML 4.0:
System Requirements
MSXML 4.0 is supported in Windows Server 2008 R2, Windows 7, Windows
Server 2008, Windows Vista Windows Server 2003, Windows XP, and
Windows 2000
From Installing and Redistributing MSXML 6.0:
System Requirements
MSXML 6.0 is supported in Windows Vista; Windows 2000 Service Pack 4;
Windows Server 2003; Windows Server 2003 Service Pack 1; Windows XP
Service Pack 1; Windows XP Service Pack 2.
MSXML 6.0 is preinstalled with Windows Vista. For earlier versions of
Windows, you can install MSXML 6.0 as a separate download.
So you can only use MSXML4 below Vista. And with Vista and above you should be able to reply on MSXML6 already existing.
Your installer could perform an OS version check (alt ref) and then only install MSXML4 if needed. Or you might be able to detect specifically if MSXML6 is installed and then install MSXML4 only if not (assuming therefore its an older system).
But I would test your application (if you haven't already) and see if it will run against MSXML6; it may, without changes. If so then I would forget MSXML4 and include MSXML6 in the installer instead (*). That way your installer could just run it 100% of the time, and expect that on Vista and up it would just do nothing. Your installer would therefore be simpler plus you would be taking advantage of "MSXML 6.0 provides security and performance improvements over earlier MSXML versions." noted here.
(*) Unless you have to run on WinXP pre-SP1?
I have fairly large legacy (read only) VSS 8 database that is currently sitting on a windows 2003 server.
As part of an infrastructure consolidation I am being asked to move it onto a new Windows 2012 server. I can't find any notes on whether or not VSS8 will run on 2012; before I even attempt this do you know of any issues running VSS on Windows 2012?
Is it easier to flip the old server to a VM and keep it for posterity and those rare occasions we want to know what someone did in the naughties?
The database itself is merely a fileshare, so you don't have to install the accelerator if you don't want to/are unable to.
In the weeks since asking have deploying VSS2005 (with the runtime available on the server) onto Windows 2012 enterprise. The applications install with a warning about versions but they run fine; including the admin tools for users and checking the consistency of the databases. The end user side all works well too.
When I run command line application (executable generated using visual studio 2008) on non development windows 7 machine it gives following run time error "application has requested run time to terminate in unusual way. Please contact application support team for more information". It runs fine on a development machine.
With VS 2005 and VS 2008, Visual C++ used a side-by-side versioning scheme that requires manifest entries embeddded in the EXE to really work correctly in all cases. It's possible you are dealing with one of these. See these articles for details on debugging these side-by-side issues.
Diagnosing SideBySide failures
Part 1: Troubleshooting VC++ Side by Side Problems
Part 2: Troubleshooting VC++ Side by Side Problems
Note that with VS 2010 and later, Visual C++ no longer uses this side-by-side scheme. That said, there are still lots of reasons to use embedded manifests anyhow. See this article.
Does a System.Runtime.InteropServices.COMException of 0x80040154 always mean that the class isn't registered? I'm getting a COMException which says "Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following error: 80040154." It's trying to load Interop.Domino.dll which is a reference I got from the COM tab of Add Reference called "Lotus Domino Objects" which points to domobj.tlb in the Notes program folder.
I wrote the code years ago - it's the only thing I've ever done with interop and it's fair to say that I never really got to grips with it.
I'm seeing this error again after moving the code to a 2008 R2 server (so it's x64). It was written on XP and run on 2003 (both x86). In order to diagnose the problem, I built a Win7 x86 (because there's no R2 x86) box and it worked. I also built a 2003 x64 box and it fails with the same error, so it looks like it's caused by moving to x64 architecture. Is there something I should do when doing interop to get x86 COM DLLs to work on x64 machines?
I had the same problem trying to build and run a .NET application on Windows 7 x64 that called interop.domino.dll, which is 32 bit only.
To resolve, I recompiled the .NET application to run specifically as x86 when run on x64 operating systems.
I was using Visual Studio 2010 Express Edition which is trickier to target specifically for x86 platforms than the paid for versions.
The solution was:
Click TOOLS > OPTIONS > PROJECTS AND SOLUTIONS
Check the box "Show advanced build configurations" and click OK
Click TOOLS > SETTINGS > check EXPERT SETTINGS to see the build configuration manager
Click BUILD > CONFIGURATION MANAGER select the platform dropdown to X86 and click CLOSE
Now rebuild the project
Pay attention to register of 32-bit components using the correct register (C:\Windows\SysWOW64\regsvr32.exe).
If you have already registered up with the 64-bit version, unregister each dll with the same version.
More help you find here Team is Going from XP32 to XP64 for .NET Development - Any Gotchas?
Good luck
There's an IBM technote that indicates that the Domino COM classes are not supported on a 64-bit OS. See https://www-304.ibm.com/support/docview.wss?uid=swg21454291 So it seems like even by compiling the code to run as x86 (as per mpownie's answer), you're still taking some chances.
I'm running Embedded Visual C++ 4 with service pack 4, to develop an application for a device running CE 5.0. I'm using the CE 5.0 SDK for this purpose, which works fine except for the fact that while it will target my device (i.e. an SH4 based PDA), it will not let me select anything other than the StandardSDK emulator for debugging. If I go to Tools / Configure Platform manager, I can connect to my device under Windows CE default Platform, but I cannot select it from the Build Toolbar for output and debugging purposes. Is there any work around for this. I've considered moving to VS2008 for this app, but it breaks a large amount of 3rd party code.
Embedded Visual C++ and "Platform Builder" are different tools. The "Windows CE" SDKs are designed to work with "Platform Builder" to make things like OSes and drivers. However, Applications generally use the "Windows Mobile" or "Pocket PC" SDKs.
So here are three different solutions:
Continue to use EVC++ 4.0
If you want to keep using Embedded Visual C++ 4.0 instead of one of the newer IDEs, you can use "SDK for Windows Mobile 2003-based Pocket PCs". Which I believe is the newest SDK for EVC++ 4.0.
Upgrade to VS2005+
This details how to migrate from EVC++ to VS2005 while still making native apps.
You can use the 5.0 SDK line of features in the "Windows Mobile 5.0 SDK for Pocket PC"
Use Windows CE SDK to make Applications with EVC++ 4.0
It actually is possible to make Applications using a CE SDK. This is used by OS developers to make applications for their OS.
You can develop an application using
Microsoft® eMbedded Visual C++®
together with Platform Builder. Before
you can develop an application, you
must use Microsoft Platform Builder to
create an OS design, build a run-time
image, and then download the run-time
image to the target device.
When you download a run-time image,
Platform Builder uses a download
service to copy the run-time image to
the target device. When the run-time
image runs, Platform Builder
communicates with the target device
over a kernel transport.
To develop an application, keep
Platform Builder connected to the
target device, and then run eMbedded
Visual C++. After you write, compile,
and run the application, eMbedded
Visual C++ uses the established
connection to run the application on
the target device.
Note The previously mentioned
process differs from the process used
to develop an application for a
run-time image not downloaded by
Platform Builder. When you do not use
Platform Builder, you manually connect
to the target device using the
application connectivity
communications framework of Platform
Manager. For more information about
application connectivity, see
Application Connectivity.
-- http://msdn.microsoft.com/en-us/library/ms859575.aspx