An application that has been running just fine with Windows XP and Windows 7 suddenly developed problems with Windows 10 Pro. However, with Windows 10 IoT Enterprise, it seems to work fine. It also seemed to work fine back in May of 2018 with Windows 10, yet with newer installs of Windows 10, it doesn't work.
After some investigation, we found that the application seems to be unable to create the set of files that it uses for persistent data with Windows 10 Pro.
Looking further, we found that the complete pathname was incorrect. It appears that the pathname to the directory where files were being stored, though not properly constructed, worked fine with Windows XP and Windows 7, but not with Windows 10 Pro.
The pathname being generated looked like this (those are path backslashes and not C/C++ backslashes for escaping a character):
\C:\DirA\DirB\DirC
while the corrected pathname being generated looks like this:
\\.\C:\DirA\DirB\DirC
Reading MSDN's article on Naming Files, Paths, and Namespaces, I am a bit confused about what appears to be a number of different ways that a valid pathname can be constructed. It appears that different Windows filesystems (FAT16, FAT32, NTFS, etc.) have different naming conventions.
What is the pathname format I should use so that my application will be able to create and open files in a specific directory on a local drive C: with multiple different versions of Windows? I am specifically interested in Windows 7, POSReady 7, Windows 10, and Windows 10 IoT Enterprise (which is not the same as Windows 10 IoT).
I am using the Win32 API CreateFile() function to create/open the files.
What is the pathname format I should use so that my application will be able to create and open files in a specific directory on a local drive C: with multiple different versions of Windows?
You should be using:
C:\DirA\DirB\DirC
Or, if you need to access a pathname longer than MAX_PATH, and don't/can't opt in to the new longPathAware feature introduced in Windows 10 version 1607:
\\?\C:\DirA\DirB\DirC
DO NOT use \C:\DirA\DirB\DirC, this is not correctly formatted.
You should not need to use \\.\C:\DirA\DirB\DirC, though it will work. Just be aware that:
The "\\.\" prefix will access the Win32 device namespace instead of the Win32 file namespace.
Typically, you would use \\.\ only when accessing local devices, like physical volumes, serial/parallel ports, named pipes, mailslots, etc. Not when accessing entries on the file system.
Related
I like the idea of Windows applications that run regardless of which folder they are in and which don't use the registry for settings but use local files instead.
This allows such applications to be stored on any disk or even a USB drive, which can be used on different computers while behaving the same way. That's the basic principle of PortableApps.
An additional bonus is that no administrator rights are needed for the installation, since there is no installer.
However existing applications are often already written to use the registry.
Is there a C library that can be used to build these applications from (C/C++) source code with minimal changes which redirects all registry access (read and write) for at least the application's settings to a file on disk (relative to the running application or library)?
I guess it shouldn't be that hard using #define to redefine all Windows API calls to registry functions.
Then it would just be a matter of the right #include in the right place and linking to an additional library.
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.
I have a legacy VB6 system which is installed in C:/Program Files/IronDuke
In the past it has written some files into this directory. I understand that these files are hidden away if the application is installed under Vista or a later OS, but not if they were written under XP or earlier OS.
How can I retrieve a copy of these 'hidden' files when written under Vista or Windows 7 or 8?
You are looking at a feature called UAC Virtualization, this blog posting gives a pretty good rundown on what is happening and where the files are located.
From above article:
For example, if an application attempts to write to C:\Program Files\Contoso\Settings.ini, and the user does not have permissions to write to that directory (the Program Files), the write operation will be redirected to C:\Users\Username\AppData\Local\VirtualStore\Program Files\Contoso\settings.ini. If an application attempts to write to HKEY_LOCAL_MACHINE\Software\Contoso\ in the registry, it will automatically be redirected to HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso or HKEY_USERS\UserSID_Classes\VirtualStore\Machine\Software\Contoso.
so in your case if you are trying to find the files you need to look in:
C:\Users\Username\AppData\Local\VirtualStore\Program Files\IronDuke\
You cannot write to Program Files under Windows 7 / 8 - system security prevents programs running as regular users from doing so. One option for you is to write these files to the user's profile folder (you'll have to update the VB6 program for this, although the changes should be pretty small if the program is otherwise well-written). This would be your best option since the updated code would work well in the future without more changes.
You amy be able to get the program running using Compatibility Mode but I doubt it - on my Windows 8 system I don't even get 'Windows XP' as a compatibility option anymore. All other options will likely enforce security.
You can try running your program as administrator but I'd only do this if you don't have the source to make the changes - it's poor practice to run programs with all privileges since it opens up the system for attacks.
I currently have many Linux VM's set up on VMware Workstation, there are some shared folders that contain source code that is held on the host computer. The issue I am having is that whenever I try to compile a file by using any compiler I get an Illegal seek error and file not recognized. Is there any way around this? I am using an Ubuntu 64-bit VM with Windows 7 as the host and the location of the shared files are on the Windows 7 hard drive.
I've run into a number of problems doing development over a network share in the past and suggest rather than sharing the files via SMB, you'll find more luck if you check in/out the files from a source control system (or simply copy them) so they're on a "local" drive on both the guest and host.
I'm trying to port an application written in C from linux to windows.
At the moment I'm done fixing the 'hard' parts like missing posix features and the like.
The application compiles, links and works on Windows now (except for the fork() stuff which will be replaced with windows service code later).
The only problem I'm having now is that within the MSYS shell it all works (this maps unix paths for me).
Outside of the MSYS shell it won't work because ~ is not available.
I'm looking for the best way to set the windows user home within my #ifdef stuff.
I read about %USERPROFILE% somewhere but that doesn't seem to work.
Use SHGetKnownFolderPath (Vista+) or SHGetFolderPath depending on your Windows version.
I think you should use the SHGetFolderLocation API:
http://msdn.microsoft.com/en-us/library/bb762180%28VS.85%29.aspx
well not enought, you should even retrieve the ID of the user folder, but by starting at the doc location above you should have all what you neeed.
This should works on any windows version.