I am wondering if it is at all possible to receive etw events (vista+) using kernel code? I saw an example using user-mode functions, but I don't see any examples using kernel-mode functions. I understand that drivers are more commonly the providers, but I figure that the ability should still be there in kernel-mode to consume these events in a callback.
If anyone has any experience, I'd appreciate hearing about it. Thanks.
Jeff
Related
I am wishing to use the Sync FIFO interface of a FT232H on a custom board from python on a RaspberryPi. I would use PyFTDI, but PyFTDI doesn't implement the Sync FIFO interface mode. The constant for the Sync FIFO mode is defined in PyFTDI but never used. I plan on accessing Sync FIFO by using PyUSB directly with PyFTDI as a reference. However as PyFTDI doesn't ever use the Sync FIFO mode, I don't know what FTDI commands are used for the mode on the USB endpoints. The documentation I have been able to find from FTDI tell how to use the proprietary library as opposed to the low level command structure actually sent to the chip. I have done a bit of searching, but FTDI provides many documents and it is a bit of information overload.
Does anyone know where the documentation is which covers the low level command codes and arguments which are sent to the FTDI USB end points? I am assuming the authors of PyFTDI were referencing something besides wire sniffing.
According to their knowledge base FTDI provides an API document under an NDA for some circumstances.
In some circumstances, it may be desirable to develop a custom driver for an exotic operating system or an embedded system. In these circumstances, an API document may be obtained from FTDI under NDA to allow driver development for FTDI devices. To request a copy of the API document, please contact FTDI Support support1#ftdichip.com.
I have several years experience with microcontroller programming. Freertos provides the necessary code to port to a set of microcontrollers. I would like to port Freertos to an embedded system which is not supported.
Which main steps have to be undertaken in order to successfully port freertos to another embedded system? (for example: what initialization steps should absolutely be done in port.c etc...) I have read the freertos page about porting, but it is still pretty vague.
I presume this is the page you are referring to http://www.freertos.org/FreeRTOS-porting-guide.html it is vague because each architecture has its own requirements. For example, is a yield going to be performed synchronously using a trap style instruction, or asynchronously using a pended interrupt, how is interrupt nesting going to be implemented and what support does the hardware give to implement it, etc. Therefore it would have helped a lot if you said which architecture you wanted to port to, then I might have been able to suggest which port to look at as a reference.
I'm trying to decide if MSMQ is the right tool for communication between our application and a third party web service we are currently communicating with directly. We're looking to uncouple this such that if the service goes down, life could still go on as normal.
I can't find anything outside the usual MS fluff about it being the greatest thing and solving all your problems etc etc. It would be really useful if I could find some information that was somewhere between marketing fluff and API - like an architecture diagram of the components and how they integrate with each other, and more importantly how I integrate with them.
It's probably that I'm just looking for the information in the wrong places, so if someone could point me in the right direction, I'd appreciate it.
A typical MSMQ architecture would be composed of 3 parts...
Message Queue - This would be on one of your servers. You would have to install the MSMQ bits and create your queue.
Client - Your client would insert messages into the queue. I'm assuming you're using .NET. If so, most of what you want is going to be located in the System.Messaging namespace.
Windows Service - This would also run on a server, probably the same server as your queue. Its job would be to watch the queue, process messages as they come in, handle making sure the external service is available, and probably do some logging.
Here's an article that should go into a little more detail and give you some code samples.
MSMQ is a implementation of a message queue as are websphere mq and a bunch of other systems. When looking into the concepts and high level architecture I would suggest reading up on message queue's and how they are applied in disconnected scenario's. I can highly recommend Patterns of Enterprise Application Architecture. For specific examples on msmq check out Pro MSMQ: Microsoft Message Queue Programming it doesn't contain allot of special information but it does group it allot better then most resources available on the internet. This Hello World with MSMQ article would give you a nice overview of what it entails and it's easily executed on a development system.
If you are calling a remote web service from your application, it makes sense to use a queue to decouple your application processing from the remote system. By abstracting the communicating through messaging and having a gateway service that is responsible for communication to the web service, you isolate your application from the latency of the web service and build fault tolerance into the design by reducing the request/response usage inside your application (since messaging is by default asynchronous - you deal with it up front).
There are frameworks for .NET that can make this much easier (such as MassTransit or NServiceBus).
You can also check out SOA Patterns (by Arnon Rotem-Gal-Oz, Manning Press, in MEAP) and Enterprise Integration Patterns (Hohpe,Woolf), the latter of which is an essential read for anyone building a message-based system.
I want to write a program from scratch to see the sockets activity, what they send, what they receive, etc. I don't want to use a Library because it's more for academic purposes than anything else.
Where should I start?
Just to be clear: my program won't be connecting to anything or creating any socket, it just wants to listen to the activity in a computer.
Any thoughts (in any OS) about where to start will be appreciated.
Thanks in advance.
Take a look at libpcap/WinPcap.
You are out of luck as far as portability goes.
Although the application APIs are the same or similar for UNIX and Windows, and, both implementations are historically based on the same Berkeley Sockets BSD code, the operating system architecture and hence the ways you access low level OS functions such as network IO are completely different.
Linux has a number of 'network sniffing' tools(tcpdump, ethereal etc.) easily available. Not so sure about windows, MS provides a Network Monitor and there are some tools available -- Google 'Sysinternals TDImon' for the MS tools.
Is there any benefit on Windows to use the WSA winsock functions compared to the BSD-style ones?
The most significant difference is the availability of Asynchronous Event style APIs in Winsock.
With Berkeley sockets, each time you read or write your application will "block" until the network is ready, which could make your application unresponsive (unless the network I/O is handled in a different thread).
With an async interface, you can arrange for a callback function to be called as part of the normal windows message loop each time data is received or when the transmit buffer is empty.
Only if you plan to deploy to a legacy platform like Windows 95 or there is something in the winsock API that you absolutely cannot live without and you don't want to roll yourself (<-- doubtful tho).
If you design around the BSD paradigm, your code can work on other platforms with less porting work. If you assume that your network library will support asynchronous I/O (as Alnitak mentions), you're going to have to do a lot more work if that gets pulled out from under you.
Of course, if you're sure you'll never leave the warm bosom of Microsoft, feel free to go to town.
With respect to Alnitak's answer, I agree - I'd just add that you need not use a message loop to use asynch operations on sockets. Using I/O completion ports is a very scalable way to build a high-performance networked application.