We have compiled a fresh version of our software.
Yesterday we (accidentally) revealed that it is showing us different file (and product) versions depending on the machine you're looking at it.
If we look at it from the developer (virtual) machine it is showing the new file version. Even if it has not been compiled with "this" machine.
If we look at it from a host or different client it is showing an old version. It doesn't mind if you use the windows explorer or any different tool.
If you copy it from the virtual machine to the host - it magically changes its version.
The only OS difference between the Host and the VM is the language. The Host-OS is german, the VM-OS is english.
Has anybody an idea how this can be?
P.S.: Checked the files inside and outside the VM with a HexEditor and Resource Edtior and the new version number seems to be correctly in the file.
It showed up that the included resources had different versions for different languages. Didn't know that this is possible up to now.
Related
I have tried so many things. Literally taken me a week of trial and error. I managed to get the realtime firebase DB working but not the firestore as I can't call the command
composer require google/cloud-firestore
I have tried fresh installs 3 times for PHP and the other software. This really is not working. Why do I have to use this composer thing and them not just put a zip with all the relevant files inside?
With extension=php.dll in ini:
and changing to aboslute path surrounding extension, with and without .dll I have tried.
I've tried threadsafe and non threadsafe versions, and I also don't know what "1% is not a valid command" is. Also have tried x64 and x86 versions. The previous two images are x86 (which I assume to be 64 as my os is)
Here is an example of a x64 (I assume is 32bit) error. Procedure points cannot be found and it gives an error about entry points.
I have no idea what I did but I fixed it. To those reading this question just make sure in every place there is a php.ini they are the same directory!
Basically I have some C/C++ code that I need to build and debug on a Linux machine. Unfortunately, my windows laptop doesn't have enough free hard space to install some Linux dist nor does it have enough free RAM to comfortably run VM.
Until now, I dealt with it rather comfortably using WSL, but the scale was rather small. It was easy to edit and debug 2-3 .c files through CLI and gdb, but it became really annoying on a large scale projects.
I want something simple as "edit code in windows IDE [X], compile it on remote Linux/WSL (the project uses Makefiles), and preferably debug it via gdb".
VS has something close to what I want, but it can't deal with existing Linux projects. It needs to create a new configuration which is alien to the project's Makefile.
I know this question is a bit old, but I think the solution is to make a symlink between your WSL folder and the Window's folder. This is how I handled it for a Ubuntu-20.04 WSL:
Access PowerShell in Administrator mode
Type cmd.exe in the PowerShell
Once cmd.exe is opened, type mklink /d C:\<path_to_your_Windows_folder> \\wsl$\Ubuntu-20.04\home\<your_user>\<path_to_your_WSL_folder>
EDIT
This was tested under Windows 10 Version 2004 with WSL2
I'm unsure about C and C++ but it sounds like this is exactly the same as how i work in node and javascript every day.
I checkout my code using git inside WSL to a location like /mnt/c/code/myproject. Then using sublime/VS code/webstorm i edit the files in windows in the location c:\code\myproject this works really well and have been doing this every day for over a year.
Things to be aware of are that you need to ensure that your editor of choice saves files with linux line endings and that all command line operations are done inside WSL.
Please see this article to see the differences between windows and linux files and how this works inside the WSL.
I want something simple as "edit code in windows IDE , compile it on remote linux/WSL
You will have something as simple as that.
Only with Windows 19.03 though:
See "Updated WSL in Windows 10 version 1903 lets you access Linux files from Windows"
Microsoft's Craig Loewen says:
In the past, creating and changing Linux files from Windows resulted in losing files or corrupting data. Making this possible has been a highly requested and long anticipated feature. We're proud to announce you can now easily access all the files in your Linux distros from Windows.
So how does this work? He goes on to explain:
To put it briefly: a 9P protocol file server facilitates file related requests, with Windows acting as the client.
We've modified the WSL init daemon to include a 9P server. This server contains protocols that support Linux metadata, including permissions.
There is a Windows service and driver that acts as the client and talks to the 9P server (which is running inside of a WSL instance).
Client and server communicate over AF_UNIX sockets, since WSL allows interop between a Windows application and a Linux application using AF_UNIX as described in this post.
Warning:
The old rules still apply, you should NOT access your Linux files inside of the AppData folder!
If you try to access your Linux files through your AppData folder, you are bypassing using the 9P server, which means that you will not have access to your Linux files, and you could possibly corrupt your Linux distro.
Is anyone aware of a known issue (and workaround) where it seems like Rational ClearCase will corrupt a Microsoft Project file if it is checked out and the network connection changes? I have a laptop that is docked and hardwired to local network most of the time, and I perform some work with the Project file, then I will undock the laptop to go to a meeting or home for the evening, and upon re-docking, the Project file can no longer be opened and appears corrupt.
The error message shown is "Project cannot open the file. -Check that the file name and path are correct. -Check that the file format is recognized by Project..."
There doesn't seem to be anything directly related to Microsoft Project Server regarding ClearCase on ibm.com.
I have seen issues with dynamic views, when the view server is on the network (and said network is abruptly cut).
If this is your case, I would recommend using snapshot views.
You can have similar issue with ClearTeam 8.x web views (since the latest versions support dynamic views)
Regarding snapshot views (meaning files directly on your hard drive), you only need to watch for concurrent processes that might still access your file when undocking. A program like procmon can help.
I am running my development environment Windows XP. I need access to the function SHGetKnownFolderPath. My team proposes that I simply update my shell32.dll with theirs and update my header files.
The function is documented here:
http://msdn.microsoft.com/en-us/library/bb762188%28v=vs.85%29.aspx
Now, understand that the focus of this question is on the viability of overriding/updating the shell32.dll manually via copy-paste. Please do not respond with workarounds/alternatives to the function mentioned above. That is not the point of this question.
Is it safe to simply take the Windows 7 version of shell32.dll and paste over mine (in XP)? I am afraid to test that for fear of murdering my entire operating system. I do not know all of Windows' library inter-dependencies and whether this would even be compatible. It sounds incredibly unstable, but that is what is being proposed I do.
You should not change a Windows DLL manually. A Windows 7 DLL will have dependencies that will not resolve on XP. Even if this worked (very unlikely), next time you install a patch from Windows Update it may either break due to dependencies or replace your Windows 7 DLL back to XP version.
UPDATE: This just won't work. The Windows 7 DLL has dependencies on API sets which did not exist in XP.
Copying manually the dll via copy-paste will not work, because WFP will kick in and restore the original dll. IIRC only digitally-signed updates from Microsoft are allowed to replace system dlls on a running system to avoid messes like this. You should replace the file offline (e.g. from another copy of Windows/BartPE/Linux/...), or disable/workaround WFP in some way. So, it's not practical.
Taking a system dll from another version of Windows and copying it there seems like a terrible idea. The shell changed a lot from Windows XP to Windows 7, I'm sure that there will be a lot of missing dependencies. Even if you managed to copy every file of the Windows 7 shell to Windows XP, these files would depend from newer user32/gdi32/ntdll/... functions added in Vista and 7, so it would not work anyway.
So, I think that the most probable consequence of replacing shell32.dll would be the failure to load almost any non-core component of the OS: failing shell32.dll to load due to missing dependencies, almost any GUI executable that links against it would fail to start. So, it's not safe.
Other than being a problem from a technical standpoint, I strongly suspect that it's also illegal. Having a license for both Windows XP and Windows 7 would not help, I think that this is considered "modification of the software product", that is explicitly disallowed by the Microsoft EULAs. So, it's not legal.
If you want backwards compatibility with XP just use SHGetFolderPath instead of doing all this mess.
Is it safe/practical to manually update shell32.dll in
Windows XP?
No.
shell32.dll is a core operating system file. I would expect that minus the other dependencies underneath the Windows 7 version you would have all sorts of unexpected behaviors. It would be better to test within a VM a complete Windows 7 environment rather than copy over a part of another version of an operating system.
Bigger questions: Do you think anyone at Microsoft every tested this exact combination? If you run into issues and you call support do you believe that you will find that your configuration is a supported one for your efforts? Having worked for MSFT in the past I would think that the answer to both is likely not.
Probably they know what they're saying. Anyway I would suggest you creating a system restore point and, just in case, downloading a minimal linux distribution so that, in extreme cases (i.e. windows can't boot), you simply restore their shell32.dll with yours.
I don't think so...
But if still want to try, then i suggest you install a virtual machine and try it there. this way much safer.
The site, http://sqlite.phxsoftware.com/, talks about a mixed-mode assembly and a managed-only version of the provider. Are they both named System.Data.SQLite.dll? I installed the managed-only version in windows and it is working. Which, as I understand it, means that I must also have the native sqlite3.dll file somewhere on my machine that it is finding, right?
When I try to get my assembly to run on Linux with Mono, I get an EntryPointNotFoundException looking for sqlite3_open_v2. So I downloaded the precompiled shared-library for Linux without the TCL bindings from http://www.sqlite.org/download.html and placed it in the same folder as the other assemblies. But that didn't change anything.
The page at http://www.mono-project.com/Interop_with_Native_Libraries says Linux will look at my LD_LIBRARY_PATH environment variable. So I set that to contain '.', the current directory. That didn't work either.
So then I copied sqlite-3.6.19.so to sqlite-3.so, sqlite3.so and sqlite.so. Still no change.
What am I missing?
Instead of using System.Data.SQLite.dll on Windows and Linux, I decided to use Mono.Data.Sqlite.dll on both sides.