I'm developing a network redirector using RDBSS.
In our network redirector volume, a executable file which is packed from Inno Setup(Open source packer) can not be run.
When we do double-click the file in Windows Explorer, the Explorer shows this messagebox.
It works well on 32bit Windows. Only 64bit Windows is problem.
I guess it is related with npdll or MUP.
We have implemented npdll, and I thought it doesn't have any bug now. - Of course we also have npdll 64bit version.
Other executable files and any files work well for both 32 and 64OS.
If we run this file in 64bit Windows SMB volume, it runs fine.
So, I'm pretty sure some our codes have a bug.(npdll or redirector driver)
Could you guess anything about this?
P.S Is there a good document describing how MUP works? If you know, let me know please.
Thanks.
The other executables which work, are they 64-bit or 32-bit?
If only 32-bit processes (like InnoSetup) fail, could it be that you need to install both the 64- and 32-bit versions of your DLL on x64 systems? That's required for some DLL types (e.g. video codecs) if you want their functionality to be available to all programs, but I'm not familiar with RDBSS and thus don't know if it applies in this case.
Related
I have a program built with VB6 and using some 32-bit DLL's. Will this program run on a 64-bit machine? This page suggests that it should run fine on the Windows on Windows layer, but what about the DLL's?
Yes, both the VB 6 program and the DLLs will work just fine on a 64-bit version of Windows.
Since both are 32-bit, they will run under the Windows-on-Windows 64 (WoW64) subsystem, which effectively emulates a 32-bit operating system on the 64-bit versions of Windows.
I've run many such programs myself with nary a hitch.
Beyond Explorer extensions and kernel mode drivers (neither of which you've written in VB 6), any compatibility problems that you might experience are almost certainly the result of bugs in your own code, which are easily fixed upon detection. Ask more questions about that when you find them.
Are the DLLs built with VB6 as well? Or are they native?
If you are dealing with 100% VB6, then in my experience, yes they tend to run with minimal problems (I maintained a number of plug-ins for another program that were mostly implemented as VB6 COM components, around the time that Windows 7 came out).
It will all of course depend on what libraries your code is using, whether or not you are accessing locations such as %PROGRAMFILES% etc, calling code in native libraries. These things can cause small problems but it is possible to work around them.
Microsoft are still supporting the VB6 runtime on 64-bit windows
Yes, it works, and if you have any problems they will help you.
We are in the process of building a 64bit version of our software, but we use Flash player's OCX control to host Flash in our windows. This OCX file is a 32bit build, do you know if it's possible to host this 32bit version of Flash within our 64bit application?
It's certainly possible... Firefox has 64 bit versions that embed the 32 bit Flash player. On Linux, this is accomplished by nspluginwrapper, which is open source so perhaps you can figure out how they do it. There must be something similar for Windows.
I do not believe that loading 32-bit DLLs into 64-bit processes is supported by Windows. An OCX is a DLL with a different extension.
You need to use some kind of external (COM) host process
Is it possible to run the COFF executable files on UNIX or the ELF executable files on Windows? And what would be the steps to be able to run either file type on Windows and UNIX. I'm just curious.
To answer your question properly, it is relevant to review what ELF, COFF, and PE are. These binary formats are essentially just containers that give directions to the operating system about how to execute the raw CPU instructions contained in the file. They are very much like audio/video containers like MKV, WMV, and OGG. Support for the executable format is either in the operating system or not. Microsoft Windows has consistently not given any support for COFF or ELF, until recently. With Windows 10, Microsoft has provided indirect support for ELF by building into the Windows kernel UserMode-Linux compatible system routines. A UserMode Linux kernel runs on top of the Windows kernel and runs all ELF binary formats almost as if it were running independent of MS Windows.
The alternative to using the UserMode-Linux (sub-kernel) being for Microsoft to rewrite the majority of the Linux API in a completely compatible format, their choice solves one other compatibility issue: The API. "A" stands for Application and "I" for Interface, however the API as an interface is mainly just a set of executable routines and environment assumptions. Access to the filesystem and most basic system routines is provided by the Windows kernel, while everything else is provided in the UserMode Linux kernel. This way not only can Windows run ELF formatted executables, but in can run the most popular ELF executables that are already made to run on the Linux API.
The reverse, the other half of the question, running PE (most Microsoft Windows executables) on Linux is possible as well. There are two runtime wrapping libraries that can run MSIL (virtual machine application) and Win32 (normal CPU application). Because the Linux kernel is extendable to recognize a certain byte format, then run an appropriate wrapper program, in effect the kernel supports PE and potentially more executable container formats. Therefore, Linux can run some PE programs either in the mono runtime (.NET/C# applications) or in the WINE runtime (Win32 C/C++).
To install the UserMode-Linux environment you can follow instructions provided on Microsoft's Development Network. To summarize:
Turn on Developer Mode: Settings | Update & Security | For Developers | Check the Developer Mode radio button
From the start menu, open “Turn Windows Features on or off”
Scroll down and check the “Windows Subsystem for Linux (Beta)” feature
Hit okay and reboot (required step)
Once rebooted, open a PowerShell/command prompt and run “Bash” and follow the simple prompts to accept Canonical’s license and kick-off the download of the Ubuntu image
After download has completed, you’ll be able to start “Bash on Ubuntu on Windows” from the Start menu
Be aware this method only works on Windows 10 and is still limited to text-mode console and a Win32 port of Xorg like vcXsrv for anything graphical. Cygwin or MSYS2 systems are not able to run ELF binaries, but make it possible to port and run the same applications that are normally ELF binaries on a Linux system.
To actually run executables and have them do useful stuff, you need to worry about the API, not just the executable file format. On a Linux machine with WINE installed, you can run Windows .EXE files from the command line and they do the same thing that they do on Windows.
The other way around is not really possible, however if you install CYGWIN on a Windows machine, and then rebuild the application from source with CYGWIN compilers, you will get an executable that runs on Windows and does the same thing that the Linux executable does on Linux. Lots of standard Linux tools are already ported and in the CYGWIN repository including stuff like X-Windows and GIMP.
http://lbw.sourceforge.net/ works better than line.
low was another project for doing the same thing, but that was the less working.
EDIT: http://atratus.org/ seems to do the same as well, without the need to have Interix/SFU.
COFF was originally introduced by UNIX (around System V or thereabouts) so yes, some UNIX probably still supports COFF format. It's been deprecated by Linux at least for a while, and presumably most other Unices have also deprecated or outright dropped support.
Windows ELF support is a bit more iffy - almost certainly not there without some deep trickery. You should be more specific about what you're trying to do here...
I was looking at some libraries with dumpbin and I noticed that all the 64-bit versions were linked to KERNEL32. Is there no KERNEL64 on 64-bit Windows? If not, why?
All my operating systems are 32-bit so I can't just look. A google search brings up nothing worthwhile so I suspect that there is no KERNEL64 but I'm still curious as to why this is.
EDIT: I found this later which is pretty useful. MSDN guide to x64
It's always called kernel32.dll, even on 64-bit windows. This is for the same compatibility reasons that system32 contains 64-bit binaries, while syswow64 contains 32-bit binaries.
On the 64-bit versions of Windows one of the "kernel32.dll"s contains 64-bit code but is still called kernel32.dll. This is at least misleading
Hope the following links will give the solution for this
http://www.howzatt.demon.co.uk/articles/DebuggingInWin64.html
http://www.viva64.com/en/l/0002/
http://blogs.msdn.com/b/aaron_margosis/archive/2012/12/10/using-ntfs-junctions-to-fix-application-compatibility-issues-on-64-bit-editions-of-windows.aspx
64-bit Windows provides such an environment "out of the box" and supports 32-bit applications using the 'Windows on Windows 64' subsystem, abbreviated to WOW64, which runs in user mode and maps the 32-bit calls to the operating system kernel into an equivalent 64-bit call. This is normally almost invisible to the calling program.Windows provides a set of 64-bit DLLs in %windir%\system32 and an equivalent set of 32-bit DLLs in %windir%\syswow64. In fact the bulk of the binary images in this directory are identical to the same files in the system32 directory on a 32-bit Windows installation. (It seems to me an unfortunate naming issue that the 64-bit DLLs live in system32 and the 32-bit ones live in syswow64, but there it is)
I'm migrating my development workstation from 32-bit Vista to 64-bit Vista.
The production platform is 32-bit Windows Server and SQL Server 2008.
Does anyone know of any issues with migrating the code base?
EDIT:
the system consists of web forms, c# code, stored procedures.
there is also ajax.net, ssrs, ssis, and dynamic reports/graphs from dundas.
however, i think other users might appreciate any lessons learned or feedback in general regarding this move.
FINDINGS:
As of Jan 24, 2009
Checkpoint VPN does not support Vista 64 (actually it seems that very few do)
Cropper utility required special download and rebuild to work on Vista 64 (Cropper looks very nice, but it lacks scrollable window capture)
The lack of support for Vista 64 made it not worth while for me. I wish someone would have mentioned the lack of VPN support, but there is currently no vpn vendor that supports 64 bit clients.... So be forwarned - as of 1/28/2009 - using Vista 64 is not a good option for those of us who need vpn.
I have done exactly this - migrated my workstation to Vista 64 whilst still deploying code to 32-bit Win2008 servers.
Generally, your biggest problem will be the WOW64 emulation layer - which means that 32-bit processes and 64-bit processes see different versions of the same resources (registry keys, system folders, and so on.) In .NET, there's an enumeration System.Environment.SpecialFolder which will give you safely abstracted access to Program Files, Application Data and other potentially risky system folders. You'll also need to force IIS to run in 32-bit compatibility mode (it can't run 64-bit and 32-bit web apps simultaneously) - instructions at http://support.microsoft.com/kb/894435
There's nothing insurmountable, though - I'm successfully compiling COM-visible .NET assemblies on Vista x64 (setting the compiler to target x86 CPUs), and then deploying them alongside ASP.NET and legacy ASP code running 32-bit COM objects on a 32-bit server, and it's all working very well. There's some notes you might find useful posted on my blog; biggest headache I encountered personally was that 32-bit applications (including my favourite text editor) can't see C:\Windows\System32 any more... but even that's easy enough to work around.
Don't use hard coded names for system folders.
(a bad idea anyway)
I have come across one issue with Vista 64:
Program Files
Program files may be stored in Program Files x86 or in Program Files you may have to code around this if any of your code makes assumptions about where programs are stored - even if you have done the right thing and used environment variables, as there are 2 locations there are now 2 different environment variables. You need to know which of these your app will be installed in, which will be different if you target any CPU from if you target x86.
I had much trouble with adding 3rd party 32 bit ISAPI handler to IIS on 64 bit w2k3 server (php) I had to make IIS run in 32 bit compatibility mode. If it's all managed I can think of no serious problem though.