Has anyone ever tested a Microsoft Access 2007 .accdr application on Windows Vista 64 bit version? I sell a shareware program using the Access 2007 runtime, and, for one customer with that setup, there's some kind of problem. According the user ". When I try to execute the program, it opens IE and then brings up the dialog box to either Open, Save, or Cancel the "myprogram.accdr" file. If I choose run it simply goes away and then returns back to the same question"
It sound like this somehow got mapped to IE. On my windows XP system, it starts Access and runs the program. Any ideas?
MS Access isn't supported on 64bit, as it requires a 64bit JET engine which isn't available, Microsoft only released a 32bit JET engine. So your application has to run on WOW so it runs as 32bit and therefore is able to use the 32bit jet engine.
It works just fine. After 3 weeks of hair pulling with access installer packager. I got it wot work. your references must be added in the packager or you will get run time errors. Billions of them.. Not really 4 or 5. and then it will not recognize the built in functions like date, time, isloaded....etc.
SO YES IT WILL WORK.
Is the customer using the 64 bit IE? Access 2007 is 32 bit only. The 32 bit IE might work properly.
Related
When I change fonts of text items (When I changed about 5-6 of it), Oracle Reports Crashes. It gives error message "Not Responding". Why? How can I solve it?
Device OS: Windows 10 Pro
RAM: 8 GB
64-bit
Unlike Forms (which is a fine piece of software), Reports is one of most unstable tools I've ever worked with. Yes, it tends to crash without a reason. It isn't even "don't do this because it'll crash" so that you could create your own "don't do it" list. It happens for any reason - in your current case, when you change a font.
So, what to do?
check My Oracle Support (previously called Metalink) to see whether there's a patch for your Reports (i.e. Developer Suite) version
save frequently so that changes you've made aren't lost (and you'll have to do everything again)
reboot sometimes helps
I've installed Developer Suite 10g onto a virtual machine that runs under Windows XP (which is/was a certified combination). Have a look at certification matrices; if operating system + Reports version isn't certified, there's really no guarantee that it'll work.
as I've told you - even if it is certified, it crashes anyway
Unfortunately, I don't have a magic wand to solve your problems. Be patient as much as you can. Good luck, I sympathize with you.
I'm using PDFCreator to create PDFs in VB6. My VB6 development VM is Windows XP 32-bit. On that system PDF generation works both from a desktop app and from ASP (via VB web class runtime).
When I create an exe to run on Windows 7 or Windows Server 2008 R2 or use it in the web class runtime I get:
Run-time error '429':
ActiveX component can't create object
This is when using early binding. I add a project reference to "C:\Program Files\PDFCreator\PDFCreator.exe" and then in my code I do:
Public WithEvents mPDFCreator As PDFCreator.clsPDFCreator
Set mPDFCreator = New PDFCreator.clsPDFCreator
If I don't use a project references and use late binding instead, then it works on the desktop app but still not in the web class runtime. Late binding is done like so:
Set mPDFCreator = CreateObject("PDFCreator.clsPDFCreator")
I want to use early binding so that I can use the events, plus I need it to work in ASP/Web Class Runtime.
I realise I'm dealing with ancient technologies here and I should have tempered expectations when running such things on modern 64-bit Windows and IIS. If porting this legacy app to .NET were an option, I would.
On IIS I have set the Enable 32-bit Applications setting on my app pool. I have also tried running it as Administrator to rule-out security problems.
I've done everything I know how to debug this, but I'm stumped. I suspect it has something to do with PDFCreator being a 32-bit app and COM registration. I've also tried running regsvr32 out of SYSWOW64 but PDFCreator.exe can't be registered.
Windows 64-bit architecture does not allow the load of 32-bit dll into 64-bit processes.
But you can modify the configuration of your vb project to convert it from an in-process dll COM component into an out-of-process exe COM server. This will allow you to instantiate your 32-bit component from a 64-bit process.
See Process Interoperability
Since this is a VB6 question there aren't any 64-bit processes to worry about.
It seems far more likely than anything else that this library just isn't being registered properly. I haven't use it since I don't know whether its setup works properly. I do know that the download itself does not display with a UAC Shield on its icon, suspicious in itself. For all I know the setup program spawns a run of the wrong regsvr32.exe.
But it seems more likely you have misregistered the library manually after copying it naked over to these 64-bit Win7/Server 2008 systems.
In any case, going over all of the symptoms you describe, I'd guess it got registered as a 32-bit ActiveX library but registered in the per-user virtualized part of the registry for the user you were logged on as when you registered it.
This can be a hassle to clean up after. However you should, and then be sure to manually run the original setup once again with elevation.
These threads that include hand-wringing over "ancient technologies" really get old. It's a poor workman who blames his tools. In the future why not hire an experienced programmer to handle tasks like this?
I use PDFCreator in my accounting software written in VB6. Years ago, I noticed that after a certain update from the makers of PDFCreator, my software stopped working properly with it. The problem stopped after I re-installed the older version, and came back when yet another new update was released from them, so I have had my customers freeze at the version that worked. I don't know off the top of my head what version that was, but I can check my own web site since I made it downloadable for my customers if it would help, but it's likely many years old now.
I am using "Microsoft Visual Studio" to work with an "MFC application".
I am using "Installshield" to create the setup file for this application.
I get a "setup.exe" file.
If I run this setup on a "Windows XP 32 bit" machine, the installation ends properly.
Yet, when I try to start the installed program, I get the message:
"The procedure entry point _except_handler4_common could not be located in the dynamic link library msvcrt.dll."
In debug mode, I can't find the moment the error occurs because whatever the breakpoint I put in the code, the message appears before reaching the breakpoint, I guess at the very beginning of the program execution...
Note: It works for Vista 32 bit and Seven 64 bit.
It appears lots of people do have the same problem but I couldn't find a solution for myself.
Can you help?
Thank you.
Welcome to the world of DLL hell and application dependency analysis.
I found that DLL on my Win8 machine in the SYSWOW64 (32bit System32 folder ) with version 7.0.9200.16384. Looking at it using Dependency Walker I can see it in fact exports the function you are looking for.
I also see on my InstallShield machine a merge module called MSVCRT.MSM that redistributes version 6.00.8797.0 of this file. However when I look it using Dependency Walker, I see it has the exported functions _except_handler2 and _except_handler_3 but not _except_handler_4_common.
So therefore you need a newer DLL and that merge module won't help you. Microsoft used to have this cool website called DLL Help Database that told you all the versions of a file and what shipped them but sadly they killed it.
BTW, I can also see that this DLL is installed with Windows these days. Windows XP? I'm not so sure as I'd have to fire up a VM and look.
A couple possible resolutions:
Find out what SP or Hotfix of Windows fixes this and make it a dependency of your MSI.
Grab the DLL from a Win 8 machine and add it to your INSTALLDIR and deploy it privately.
One final note. This is either caused by the version of Windows XP comes with an old version of the DLL ( A related KB Article says it does ) or that a third party application whacked the DLL causing the problem. Some more study is required here.
I recommend you first try installing the MSVC Redist version 2008. That one does include the implementation of the missing function.
This post is old but I wanted to leave my solution since this problem was hell to me. My python app was working for Linux, Win7, 8 and 10 but WinXP refused to work with that message.
I was using py2exe to get an executable and it will put some DLLs along with the exe file.
Deleting some dlls from the exe's directory was the only thing that make the app work in XP and continue working in the other systems:
[ "POWRPROF.dll","IPHLPAPI.DLL","USP10.DLL", "DNSAPI.DLL" ]
Also distributing "Microsoft.VC90.CRT" directory along with the exe file, with it's manifest and DLL files.
I hope this will be useful for someone, since it took me weeks to figure it out.
(i know the OP wasn't working with python, but the error is just the same)
Your program has a dependency which is not being satisfied on Windows XP. You might try using Dependency Walker to identify it, or you might check for known limitations. For example, Visual Studio 2012 doesn't support Windows XP until update 1 and a build option change - is that what you're using?
The problem was probably because you might used a corrupted DirectX version on your Win XP. It happened to me as well because I randomly downloaded a DirectX setup which was corrupted and caused these. The solution I did was is I deleted all the files that has anything to do with directX from C:Windows/System32, deleted the directX from add/remove program as well and completely removed the whole registry key from regedit. Local_machine/software/microsoft/DirectX... What I did then was found a original values and keys for DirectX 9 on the net and made a new registry key.
The DirectX folder was once completely and originally back on regedit and it showed in dxdiag that the directX is installed.
In case you encounter crashes in the game, I suggest you to download .NET Framework 3.5 Service Pack 1 and then make a backup on your PC (If you're not using nVIDIA graphic cards like I do, I use ATI Radeon) and download nVIDIA PhysX system software driver and see if it works. (You need nVIDIA phydX drivers to run this game without crashes only if you use Win XP, the problem shouldnt encounter on Win 7) In case the drivers screw up your PC (The nVIDIA PhysX one) you will be able to restore your old PC function before those drivers (If you made a backup of your PC, I suggest using Acronis Boot for backups) it means you're totally out of luck if you're not able to get the nVIDIA PhysX on ur for example, ATI graphics on Windows XP, because without nvidia physx, on Win XP, Metro wont run, while on Win 7 / Vista / 8 it should.
I just installed the latest VS 2017 and was running into the same problem. I googled everything but couldn't find any solution, so I just defined it myself:
extern "C" int _except_handler4_common() {
return 0; // whatever, I don't know what this is
}
I've spent the last 8 hours picking my code apart with this exact same error and it turned out to be a line of code in my application, specifically a check for IPv6 support in the OS:
conf.IPv6Disabled = !(Socket.OSSupportsIPv6);
I commented that line out and voila, error disappeared.
This problem persists to every software or game that requires windows 7 or 8 or vista but is made run into windows xp. So if you want to resume or start your program you need to upgrade your windows to 7 or 8 or vista as per the system requirements of the program.
HOPE IT WAS HELPFUL
THANKS
I need take an old software that was built in 4D 2004 (you probably never heard about 4D but it doesn't matter) and make it compatible with Windows 7 by fooling it and making him believe he's running under Windows XP.
I thought the application was getting the version number of windows from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion and that I could change this value but I was wrong… Even if I change the values in the registry, the version number of windows returned by my application is always the same:
498139398 for Windows 7
170393861 for windows XP
Those value contains the windows version (this link explain how to extract the version number) but I don’t know where it was taken from.
If you google those numbers, you’ll find out that other applications are referring to the same version number.
I tried to find what registry was used by the application with a Process Monitor but none of the registry accessed by the application seems to be related to a windows version.
Does anyone have a clue of where those values might be coming from? Could it be outside the registry / hardcoded somewhere?
Windows already has tools to do this. Have you tried right-clicking on the program, selecting Properties and looking at the Compatibility tab?
For more complex tricks investigate "Microsoft Application Compatibility Toolkit".
All these years i have been successfully using EnumServicesStatus in combination with OpenScManager (with SC_MANAGER_ENUMERATE_SERVICE) to get a list of the services installed on a computer. This has been working well since NT 4 and up to Vista.
Now, for some reason, in Windows 7 I'm not getting the whole list of the installed services, but only a few of them. No errors, just a very incomplete list of services
Has anything changed in Windows 7? Do I need administrative powers now to enumerate services (I hope that's not the case)? Using Delphi 2010 but the same code was working file in D2007.
I don't think anything has changed here. It would cause huge incompatibilities with old software. But D2007 used the ansi version ENUM_SERVICE_STATUSA and I think D2010 calls the unicode version ENUM_SERVICE_STATUSW. Maybe you are doing some manipulation in the results that assume that the result is ANSI when you are getting Unicode? Just guessing.