How is VirtualHere able to virtualize USB devices on macOS without requiring the user to install kernel extensions?
As far as I am aware, there's no documented way to virtualize USB devices on macOS.
The USB/IP project, for example, only supports clients on Windows and Linux.
I understand this is proprietary software but it must be using some technique available to userspace?
Thanks
Really interesting.
Seems they are using the IOUSBHost.framework, which is at most undocumented.
Using it requires getting custom entitlement from Apple:
com.apple.usb.hostcontrollerinterface, which could possibly take a lot of time.
There are some traces that it could be used to create virtual devices, but no details about it.
You could try to use tools like classdump to get some information directly from the framework, or read some headers on github.
It would be great if someone could share any information about it with community, as Apple seems to be very lazy about doing this.
I have a vague recollection of reading somewhere in Microsoft's documentation (it might have been to do with BLE APIs), that some APIs are only available to apps downloaded from the Windows Store. I just searched again and can't find anything. Did I misremember or is this the case for some APIs?
I'm not aware of any APIs that aren't available in a side-loaded application, but APIs from the Windows.ApplicationModel.Store for example may not function in a meaningful way (like ListingInformation wouldn't be useful).
From this post i see we can run un-managed code in azure.
Running Native Code
My question is do we have access to all Win32 API's in azure, or are there any limitations. In general are there any limitations (which some of you may have come across) in running un-managed code in azure.
Thanks
Nakago...
Most Win32 APIs will work fine. But please note Windows Azure is a service environment, so in general it doesn’t make sense to call APIs like CreateWindowsEx.
In addition, by default, only core OS components are installed. Please install libraries like ATL yourself, if you wish to use them (via startup task or custom VM image). Please also manually enable Desktop Experience to use certain OS features. From my experience, I’ve tried to use Direct2D (to process images, but not render them) and Media Foundation, it doesn't encounter any issues.
Best Regards,
Ming Xu.
For developing programs for windows, we need windows SDK. I understand that this SDK is what helps to create windows and handle window events and all that. I suppose it also enables us to manipulate with files and registries.
(Does the same SDK is the reason for thread creation and handling?)
All that is fine!
I would like to know what are the files and libraries that come as a part of this SDK. Also does it come when I install the OS or when I install editors like Visual studio? Sometimes I see links to windows SDK separately as such. Is it same as the one that I get when installing Visual Studio or has something more than that.
Base Services:
Provide access to the fundamental resources available to a Windows system.
Included are things like
file systems,
devices,
processes & threads
and error handling.
These functions reside in kernel32.dll on 32-bit Windows.
Advanced Services:
Provide access to functionality that is an addition on the kernel.
Included are things like the
Windows registry
shutdown/restart the system (or abort)
start/stop/create a Windows service
manage user accounts
These functions reside in advapi32.dll on 32-bit Windows.
Graphics Device Interface:
Provides functionality for outputting graphical content to
monitors,
printers
and other output devices.
It resides in gdi32.dll on 32-bit Windows in user-mode. Kernel-mode GDI support is provided by win32k.sys which communicates directly with the graphics driver.
User Interface:
Provides the functionality to create and manage screen windows and most basic controls, such as
buttons and scrollbars,
receive mouse and keyboard input,
and other functionality associated with the GUI part of Windows.
This functional unit resides in user32.dll on 32-bit Windows. Since Windows XP versions, the basic controls reside in comctl32.dll, together with the common controls (Common Control Library).
Common Dialog Box Library:
Provides applications the standard dialog boxes for
opening and saving files,
choosing color and font, etc.
The library resides in comdlg32.dll on 32-bit Windows. It is grouped under the User Interface category of the API.
Common Control Library:
Gives applications access to some advanced controls provided by the operating system. These include things like
status bars,
progress bars,
toolbars
and tabs.
The library resides in comctl32.dll on 32-bit Windows. It is grouped under the User Interface category of the API.
Windows Shell:
Component of the Windows API allows applications to access the
functionality provided by the operating system shell,
as well as change and enhance it.
The component resides in shell32.dll on 32-bit Windows. The Shell Lightweight Utility Functions are in shlwapi.dll. It is grouped under the User Interface category of the API.
Network Services:
Give access to the various networking capabilities of the operating system.
Its sub-components include
NetBIOS,
Winsock,
NetDDE,
RPC and many others.
Internet Explorer web browser APIs:
An embeddable web browser control, contained in shdocvw.dll and mshtml.dll.
The URL monitor service, held in urlmon.dll, which provides COM objects to applications for resolving URLs.
A library for assisting with multi-language and international text support (mlang.dll).
XML support (the MSXML components, held in msxml*.dll).
I have listed only files for 32-bit windows (as that is what many window developers work on)
For more info, please check http://en.wikipedia.org/wiki/Windows_API
EDIT:
Above dlls and all are part of the operating system, not the SDK. The Windows SDK provides import libraries (.lib files) that allow code to dynamically link against these system-provided DLLs.
(This was rightly pointed by Marcelo Cantos. Many thanks to him)
SDK stands for Software Development Kit. It is a big fat collection of headers, libraries, tools and other bits and pieces that developers use to construct software. Microsoft provides many SDK's for their large range of products, and they are not generally deployed to the end-user's desktop. They are usually only installed on developer machines, either as part of a development environment like Visual Studio, or separately (but usually intended for use within VS anyway).
When you talk about the thing that handles windows, threads, etc., you are describing the Windows APIs. The purpose of an SDK is to allow developers to write software that accesses the APIs.
The Windows SDK gives you, as a developer, access to all the services of the Windows platform, including all the things you list.
The SDK is installed as part of the installation of Visual Studio, and usually you'll use the one that came with the compiler, and never have to worry about it. The standalone SDK downloads are there to support two scenarios:
If you use a compiler other that Visual Studio, it may not come with the SDK files, so you can download them separately.
Each new version of Windows includes more features in the API, so to call these new functions you need an updated SDK.
Background: This is for a university managed lab environment. Upper management wants to know how often users are using the various software we purchase for the labs. I've already implemented a solution for our Windows machines which consists of a client that tracks user process invocation and sends the results to a web service.
Now I need to create an equivalent Mac client but I have zero experience developing for the Mac platform and its various APIs. Our Macs are currently running 10.4, but will eventually be moving to 10.6 within the next year. I think I've got a handle on consuming the web service using something like gSOAP or even Mono. For the process tracking, I was looking at the Carbon Event Manager. But I've been reading that the Carbon APIs are on the road to being deprecated and I'd rather find something that will be supported moving forward.
Should I just use the Carbon stuff for as long as it works? Or is there some equivalent library I could be using that won't be phased out anytime soon?
Carbon APIs are not being deprecated, Carbon applications are. Feel free to use the event manager.
See The myth of Carbon’s 64-bit unavailability