billziss

Thank you. This looks exactly like what I had in mind.

EDIT: Another alternative would be to be able to slide the main screen halfway to the side thus allowing a second screen next to it for a dual screen setup.

Just wrote something similar. I agree.

I would much prefer it if manufacturers created a multi-screen setup with screens next to each other. I can imagine some form of folding or attachment mechanism that converts a single screen laptop to dual or triple screen. Since going "laptop only" many years ago the thing I miss the most is the multi-monitor setup that I used to have and would love it if I was eventually able to recreate this with my laptop.

The idea of a second screen above the keyboard does not appeal to me. I have a Macbook Pro with a touch bar and in general I dislike it (even though I have written a custom dock for it, which allows me to reclaim some main screen real estate from the macOS Dock). I understand that this new MSFT screen is bigger and potentially more useful, but the problem of having to look down on the second screen above the keyboard would still be there.

(I am aware of macOS Sidecar.)

I use the refcount to avoid copying the string when passing it around. I just refcount it instead.

To clarify this is part of a larger library that includes other memory management machinery, such as autorelease pools, etc.

These days my work is focused on kernel/systems programming, so plain C (char or wchar_t) strings outside the kernel, and whatever the kernel requires inside it (e.g. UNICODE_STRING on Windows).

When I do apps I have my own length-prefixed variant.

I do not think I have ever seen a string that needs more than 64K, but then again I do not read whole files in memory in C. (I do in Python.) So this would be wasteful in many cases.

My personal variant uses 32-bits for length and 32-bits for refcount, which aligns well on most platforms, including 64-bit ones.

Something like:

    struct string_header
    {
        int32_t refcnt;
        int32_t length;
        // character content starts here
    };

Given a char pointer to get to the header you must do:

    ((struct string_header *)p)[-1]

While I often implement strings along the lines you suggest I disagree that this feature belongs in the standard library. For one thing how big (sizeof) should the length prefix be? 16-bits? 32-bits? 64-bits?

The beauty of the C string is that it is minimal and straightforward: if you have a pointer to it, you know where it ends. And it works with pretty much any OS out there.

(My personal variant of dynamic strings are refcounted, length prefixed and nul-terminated with the pointer pointing to the traditional C string.)

> But that would require them to implement a new file system from scratch wouldn't it? VolFs in WSL1 relied on NTFS to do the heavy lifting.

You are correct.

Perhaps you are right, but to me this feels more like Microsoft hedging their bets, rather than a genuine interest in having two parallel products doing effectively the same thing (from a user perspective).

I asked the same question on their GitHub issues: https://github.com/microsoft/WSL/issues/4022

But is it really just "aggregation"?

https://www.gnu.org/licenses/gpl-faq.html#MereAggregation https://www.gnu.org/licenses/gpl-faq.html#AggregateContainer...

I do not know, but I can see arguments on both sides. This is why I would love to hear the opinion of the FSF on this.

I think I agree with your overall understanding. It would be interesting to learn what FSF's position is regarding WSL2.

> They reference the concept of open file handles and moving folder structures.

I think this comment may have been disingenuous on their part. The reason is that this problem more than likely still exists in WSL2 for the /mnt/c, /mnt/d file systems (i.e. what they used to call "DrvFs" in WSL1).

WSL1 comes with (at least) 2 file systems. "VolFs" which is the file system that they use for the Linux root file system and "DrvFs" which is the file system that they use to access Windows drives (C:, D:, ...).

In WSL1 VolFs was implemented as a layer on top of NTFS, so it comes with all the Windows file system and NTFS baggage. In WSL2 they will replace this file system with a native ext4 formatted partition on a VHD file, thus eliminating the Windows I/O stack (except for READ/WRITE I/O to the VHD file).

My contention is that they could have instead replaced VolFs with a native WSL1 file system that uses a disk partition or VHD as its backend storage, thus eliminating the Windows I/O stack in the same way. They could then have implemented proper Linux file system semantics without any baggage.

> I think they found the boundary of OS research in this case

Unlikely. It would not surprise me if the changes we are seeing are less technical and more political.

Which systems do you think are more similar: Windows and Linux or FreeBSD and Linux?

Presenting a Linux syscall interface on top of Windows is a hard task. The systems have fundamentally different approaches to many OS functionalities. In general you cannot just 1:1 map syscalls between the two. I am very familiar with the Windows kernel and fairly familiar with the Linux kernel and I am 100% convinced of this.

This is not to minimize the FreeBSD achievement. However I expect that mapping from Linux to FreeBSD and back would be an easier task. I should note here that I only know generalities about the FreeBSD kernel and would be willing to be educated if that is not the case and done in good faith.

Yes, I am aware of the Linux emulation in FreeBSD and elsewhere.

Although many people seem to be receiving the WSL2 news well, I am one of the few that feels that we will be missing something important with this new direction.

WSL1 was pushing the boundaries of OS research: - a method for having multiple syscall interfaces in a mainstream OS - processes in WSL1 were real NT processes (even if lacking some of the NTOS environment) - direct integration with the rest of the OS without an awkward VM separation layer.

In comparison WSL2 is basically an optimized VM with some fancy guest additions. Color me underwhelmed.

I understand the argument that WSL2 is faster than WSL1 in file system operations. I expect this will only be true for their root file system ("VolFs") and that performance will remain same or suffer for Windows drives ("DrvFs"). I am certain that they could fix "VolFs" performance by moving the file system of NTFS and into a raw disk partition or VHD. (Note: I write file systems both in and out of kernel.)

Finally WSL2 will be distributed with Windows which raises some licensing questions (IANAL) if not in the letter of the GPL license at least in spirit. I write GPL'ed software myself and I would be somewhat miffed if I saw my software used in a similar manner (i.e. "via a VM", but still distributed with non-GPL code).

WinSpd is not a standalone application, but rather a set of libraries and components that allows others to create applications that can do what you want (serve a disk over a network).

The included sample, called rawdisk, memory maps a file and uses it as a disk image file. This could presumably be done over SMB or NFS, although I have not tested the performance.

I think it is a perfectly legitimate question. I had two reasons for creating this: a practical one and a theoretical one.

The practical one is that I wanted to be able to store disk data in a cloud storage bucket (i.e. "format" a bucket with NTFS and use it as a disk). For various reasons I did not want to build this as a WinFsp or FUSE file system.

The theoretical one is that I am exploring the possibility of writing a new OS where all/most IO/services/etc. could be implemented either in kernel mode or user mode. Not bolt it onto an existing OS like I have done with WinFsp and WinSpd, but build the OS like this from the ground up.

To finish here are some use cases for WinSpd as food for thought:

- Mounting virtual disks in a format other than VHD.

- Mounting a cloud storage bucket as a disk.

- Serving a read-only disk from an internet location for use by multiple users.

- Tracking disk I/O for backup, snapshotting or other purposes.

Thanks for the additional information :)

Sorry for the second reply, but I read a bit about ImDisk.

I think the main difference is that WinSpd is a general tool for creating disks as user mode processes, whereas ImDisk is a tool for mounting image files only.

It looks like WinSpd is a more generic tool. But I know very little about ImDisk so I may be mis-representing it.

Interesting. I was not aware of ImDisk. Reading about it, it appears to be a RAMDisk only tool. Did I misunderstand?

Yes. Async I/O in Windows happens at the file system level, so the answer is yes, by default.

Command queues are supported by default as well, as this is a Storport virtual miniport driver (which supports command queues).

Thanks.

Here is the most updated version of those documents:

https://github.com/billziss-gh/winfsp/wiki/WinFsp-Testing

Agree. The Projected File System is very limited compared to WinFsp, Dokany or CBFS. I have looked at it quite extensively as my own WinFsp open source software is in the same space.

Dokan and CBFS are more like WinFsp (another project of mine) in that they allow you to create file systems rather than "disks".

I like to think that WinFsp is very stable software. I am working to bring WinSpd to the same levels of stability.

Good question. Unfortunately I do not know enough about iSCSI to answer this question fully.

In my case I wanted a simple way to create "SCSI disks" using a user mode process. Since I had already created WinFsp, which has a solid IPC (Inter-Process Communication) protocol, this felt like the best way forward.

WinFsp allows you to create file systems. This project allows you to create disks that can be formatted with existing disk file systems (e.g. NTFS).

They both have their uses but in general I think WinFsp is more useful for most.

I am not familiar with ImDisk.

- Be enthusiastic about learning! - Focus on creating something that scratches an itch of yours.

I am the WinSpd author. Feel free to ask me any questions you may have.

Of course. I can see a couple of ways that this can happen:

- P/Invoke. - Recompiling the library in C++/CLI mode.

I am the author of WinFsp. Please let me know if you have any questions.