I'm asking and answering my own question to find the answer later (and to help anyone stuck using the ancient Borland C++ 5.02 compiler for some reason).
I have Borland C++ 5.02 installed in a 32-bit Windows XP virtual machine, with a BC++ project residing in a folder shared with the host computer (mapped to drive letter H: in the VM). The project compiles successfully, but always fails the final step with this message:
Could not load: tlink.exe
My compiler is installed in the usual C:\BC5 location in the virtual machine, but it turns out that it can't handle project folders on paths that contain spaces in their names. So I copied the project from that shared H: drive to C:\BC5\[project] and voilà! it compiles and links with no problem. I've also copied the project folder to my virtual machine's root C:\ and that works as well.
Related
recently I started to use WSL & vcpkg, but it has some problems when mixing windows + linux development.
It seems like that installing Linux packages or Windows packages with vcpkg, mutually damage the vcpkg configuration and then vcpkg roughly says: "the package you want to install doesn't exist". (I know for sure that it exist)
If it matters, the project is located in the windows "world" so the WSL directing to it with /mnt/c/Users//workspace/proj1
but it really doesn't matter.
Does Anyone already encountered this problem?
Am I doing something wrong?
Is there a better way to develop a cross-platform project?
Thanks
So I post it to help anyone who have doubts about it:
Don't mix WSL project with windows project because it will force you to work on the windows filesystem from WSL. (WSL can work on the windows filesystem with /mnt/)
anyway, It will both corrupt the vcpkg and the overall compile times will be horribly slow from linux filesystem (usually ext4) to the windows filesystem (NTFS).
this is my original post in the Github:
https://github.com/microsoft/vcpkg/issues/13948#issuecomment-706625438
Where do you store your thirdparty libraries and header files to when developing C/C++ on Windows?
When developing on Linux the package managers usally installs thirdparty libraries to /usr/lib and /usr/include. So I know where to look for.
I am just starting to develop on Windows and made the mistake to install libraries to C:\Program Files which is a bad idea due to UAC and permission lookdown on Windows 10.
Is there some kind of best practice? Thanks in advance
Usually to one of these locations:
Commercial tools might have an installer and if so the location is indeed often Program Files [ (x86) ]
Libraries built from source (for example zlib for compression) go wherever you have your root folder for C++ projects. Using Visual Studio you might have a C: > VS17 folder with one sub-folder for each solution and each partner library. You then reference the H and LIB files using relative paths like ../../other-libraryname/include so that they will work if you move the VS17 library to a new drive or change its name.
In both cases, when building a setup package for deploying to another PC, you typically include only DLL files and code statically linked into your own EXE, you don't include H or LIB files. The default installation location for the setup will be Program Files, but if your third-party library includes COM objects they might recommend installing them to the Windows system32 folder.
I want to create a 32bit executable app from my script to run on Windows 10 with X86 or X64 architectures. I've generated the X64 version of my script and it worked fine. My host machine is X64 but I installed Python X86 version to generate X86 app. Then I generated the executable with Pyinstaller but when I run the executable it throws the following error:
C:\Users\Name\Appdata\local\Temp_MEI51162\VCRUNTIME140.dll is
either not designed to run on Windows or it contains an error...
and in the console I see this error:
Error loading Python DLL
'C:\Users\Name\AppData\Local\Temp_MEI51162\python36.dll'.
LoadLibrary:
I've checked the _MEI51162, both VCRUNTIME140.dll and python36.dll is there but the python36.dll has a size of about 1 MB instead of 3 MB. It doesn't matter if I generate the app as a standalone executable or not and still give me the same error.
It seems that the problem happens when you install both 32bit and 64bit of PyInstaller. And PyInstaller would fail on selecting which version of dependencies are required for the current build. The problem in my situation was VCRUNTIME140.dll. I couldn't find a way to replace the vcruntime140.dll, but I found a workaround by adding the correct file manually to C:\Users\<User>\AppData\Roaming\pyinstaller directory and rebuild with Pyinstaller then It will be replaced with the new one just copied. This will fix the issue temporary and the directory should not be deleted.
Investigating the bit width of DLLs on my Windows 10/64 bit box with Visual Studiop 2013 installed.
dumpbin /headers C:\windows\system32\msvcp120.dll | findstr machine
reports: 8664 machine (x64)
but
cd C:\windows\system32\
dumpbin /headers .\msvcp120.dll | findstr machine
reports:
14C machine (x86) 32 bit word machine
I've tried it on several machines with the same result. What's going on ?
This is the file system redirector at work, always active on a 64-bit OS when you look at the c:\windows\system32 directory. You are actually looking at c:\windows\syswow64\msvcp120.dll, thus the machine type is x86. Caused primarily by running the 32-bit version of dumpbin.exe, like most users would. Only the 64-bit version (vc/bin/amd64 directory) does not get redirected.
I was puzzled a bit and discovered one aspect of the redirector I did not know before. It redirects only relative paths. So .\msvcp120.dll or ..\system32\msvcp120.dll. But not a full path, like c:\windows\system32\msvcp120.dll. Drive letter is not actually important.
I'm creating a InstallShield 2012 Spring project, and I need to copy some jpg into System32 subfolder.
In Application Data/Files and Folders, I put that into [WindowsFolder]/System32/akrmf and when install, it copies to SysWOW64/akrmf on Windows 7
The installation project doesn't include any exe or dll, only text files and images.
I tried using [SystemFolder] and copies into SysWOW64 too.
Is there any way to force installation into System32/akrmf folder ?
Thanks
To target the true (64-bit) system folder with Windows Installer, your MSI needs to be a 64-bit package (see Targeting 64-bit Operating Systems). Unfortunately this prevents it from installing on 32-bit systems.
To do this with InstallScript, there are related approaches that do not require creating two separate packages, but you may find it easiest to create two different components where only one is selected for installation.