I have 32 bit application using 32 bit third party library. Now I have to make my application 64 bit , so that it can take advantage of 64 bit address space ( large memory ). Since I can not load 32bit library into 64bit application process, I am thinking of creating 32bit executable wrapper over third party library and communicate from my 64 bit app using IPC ( named pipe/socket ). So my question is would their any issue in doing so ?. Also if I have to install my application on 64 bit systems, all files related to my application will be copied to "c:\Program Files" directory. Now can I keep my 32 bit third party exe wrapper in the same "c:\Program Files" or I need to copy to "c:\Program Files(x86)" directory ?
相关问题
- the application was unable to start correctly 0xc0
- Inheritance impossible in Windows Runtime Componen
- how to get running process information in java?
- Is TWebBrowser dependant on IE version?
- How can I have a python script safely exit itself?
相关文章
- 如何让cmd.exe 执行 UNICODE 文本格式的批处理?
- 怎么把Windows开机按钮通过修改注册表指向我自己的程序
- Warning : HTML 1300 Navigation occured?
- Bundling the Windows Mono runtime with an applicat
- Windows 8.1 How to fix this obsolete code?
- Why windows 64 still makes use of user32.dll etc?
- CosmosDB emulator can't start since port is al
- Is it possible to run 16 bit code in an operating
This is exactly the way Microsoft recommends for such kind of problems. If you are working with COM, you can make COM exe server. For .NET use WCF. In your case - native C++, no COM - memory-mapped file or pipe is a good choice.
Regarding installation destination folder - you need to test this with the tool used to build installation packages. If the whole installation target is 64 bit, and single executable is 32 bit - the tool may show warning about this file. When the file is executed, it doesn't matter whether it is in Program Files or Program Files (x86), or any other directory.