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.
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.
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.
This is by no means a "give me the solution" question, but more to gain a higher understanding. Please feel free to point to references where I can learn more about this, I've tried searching and all I get are how to's for setting up and accessing network drives.
I want to be able to monitor a file on a windows machine, but the file sits on a shared drive hosted locally. If it is manipulated by another machine, is there a process I can look for that will indicate that the file may be accessed by a resource elsewhere on the network? I understand that the host machine must be available in order to access the file in the first place, but what processes are called to actually manipulate the file. Is this below the OS level? I have access to a minifilter driver that I can ask a more experienced developer on the team to help me with if need be.
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'm new in kernel mode world. I've tried to write a simple "hello world" driver in a Windows 7 virtual machine, I'm using WDK 7600.16385.1 -> x86 Free Build Environment for compilation, when it does, the generated driver is a .sys file extension, so I'd like to know if is possible to set up the compiler to generate an .exe file, so thereby a user can run it by double-clicking the executable.
I thought that perhaps, when I install some driver and the "setup" is a .exe file, in fact it isn't really the driver, it is a program that installs the driver (in .sys extension) on your computer, so the .exe file is just the installer and not the driver itself. But I am not sure if this is true.
If you could give me some information about generating a driver for Windoes, I'll be eternally grateful!
Thanks in advance!
The .exe files you're looking at are, indeed, installers. There are a number of tools available for creating installers; NSIS is one of the more popular options.
.exe marks executable files for Windows user mode. The format of user mode and kernel mode "executables" differs a lot. In particular, there is no such thing as user running the kernel executible. Kernel drivers aren't directly accessible to user mode; communication is allowed only via OS-defined interfaces, i.e. user-mode component must perform a dedicated OS call which will be routed to the kernel component by the OS. There are many more differences between kernel and user modes but this particular one explains why running kernel driver by user isn't possible (and shouldn't be).
As for your second question, yes, these .exe files are installers.