Does MC work independently from OS libraries and kernel? - windows

Does the windows version of Midnight Commander (MC) work independently from Windows libraries? I mean does it have it's own way of reading data off the disk or is it using the OS's abilities?
If it's not independent do you know of any file manager that is? (Is it possible?)
Any help is greatly appreciated.

Only the windows kernel, and device drivers, can access the disks directly; all user mode programs must use the windows API (e.g. FindFirstFile).

Do you want MC to access the HDD controller directly? If no, you'll deal with Windows file system driver stack no matter what file manager you use.

Related

Add various multiboot options just like WinPE by Strelec on flash drive

So I've been wanting to put a windows 10 ISO on my flash drive, but I have WinPe by strelec already on it. I don't know how I can a windows installer on top of it and I don't even know if that's even possible at all... Please send help I'm a newbie when it comes to software
Unfortunately no, it is not possible to have multiple bootable OSes if something is already present, (at least to the extent of my knowledge) but if you'd like to dualboot on a clean USB drive, (erase your existing one, even) there exist several tools that can do that, such as Easyboot, syslinux, or even grub4dos. Some other helpful resources can also be found at Reboot.pro. However, if you are currently running Windows, I recommend WinSetupFromUSB as an easy way to get a multiboot USB drive going.
Yes It's possible just use ventoy and You can have multiple ISO's in the same usb, boot from USB and choose the want to boot, https: //www.ventoy.net/

Reading the EFI System Table in Windows

Is it possible to access the EFI System Table from the OS? I would like to know where the Runtime Services are mapped. The reason for this is that the Windows API only exposes the variable services to user mode (Get/SetFirmwareEnvironmentVariable), but I was wondering if it would be possible to use the rest of the services by accessing them directly in a custom driver. I know that the Windows loader is mapping the table containing the virtual addresses of the services into the kernel memory, but I have not found a way to locate and read it. Can somebody provide suggestions or directions on how to accomplish this goal?
A year old question but I will answer it and maybe it would help somebody else.
Long story short. No it's not possible. It's entirely Windows internals and if Microsoft doesn't expose it there is no way to access UEFI Run-time Services. As for the UEFI variables they are stored in a non-volatile RAM and only the UEFI firmware (BIOS) knows where all the variables are stored and how. So there are 2 possibilities either BIOS provides a way for Windows to get a pointer to UEFI Run-time Services or Microsoft has an agreement with BIOS vendors, like: - ok guys, if you want your systems to be compatible with Windows here it is the memory location where you must store the pointer to your UEFI Run-time Services period.
I saw programs writing to NVRAM using SetFirmwareEnvironmentVariable.

How do you programmatically detect dual booting (particularly Linux) from within Windows?

My dad is looking for ways to automate checking the settings of a Windows server for giving it a standards compliance grade. He needs to know if more than one OS is installed, but wants to avoid taking down the server at all costs. Is there any technique within Windows (XP and newer) for programmatically ascertaining whether a machine has multiple OSs installed?
It depends on what you consider "an installed OS".
At the very least you'd have to scan all partitions (including the ones Windows's limited filesystem support can't recognize) for filesystems and then see if they "look" like another OS. If you need to know if the alternate OS is bootable as well, you'll have to scan for boot loaders and their configuration as well.
By the way, what difference does it make if there's another OS installed on the computer?
Not entirely reliably. You could attempt to access the MBR and the partition table and sniff for evidence of the competition if you can persuade Windows to let you open the other partitions as raw devices. It would be a heap of work.
How about doing a checksum of the bootloader and comparing it against a known-good list of Windows OS bootloaders on the HDs?

Windows X Unix in USB communication

inHi, this question is fast, but from my point of view its pretty hard. I have been messing with implementing USB device built from MCU. So I found project called V-USB which is software-emulated USB interface for Atmel MCUs. But this is not so important.
The question is, on their site, they say that using custom USB class, you can simply write host software on Unix, but you need driver DLL for Windows. The problem is, they dont explain why.
So, please, why? I dont know Unix based systems, but I thought that the very basics of different OS are the same becouse thay rise from the same hardware, and even Unix cannot do HW IO operations from user mode.
I know about libraries for USB communication like LibUSB and so, but I want to know the very reason why thay say that its easy on Unix. Thanks.
EDIT:
Thanks for answer, but can I have further question? How this everything is a file works? I mean, my vision of driver on Windows is a program running in kernel mode, thus allowed to access CPU IO ports, which either provides functions to OS by some standarts, to allow Windows to use it (for example HDD driver must be accessible from filesystem driver by standardised set of functions, to allow any HDD work the same).
With this all you have to do is call drivers via WinAPI function or directly call its functions. But USB implements new feature which is different classes. So there is main USB root driver to handle USB and calling right secondary drivers for right devices. Than there is the same procedure, you just call your USB driver.
But if in Unix everything is a file, how are handled different classes? I just cannot imahine how this works in some analogy to Windows way. Does that file represents the way to communicate with USB root driver?
Everything in UNIX is a file, which supports simple operations. No matter if you are communicating via a terminal or a via a usb device, everything is a stream of bytes to a file.
* read
* write
* lseek
* close

How to create a "Block device" in Windows

For those familiar with Linux, it is possible to create a module and register it as a block device. This allows the user to mount it as a regular disk (while all the block I/O is handled by the module, e.g. USB mass storage).
Is there a way to do this in Windows ? (Need to create a volume mountable by Windows. The raw data will come from propriety interface).
The easiest way (and it's not easy!) is to write a Storport Miniport driver, you can even do this with KMDF as well. The latest issue of OSR's "The NT Insider" has an article on how to do this, but it's not going to be any kind of easy.
You will learn a ton though, so if you're interested in kernel development, this is a good way to get started!
You can find some simple block device drivers at http://www.acc.umu.se/~bosse/ . Look at the FileDisk driver, which is a Windows equivalent of /dev/loop
Take a look at the Truecrypt project. They have a pretty good implementation of a virtual block device.

Resources