Winsock Kernel (WSK) Interface for the VIOSOCK Driver #835

MartinDrab · 2022-10-02T21:08:25Z

This pull request introduces WSK interface for the Socket driver. That allows to take advantage of the driver (and communicate with other virtual machines and the hypervisor through AF_VSOCK) also directly in the kernel.

Starting Windows Vista, Microsoft implements WSK interface for AF_INET and AF_INET6 address families. The interface provides similar functions to WinSock2 known from the usermode (well, the word similar needs to be relaxed a bit). Support for AF_VM allows the user, in theory, to easily reuse kernel code communicating over a network.

Limitations

Aim of this PR is to provide sort of a basic implementation of the WSK interface for AF_VSOCK, without any changes to the Socket driver code. This means that some WSK calls and features are NOT implemented yet.
The following WSK calls are not implemented

WskListen, (WskBind on a listening socket does the trick),
WskConnectEx (the same as WskConnect + WskSend),
WskSendEx,
WskReceiveEx,
WskSocketConnect (same as WskSocket + WskBind + WskConnect),
WskControlClient.

Also, socket event callbacks are not working yet. Their implementation possibly requires some changes to the Socket driver code, thus, I decided to possibly do that in a later PR. These callbacks can be used to notify the user about an incomming connection or of newly arrived data.

This is still a WORK IN PROGRESS, some formatting needs to be altered and some descriptions added. It will be finished this Monday or Tuesday.

YanVugenfirer · 2022-10-03T06:53:05Z

@MartinDrab Thanks a lot for sending the PR. I am going to review it.

Quick comment - please add "Signed off by" to commit message (you can do it automatically to using "-s" command line option for git commit command). Please use your real name.

YanVugenfirer · 2022-10-03T07:52:36Z

Can you also please add a page for virtio-vsock in the wiki: https://github.com/virtio-win/kvm-guest-drivers-windows/wiki

If possible add following:

QEMU command line
Architecture on Windows and outline different components
Installation
Usage examples.

Thanks a lot!

MartinDrab · 2022-10-03T18:40:19Z

Yes, I will add some documentation related to the WSK interface nad its current limitations. I will work on it tomorrow.

YanVugenfirer · 2022-10-06T11:28:51Z

If trying to compile from the solution that is found in the driver directory, compilation fails (tried to compile with Win8 and Win10 Release | x64" configurations.

4>Generating Code...
5>C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\viosockwsk-test.c(39,25): error C2220: the following warning is treated as an error
5>C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\viosockwsk-test.c(39,25): warning C4100: 'Irp': unreferenced formal parameter
5>C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\viosockwsk-test.c(38,25): warning C4100: 'DeviceObject': unreferenced formal parameter
5>C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\viosockwsk-test.c(472,17): warning C4100: 'Context': unreferenced formal parameter
5>C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\viosockwsk-test.c(670,22): warning C4100: 'DriverObject': unreferenced formal parameter
5>Generating Code...

YanVugenfirer · 2022-10-06T11:29:01Z

What about ARM64 support?

YanVugenfirer · 2022-10-06T11:37:47Z

viosock/inc/debug-utils.h

+
+#if defined(DBG) || defined(_DEBUG)
+
+#define DEBUG_ENTER_FUNCTION(Format, ...) \


Why not use existing debug printing infrastructure that depending one configuration will use different debug print methods?
Checkout: InitializeDebugPrints and VirtioDebugPrintProc

YanVugenfirer

LICENSE file should be present in the directories of the new binaries, similar to "sys" and "lib" directories.

YanVugenfirer

There are several ways to build the drives.
For developers: you can use solution in each of the drivers directories (btw: doesn't work for me)
For release and CI: build every binary from the solution in the root directory. Currently wsk project is missing from this solution.

YanVugenfirer · 2022-10-18T11:24:19Z

+1 for additional commits

MartinDrab · 2022-10-18T12:32:36Z

+1 for additional commits

Yes, I am still working on it. I hope to finish the PR on this week's end.

YanVugenfirer · 2022-12-22T12:37:04Z

Hi @MartinDrab,

If you are going to make additional changes to viosock driver, can you please take a look also on:

Thanks,
Yan.

YanVugenfirer · 2023-01-26T08:31:54Z

@MartinDrab Are you planning to submit additional changes to PR? Currently, it needs rebase.
What else is missing?

Best regards,
Yan.

MartinDrab · 2023-02-19T14:44:53Z

@MartinDrab Are you planning to submit additional changes to PR? Currently, it needs rebase. What else is missing?

Best regards, Yan.

Yes, I will rebase and finish this PR soon (I hope). As far as I remember, the only thing that is missing is adopting WPP tracing for debug prints (in the past I was always using DbgPrintEx).

I suppose I will finish this PR once we release and WHQL-sign new driver versions.

YanVugenfirer · 2023-02-21T09:34:33Z

@MartinDrab Are you planning to submit additional changes to PR? Currently, it needs rebase. What else is missing?
Best regards, Yan.

Yes, I will rebase and finish this PR soon (I hope). As far as I remember, the only thing that is missing is adopting WPP tracing for debug prints (in the past I was always using DbgPrintEx).

I suppose I will finish this PR once we release and WHQL-sign new driver versions.

Thanks for the update!

YanVugenfirer · 2023-03-27T07:13:50Z

Hi @MartinDrab

The compilation fails for viosock-wsk-test. Please add "sha256" in "File Digest Algorithm" under "Driver Signing"->"General".

Thanks,
Yan.

These macros will be used mostly when entering into or exiting from a function, sending routine name nad values of its arguments to a potential kernel debugger. These macros are NOPs on Release build, however, their usage can be invaluable when debugging driver crashes. Signed-off-by: Martin Drab <[email protected]>

…iderNPI Unlike the Windows WSK implementation, this library needs to be initialized through VioWskModuleInit before calling its WsRegister equivalent. This approach allows the client driver to provide the library with an optional device object that is then used to prevent IRP completion routines and workitems used by the library to execute after the device deletion. If the client application decides not to provide such a device object, the library can live with it but no unload protection is then enforced. Also, the client driver must provide pointer to its DRIVER_OBJECT which is used during WskCaptureProviderNPI to connect to the VIOSOCK driver. Instead of having the VIOSOCK device name hard-coded, the library takes advantage of IoRegisterPlugPlayNotification to search for the GUID_DEVINTERFACE_VIOSOCK device interface (which is enabled by the VIOSOCK driver) dynamically. Signed-off-by: Martin Drab <[email protected]>

Implements WskGetAddressInfo, WskFreeAddressInfo and WskGetNameInfo which can be used to translate AF_VSOCK addresses between their string and binary forms. Also, some necessary logic for IRP processing is being added as well. This is necessary because the WSK interface uses IRPs to signal the client driver that certain WSK operation was completed. Apart from that (and from providing operation results in their `IoStatus` field), IRPs are not used by the interface (they carry neither operation information, nor data associated with it). It is worth to note that the whole concept of address translation is not that useful for AF_VSOCK since there are no such things as DNS servers and domain names. ref: [WskGetAddressInfo](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_get_address_info) ref: [WskFreeAddressInfo](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_free_address_info) ref: [WskGetNameInfo](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_get_name_info) Signed-off-by: Martin Drab <[email protected]>

Signed-off-by: Martin Drab <[email protected]>

Most of the work done by this WSK implementation consists of packing client driver's calls into IOCTL and read/write request and passing them to the VIOSOCK driver. This commit introduces routines for creating IOCTL requests and sending them to VIOSOCK. Also, a concept of WSK Completion Contexts is introduces. The purpose of these contexts is to transfer information between code sending IRPs and their completion routines. Also, these contexts can be used to implement one WSK interface call as a sequence of requests to the VIOSOCK driver. Signed-off-by: Martin Drab <[email protected]>

The library implements this call by forwarding it to the VIOSOCK driver as an IOCTL_SOCKET_GET_SOCK_NAME request. ref: [WskGetLocalAddress](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_get_local_address) Signed-off-by: Martin Drab <[email protected]>

The library implements this call by forwarding it to the VIOSOCK driver as an IOCTL_SOCKET_GET_PEER_NAME request. ref: [WskGetRemoteAddress](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_get_remote_address) Signed-off-by: Martin Drab <[email protected]>

Unlike the standard WSK interface (TCP/IP etc.), AF_VSOCK does not require to call WskBind before WskConnect. This also holds for the connect() call in usermode. The client driver can use VMADDR_CID_ANY to connect to loopback. ref: https://www.bing.com/search?q=wskconnect&cvid=6a21f40a81d8444a886dbae1cbb54e09&aqs=edge..69i57j0l8.1546j0j1&pglt=2083&FORM=ANSPA1&PC=U531 Signed-off-by: Martin Drab <[email protected]>

The implementation supports both synchronous (Irp == NULL) and asynchronous (Irp != NULL) modes of operation and can be used to get/set socket options and send IOCTLs. ref: [WskControlSocket](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_control_socket) Signed-off-by: Martin Drab <[email protected]>

Routines for building IRP_MJ_WRITE and IRP_MJ_WRITE IRPs are also par of this commit since the VIOSOCK driver implements send/recv operations through these requests. It is also necessary to deal with the fact that the WSK interface transfers send/recv buffers through WSK_BUF structures, very similar to WSABUF in usermode, that support MDL chaining. Since the VIOSOCK driver does not support MDL chaining, the WskSend initiates a sequence of IRP_MJ_WRITE requests, one for each MDL in the chain. ref: [WskSend](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_send_to) Signed-off-by: Martin Drab <[email protected]>

Since the VIOSOCK driver does not support MDL chaining, one call to WskReceive fills at most one MDL of the WSK_BUF structure. ref: [WskReceive](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_receive) Signed-off-by: Martin Drab <[email protected]>

Only the zero value for the Flags argument is supported. The client driver may use the Buffer argument to send data before disconnecting from the remote end. ref: [WskDisconnect](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_disconnect) Signed-off-by: Martin Drab <[email protected]>

If called at IRQL = PASSIVE_LEVEL, this call blocks until a connection is accepted. This is due to the fact that the VIOSOCK driver implements the accept() operation through an IRP_MJ_CREATE (ZwCreateFile) which is usually synchronous. To make WskAccept non-blocking, the client driver can call it at higher IRQL, the accept() call into the VIOSOCK driver is then deferred to a workitem. ref: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_accept Signed-off-by: Martin Drab <[email protected]>

This call translates to an IOCTL_SOCKET_BIND request to the VIOSOCK driver, followed with IOCTL_SOCKET_LISTEN one if the socket in question is a listening one. This needs to be done because the WskListen function was not part of the WSK interface until Windows 10 version 1703. Contrary to the TCP/IP WSK implementation in Windows, it is not necessary to call WskBind for non-listening sockets. ref: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_bind Signed-off-by: Martin Drab <[email protected]>

The following routines are not implemented: - WskControlClient - WskInspectComplete - WskConnectEx - WskSendEd - WskReceiveEx ref: [WskInspectComplete](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_inspect_complete) ref: [WskConnectEx](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wsk/nc-wsk-pfn_wsk_connect_ex) Signed-off-by: Martin Drab <[email protected]>

YanVugenfirer · 2024-01-28T08:20:35Z

@MartinDrab - I suggest breaking this PR to start merging. First PR - add new project skeleton and binary build. Second PR - add to the main solution; third - functional changes (this one can remain open or also be broken into pieces that we can merge).

What do you say?

MartinDrab · 2024-02-05T15:56:01Z

@MartinDrab - I suggest breaking this PR to start merging. First PR - add new project skeleton and binary build. Second PR - add to the main solution; third - functional changes (this one can remain open or also be broken into pieces that we can merge).

What do you say?

Hello,
first, a static library project for the WSK interface already exists and should be part of the viosock/viosock.sln solution. It just nearly just a skeleton.

I consider this PR ready for merge. Of course, I can divide it into more PRs in order to make the whole thing easier to read. For example, I can create these PRs:

Add the WSK library into the main solution (1 commit),
Add the main functionality into the WSK library (approx. 13 commits),
Implement a driver for testing the WSK interface (1 commit),
Enable WPP tracing for both the test driver and the library (1 commit).

Since the main load of commits belongs to the "Add the main functionality" bullet, the separation will not help that much but I see the point and it is fine for me to make the separate PRs.

The leverages WSK to create a set of client and server threads. The server thread listen for connection and exchange a message with connecting clients. Cryptographic hash function (SHA256) is used to verify that message data are not damaged during their transmission. Server threads are working in non-blocking mode. Such behavior is necessary in order to be able to cancel pending WskAccept calls since the viosock.sys driver does not permit their cancellation (unlike send/recv requests which ARE cancellable by design). Signed-off-by: Martin Drab <[email protected]>

The WPP Event Tracing can be disabled which means return to the good old DbgPrintEx routine. To disable WPP, the following steps need to be done: - commenting the line `#define EVENT_TRACING` in project's trace.h file, - setting the "Run Wpp Tracing" option in project settings to No. Signed-off-by: Martin Drab <[email protected]>

YanVugenfirer · 2024-02-06T08:24:13Z

@MartinDrab - I suggest breaking this PR to start merging. First PR - add new project skeleton and binary build. Second PR - add to the main solution; third - functional changes (this one can remain open or also be broken into pieces that we can merge).
What do you say?

Hello, first, a static library project for the WSK interface already exists and should be part of the viosock/viosock.sln solution. It just nearly just a skeleton.

I consider this PR ready for merge.
If this is a case, let me take a final quick view and then we can merge.

Of course, I can divide it into more PRs in order to make the whole thing easier to read. For example, I can create these PRs:

Add the WSK library into the main solution (1 commit),

Add the main functionality into the WSK library (approx. 13 commits),

Implement a driver for testing the WSK interface (1 commit),

Enable WPP tracing for both the test driver and the library (1 commit).

Since the main load of commits belongs to the "Add the main functionality" bullet, the separation will not help that much but I see the point and it is fine for me to make the separate PRs.

YanVugenfirer · 2024-02-06T08:24:19Z

re-run tests

YanVugenfirer · 2024-02-11T12:59:05Z

I am merging.

There is still a problem with the build all script inside of viosock folder.

viosockwsk-test.c
       Link:
         E:\ewdk11_22h2\Program Files\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.31.31103\bin\HostX86\arm64\link.exe /ERRORREPORT:QUEUE /OUT:"objfre_win11_arm64\arm64\viosockwsk-test.sy
         s" /VERSION:"10.0" /INCREMENTAL:NO /NOLOGO /WX Ntstrsafe.lib cng.lib arm64rt.lib "E:\ewdk11_22h2\Program Files\Windows Kits\10\lib\10.0.22621.0\km\arm64\BufferOverflowFastFailK.lib" "E:\ewdk
         11_22h2\Program Files\Windows Kits\10\lib\10.0.22621.0\km\arm64\ntoskrnl.lib" "E:\ewdk11_22h2\Program Files\Windows Kits\10\lib\10.0.22621.0\km\arm64\hal.lib" "E:\ewdk11_22h2\Program Files\W
         indows Kits\10\lib\10.0.22621.0\km\arm64\wmilib.lib" "E:\ewdk11_22h2\Program Files\Windows Kits\10\lib\10.0.22621.0\km\arm64\BufferOverflowFastFailK.lib" "E:\ewdk11_22h2\Program Files\Window
         s Kits\10\lib\10.0.22621.0\km\arm64\ntoskrnl.lib" "E:\ewdk11_22h2\Program Files\Windows Kits\10\lib\10.0.22621.0\km\arm64\hal.lib" "E:\ewdk11_22h2\Program Files\Windows Kits\10\lib\10.0.2262
         1.0\km\arm64\wmilib.lib" /NODEFAULTLIB /NODEFAULTLIB:oldnames.lib /MANIFEST:NO /DEBUG /PDB:"objfre_win11_arm64\arm64\viosockwsk-test.pdb" /SUBSYSTEM:NATIVE,"10.00" /STACK:"0x40000","0x2000"
         /Driver /OPT:REF /OPT:ICF /LTCG /LTCGOUT:"objfre_win11_arm64\arm64\viosockwsk-test.iobj" /ENTRY:"GsDriverEntry" /RELEASE /IMPLIB:"objfre_win11_arm64\arm64\viosockwsk-test.lib" /MERGE:"_TEXT=
         .text;_PAGE=PAGE" /MACHINE:ARM64 /PROFILE /guard:cf /kernel /machine:arm64 /IGNORE:4078,4221,4198 /osversion:10.0 /pdbcompress /debugtype:pdata "objfre_win11_arm64\arm64\test-messages.obj"
         "objfre_win11_arm64\arm64\viosockwsk-test.obj"
         "C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\wsk\objfre_win11_arm64\arm64\viosockwsk.lib"
         Generating code
         Finished generating code
         viosock-wsk-test.vcxproj -> C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\objfre_win11_arm64\arm64\viosockwsk-test.sys
     2>Project "C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\viosock-wsk-test.vcxproj" (2) is building "C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\vios
       ock-wsk-test.vcxproj" (2:2) on node 1 (TestSign target(s)).
     2>TestSign:
         The driver will be test-signed. Driver signing options can be changed from the project properties.
         Sign Inputs: C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\objfre_win11_arm64\arm64\viosockwsk-test.sys
         E:\ewdk11_22h2\Program Files\Windows Kits\10\\bin\10.0.22621.0\\x86\signtool.exe sign /ph /fd "SHA256" /sha1 "6E51FA0F637201D2A1D9D93724E852B31D23A241"
     2>E:\ewdk11_22h2\Program Files\Windows Kits\10\build\10.0.22621.0\WindowsDriver.common.targets(1464,5): error MSB6006: "signtool.exe" exited with code -1073741502. [C:\Users\yan\dev\kvm-guest-dr
       ivers-windows\viosock\viosock-wsk-test\viosock-wsk-test.vcxproj]
       RemoveUnsignedOutput:
         Deleting file "C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\objfre_win11_arm64\arm64\viosockwsk-test.sys".
         Deleting file "objfre_win11_arm64\arm64\viosockwsk-test.cer".
         Deleting file "objfre_win11_arm64\arm64\viosockwsk-test.tmh".
         Deleting file "objfre_win11_arm64\arm64\viosockwsk-test.pdb".
         Deleting file "objfre_win11_arm64\arm64\viosock-wsk-test.vcxproj.FileListAbsolute.txt".
     2>Done Building Project "C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\viosock-wsk-test.vcxproj" (TestSign target(s)) -- FAILED.
     2>Done Building Project "C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\viosock-wsk-test.vcxproj" (default targets) -- FAILED.
     3>ApiValidator:
         Driver is 'Universal'.
       FinalizeBuildStatus:
         Deleting file "ARM64\Win11Release\viosocklib.tlog\unsuccessfulbuild".
         Touching "ARM64\Win11Release\viosocklib.tlog\viosocklib.lastbuildstate".
     3>Done Building Project "C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\lib\viosocklib.vcxproj" (default targets).
     1>Done Building Project "C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock.sln" (Build target(s)) -- FAILED.

Build FAILED.

       "C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock.sln" (Build target) (1) ->
       "C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\viosock-wsk-test.vcxproj" (default target) (2) ->
       "C:\Users\yan\dev\kvm-guest-drivers-windows\viosock\viosock-wsk-test\viosock-wsk-test.vcxproj" (TestSign target) (2:2) ->
       (TestSign target) ->
         E:\ewdk11_22h2\Program Files\Windows Kits\10\build\10.0.22621.0\WindowsDriver.common.targets(1464,5): error MSB6006: "signtool.exe" exited with code -1073741502. [C:\Users\yan\dev\kvm-guest-
       drivers-windows\viosock\viosock-wsk-test\viosock-wsk-test.vcxproj]

    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:08.01

YanVugenfirer reviewed Oct 6, 2022

View reviewed changes

YanVugenfirer requested changes Oct 6, 2022

View reviewed changes

MartinDrab force-pushed the feature/viosock/wsk-interface branch 4 times, most recently from 1f941c1 to ca908ea Compare October 22, 2022 19:30

MartinDrab mentioned this pull request Dec 19, 2022

viosock: Publish supported socket options also for the kernel #868

Merged

MartinDrab force-pushed the feature/viosock/wsk-interface branch from 7aea4dc to 6694b94 Compare December 19, 2022 19:57

MartinDrab force-pushed the feature/viosock/wsk-interface branch from 6694b94 to ed7e49c Compare March 23, 2023 13:47

MartinDrab force-pushed the feature/viosock/wsk-interface branch from dc6f109 to 6044592 Compare April 22, 2023 14:14

MartinDrab force-pushed the feature/viosock/wsk-interface branch 7 times, most recently from 034396d to 07de476 Compare May 18, 2023 20:35

MartinDrab added 15 commits January 27, 2024 06:17

WSK: Ability to create and close sockets

12333f5

Signed-off-by: Martin Drab <[email protected]>

MartinDrab force-pushed the feature/viosock/wsk-interface branch 3 times, most recently from 2e8dca1 to 819dc29 Compare January 27, 2024 15:13

MartinDrab force-pushed the feature/viosock/wsk-interface branch from 819dc29 to 881446c Compare January 28, 2024 21:10

MartinDrab and others added 2 commits February 5, 2024 14:04

MartinDrab force-pushed the feature/viosock/wsk-interface branch from 881446c to a831488 Compare February 5, 2024 22:12

YanVugenfirer changed the title ~~CI NO BUILD: Winsock Kernel (WSK) Interface for the VIOSOCK Driver~~ Winsock Kernel (WSK) Interface for the VIOSOCK Driver Feb 6, 2024

YanVugenfirer approved these changes Feb 11, 2024

View reviewed changes

YanVugenfirer merged commit 4f5a62f into virtio-win:master Feb 11, 2024
6 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Winsock Kernel (WSK) Interface for the VIOSOCK Driver #835

Winsock Kernel (WSK) Interface for the VIOSOCK Driver #835

MartinDrab commented Oct 2, 2022 •

edited

Loading

YanVugenfirer commented Oct 3, 2022 •

edited

Loading

YanVugenfirer commented Oct 3, 2022

MartinDrab commented Oct 3, 2022

YanVugenfirer commented Oct 6, 2022

YanVugenfirer commented Oct 6, 2022

YanVugenfirer Oct 6, 2022

YanVugenfirer left a comment

YanVugenfirer left a comment

YanVugenfirer commented Oct 18, 2022

MartinDrab commented Oct 18, 2022

YanVugenfirer commented Dec 22, 2022

YanVugenfirer commented Jan 26, 2023

MartinDrab commented Feb 19, 2023

YanVugenfirer commented Feb 21, 2023

YanVugenfirer commented Mar 27, 2023

YanVugenfirer commented Jan 28, 2024

MartinDrab commented Feb 5, 2024

YanVugenfirer commented Feb 6, 2024

YanVugenfirer commented Feb 6, 2024

YanVugenfirer commented Feb 11, 2024


		#if defined(DBG) \|\| defined(_DEBUG)

		#define DEBUG_ENTER_FUNCTION(Format, ...) \

Winsock Kernel (WSK) Interface for the VIOSOCK Driver #835

Winsock Kernel (WSK) Interface for the VIOSOCK Driver #835

Conversation

MartinDrab commented Oct 2, 2022 • edited Loading

Limitations

YanVugenfirer commented Oct 3, 2022 • edited Loading

YanVugenfirer commented Oct 3, 2022

MartinDrab commented Oct 3, 2022

YanVugenfirer commented Oct 6, 2022

YanVugenfirer commented Oct 6, 2022

YanVugenfirer Oct 6, 2022

Choose a reason for hiding this comment

YanVugenfirer left a comment

Choose a reason for hiding this comment

YanVugenfirer left a comment

Choose a reason for hiding this comment

YanVugenfirer commented Oct 18, 2022

MartinDrab commented Oct 18, 2022

YanVugenfirer commented Dec 22, 2022

YanVugenfirer commented Jan 26, 2023

MartinDrab commented Feb 19, 2023

YanVugenfirer commented Feb 21, 2023

YanVugenfirer commented Mar 27, 2023

YanVugenfirer commented Jan 28, 2024

MartinDrab commented Feb 5, 2024

YanVugenfirer commented Feb 6, 2024

YanVugenfirer commented Feb 6, 2024

YanVugenfirer commented Feb 11, 2024

MartinDrab commented Oct 2, 2022 •

edited

Loading

YanVugenfirer commented Oct 3, 2022 •

edited

Loading