I am trying to write a program that uses IOAudioControl.h file in the IOKit, so that I learn dealing with IOKit directly without using Apple's APIs. Whenever I run a simple file like below I got tons of errors in IOAudioControl.h
#include <IOKit/audio/I0AudioControl.h>
#include <iostream>
int main(int argc, const char * argv]) (
{
// insert code here.
std: :cout << "Hello, world! \n"
return 0:
}
Here is a screenshot for my build settings
enter image description here
and here is a screenshot for the errors
enter image description here
IOAudioControl is a class that exists in the macOS Kernel (and its API is available to kexts), and it is also accessible from DriverKit extensions (dext) via the IOUserAudioControl API in AudioDriverKit.
From your code sample it looks like you're trying to include the kernel header file in a regular user space program. This will not work, kernel objects are not accessible from user space in this way.
You do not specify what you are ultimately trying to achieve, but:
If you are trying to implement an audio device driver, use either the Core Audio Server Plugin API or build your driver as a DriverKit extension. (Most kinds of audio kernel extensions are deprecated.)
If you want to access and modify the controls of an existing audio device in the system, use the Core Audio API.
If you wish to enumerate the kernel's IOAudioControl objects from user space, use the IOKit framework's service iteration APIs from your program.
Related
I've got a Windows application with a GUI written in Rust and winapi. Despite its GUI, it behaves like a console application. When the exe file is started, a Command Prompt window pops up, and the application is run from it. This is not what I want; a main window should open instead, as in all real desktop apps. How can I achieve this goal in Rust with winapi?
I've investigated some options. You can develop Windows desktop applications using Tauri or gtk-rs, but both of these techniques have drawbacks when used for Windows apps. More options may be found here. I've also tried the windows-rs samples available on the internet, but they're all console apps with a graphical user interface, which isn't what I'm looking for.
I also note that C++ desktop applications use the function int APIENTRY wWinMain(...) as the entry point while console applications use int main(...), and wWinMain doesn't seem available in rust winapi.
Whether the system allocates a console for a newly created process is controlled by the Subsystem field in the Windows-specific optional PE header. The field is populated through the linker's /SUBSYSTEM command line option. The only relevant arguments for desktop applications are CONSOLE and WINDOWS. The former instructs the system to allocate a console on launch, whereas the latter won't.
You can instruct the linker to target the WINDOWS subsystem from Rust code by placing the per-module
#![windows_subsystem = "windows"]
attribute (see windows-subsystem) inside the main module of your application.
You'll find an example of this in the core_app sample of the windows crate.
This is the most convenient way to target the WINDOWS subsystem. You can also explicitly pass the linker flag along, e.g. by placing the following override into .cargo/config.toml:
[build]
rustflags = [
"-C", "link-arg=/SUBSYSTEM:WINDOWS",
]
This may or may not work, depending on the linker you happen to be using. Since the linker isn't part of the Rust toolchain, making sure that this works and has the intended effect is on you.
A note on the entry point's function name: It is irrelevant as far as the OS loader is concerned. It never even makes it into the final executable image anyway. The PE image only stores the (image-base-relative) AddressOfEntryPoint, and that symbol could have been named anything.
The concrete name is only relevant to the build tools involved in generating the respective linker input.
More info here: WinMain is just the conventional name for the Win32 process entry point. The underlying principles apply to Rust just the same, particularly the aspect that the user-defined entry point (fn main()) isn't actually the executable's entry point.
I have legacy applications that use the Windows semaphore API (CreateSemaphore etc.), and am writing a new multiplatform app in which I am using the Boost libraries.
Using a default Boost build in Windows, it creates named_semaphore's in the filesystem.
The file \boost\interprocess\detail\workaround.hpp seems to define flags which I had hoped would achieve this (by defining WIN32 and commenting out #define BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION)
Here is an extract from that file:
#if defined(_WIN32) || defined(__WIN32__) || defined(WIN32)
#define BOOST_INTERPROCESS_WINDOWS
// #define BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION
#define BOOST_INTERPROCESS_HAS_KERNEL_BOOTTIME
//Define this to connect with shared memory created with versions < 1.54
//#define BOOST_INTERPROCESS_BOOTSTAMP_IS_LASTBOOTUPTIME
#else
However, stepping through the Boost code for creating this semaphore (using the defines as above) shows that it still tries to create a file in a default shared directory, and this leads to an exception when Boost tries to lock it.
Does anyone perhaps know if this is possible using Boost (yet?)
Many thanks, Kevin
Windows synchronization lifetime guarantees are not POSIX, which is what Boost Interprocess implements. So, no, it is not possible.
I've used SHGetDesktopFolder() to get a PIDL and then walked down it's contents using IShellFolder.
I now have a particular PIDL referencing a filesystem location, and I can use BindToStorage and IStorage to .OpenStream() and .Write() a file.
This is all well and good if the interesting things live on the filesystem, but more interesting things live in "Shell Namespace Extensions".
In particular, I have a Pocket PC 2002 device (Specificly, a Symbol PDT8146) that is hooked up to my Windows 7 machine using Windows Mobile Device Center. This application creates a shell namespace folder that I can use from within explorer to read/write files to it.
What I cannot do is write files to it using the command line or win32 APIs.
Following the strategy I outlined above, I can get a PIDL and IShellFolder instance referring to the device, and I can list it's files. However, IShellFolder.BindToStorage() fails with 'No such interface supported' when I try to access IStorage.
Is there another shell interface I should investigate to read/write files on this stubborn device?
Try IShellFolder.BindToObject:
IStream *stream;
if (FAILED(shellfolder->BindToObject (pidl, NULL, IID_IStream, &stream)))
return E_FAIL;
But I'm not sure if this works with writing files as well.
I am new to windows development and I am trying to write a user-mode windows(XP, Vista & 7) virtual printer driver. My aim is to intercept the output being sent to the hardware printer by a third party app and add some extra data(text + graphics) to that output towards the end of the output. Then send the final payload to be printed by the hardware printer. Note that my data would not be added to every print out from the machine but just from a particular third party app.
I want to add my extra data to the print output before it gets converted to any Page Description Language(PDL). Can I do this? Would I be able to predictably add my extra data at the end of the output with proper formatting? If yes, then what kind of driver would I need to write and at what layer of the architecture ?
Is there a better way to do the same thing then writing a user-mode printer driver?
Finally, is there a sample code, online blog or book which can help me with this ?
I think you'd be better off getting the application to write to a generic Postscript driver and post-processing the resulting Postscript rather than trying to make sense of the data written to a printer driver; there are excellent open-source tools available for manipulating Postscript.
This page describes setting up a driver on Windows that will produce Postscript although you will want to do something else with the Postscript other than sending it to another printer as described there.
I don't think you need a driver. Just use the standard Postscript driver provided with the WDK, adding .PPD and .INF files to name it and specify characteristics, and then put your code in a port monitor. Port monitors are considerably easier to build and maintain than print drivers.
I'm fairly new to C programming language and packet capturing.
Right now I'm writing a simple program (using Visual Studio 2010 express) to decode a packet trace capture file. I read a number of guides, but most of them are for linux/unix. I managed to include wpcap libraries, but now i need structs defined in the system that are intended to
make decoding Internet packet headers easier.
struct ether_header in /usr/include/sys/ethernet.h
struct in_addr in /usr/include/netinet/in.h
struct ip in /usr/include/netinet/ip.h
struct udphdr in /usr/include/netinet/udp.h
struct tcphdr in /usr/include/netinet/tcp.h
Up until now I understood that winsock2 must be included for in.h, but what about ethernet, ip, tcp/udp? What should i do to manage decoding related to these headers? is it same winsocket? if it is, where could i find simple explanation of what methods to use?
OS: Win 7
Actually, most of those headers were originally intended to make writing the BSD kernel networking stack easier, not making decoding packet headers in sniffers easier; they're present for user programs in part for historical reasons.
I'd suggest getting the source to recent versions of tcpdump or WinDump and making your own copies of the corresponding header files in it; the ether.h, ip.h, udp.h, and tcp.h files from tcpdump/WinDump are taken from BSD-derived operating systems so that tcpdump/WinDump don't have to depend on the operating system supplying those headers or on it supplying particular versions of those headers (not all of the operating systems on which tcpdump/WinDump can run supply versions that work well with tcpdump/WinDump, with some of them requiring special hackery for tcpdump and some others not supplying them at all - Windows, for example, doesn't supply them at all, as you've discovered).
You can get the tcpdump source from tcpdump.org, and the WinDump source from winpcap.org (look under "WinDump 3.9.5 Source Code Download"). The WinDump source is in a ZIP file rather than a gzipped tar file, so it might be easier to unpack on Windows, and might have Windows CR-LF line endings rather than UN*X LF line endings, so you might want to try the WinDump versions.
Even though you're working on Windows, as you're using libpcap you might get some mileage from Unix Network Programming vol. 1 and TCP/IP illustrated Vol. 1. You can buy these new or secondhand off Amazon Marketplace. This will explain the headers and other related items.
I only include these (in this order)
#include <winsock2.h>
#include <windows.h>