In Windows XP (SP2 if necessary), is there any way to detect, from a userspace application, that a TCP/UDP socket (from any process) has opened? I know of the GetExtendedTcpTable() and GetExtendedUdpTable() functions, but they only detect currently opened sockets. Some sockets close immediately after they're opened that the only way I'd be able to detect their existence is by being notified when they open.
If no such a mechanism exists in userspace, I'm willing to go into kernel space to get this functionality. Are there any documented/undocumented features that could do this?
You will likely need to write a WinSock LSP or SPI driver in order to detect that without having to hook every running process directly.
Related
I am looking for using barcode capture event to executing a program (either powershell or simple vbscript) on Windows 10 machine. How can I achieve that? Do I need to create a barcode program embedded in it - if yes, how will it execute? Do I need to capture the scan event in windows machine and write a logic on scan event to execute program - is that possible?
I am not finding any help on internet. Please help.
There is no mechanism that can be called by simply registering an event handler.
Based on the mode and mechanism of the scanner device you are using, you need to create an application program that handles it.
Hardware type and mode
Keyboard input emulation
Serial (or Bluetooth) port connection
Camera image recognition
programming
The application handles the device directly
Libraries and APIs
OPOS
POS for.NET
Windows.Devices.PorintOfService
JavaPOS
Various libraries that recognize barcodes from cameras/images
At a minimum, you need to open the device or register a keystroke event handler.
In addition, it will be necessary to send a command to start/stop scanning of the scanner, to distinguish between human-operated keyboard input and notification from the scanner.
It's not impossible to implement them in PowerShell, but it's likely to be difficult and slow.
I've been playing around with NSRunningApplication in Swift 3, and I've come up with a few questions.
What's the best way to "pause" an application while it's launching. Don't quit it, but don't let it launch completely either. Just keep the icon bouncing in the dock (i.e. "freeze" the launch) for some arbitrary time. After that time, if I decide I want to quit the app after all, I can do NSRunningApplication(withBundleIdentifier: "xyz").terminate() or .forceTerminate(), and I can confirm with .isTerminated(). Otherwise, I can just "unfreeze" the app and let it finish launching.
What's the least power-hungry way of checking constantly for an app launch? I could just schedule a Timer to check every half-second or so, but I believe that hogs a fair amount of memory. Can I set a listener or notification to check for a 3rd-party app launch? (i.e. to run a function every time the Notes app changes isTerminated state).
Thanks!
You can't reliably target another process and control it from Swift (or any other User-mode program), as you really need to do that in the kernel, with a kernel extension (Kext).
Apple's official framework for this is the Kernel Authorization framework (KAuth). Using the File Operation Scope (described in the documentation), a kernel extension will be notified of various operations, including a program's execution and can allow or deny its access.
A working example of its usage can be seen in the open source code of Google Santa, which they use to manage their own employees' computers. As its documentation states:
It consists of a kernel extension that monitors for executions, a userland daemon that makes execution decisions based on the contents of a SQLite database, a GUI agent that notifies the user in case of a block decision and a command-line utility for managing the system and synchronizing the database with a server.
I need to be able to close COM ports through the command prompt (Windows 7 OS). The reason for this is that I work with a lot of experimental equipment, controlled with a language called LabVIEW, and communication to these devices is sometimes lost. Right now the only fix is to either rename the COM in device manager, or reboot. Ideally I'd like to close the port in command prompt, which I can implement programatically in my control software.
Does anyone know either; how to close a COM port in command prompt, or a quick and easy way of closing a COM port, so then I can reestablish a connection with my device?
Cheers!
I don't think you can simply close a resource that is in use by another program, this will undoubtedly lead to errors. Programmed correctly LabVIEW should not leave ports open, even if port are left open simply closing labview should be enough.
In LabVIEW programatically open and close the COM port, don't rely on the auto-closing of the VISA system. Also add timeouts to the serial connections, than you should get a connection error time out and be able to clean up the resource.
Basically you need to solve your problem at the origin, if help needed post your LabVIEW code.
Presuming you read from the serial port in a while loop, simply stop the while loop when an error is found, see the code snippet. This stops the loop and the resource will be closed outside the loop regardless of the error.
I'm interfacing to a hardware serial device using QT, I've based my application roughly around the Terminal example, but as the communication needs to be very synchronous the serial handler is living in another thread. The connection is via a 2xRS232 to USB adaptor with an FTDI chipset.
The serial comms are fine, I can connect, send commands, etc. However, when I quit and reload the application the serial port seems to be blocked.
Let COM1 be the connected device, COM2 is unconnected.
If I run the program, do a bit of talking to the hardware and quit, I can no longer connect to COM1 the next time I run the program (the data leds don't flash on the adaptor) unless I attempt to connect to COM2 first. Once I've tried this I can then connect back to COM1 as usual. This behaviour is not seen in the reference utility for the hardware and so must be down to some way I'm handling the port.
My close code is:
void mydevice::closeSerialPort()
{
this->stop();
serial->close();
emit serialClosed();
emit log("Serial port closed.");
}
serial is a QTSerialPort. First a stop command is sent to turn off the hardware (not relevant to the problem, it's just a convenience) and then I send a close command to the serial.
I have a subclassed QWidget for my main window, which calls this command on exit:
/* In the constructor */
connect(this, SIGNAL(WindowClosed()), mydevice, SLOT(closeSerialPort()));
void mainwindow::closeEvent(QCloseEvent *event)
{
emit WindowClosed();
event->accept();
}
Is there any reason for this behaviour? I assume I'm blocking the port open somehow, but surely it would complain that it's already open.
Another odd issue is that say the device is on COM1 and I open it in my application, COM1 is unresponsive in the other utility and the device appears on COM2. However, when I switch back to my program and fiddle a bit, the device appears on COM1 again (though always in COM2 in the other application).
So there seems to be a fairly simple solution, though I don't understand exactly what was causing the problem.
I have two threads, each controlling a different serial device. The serial configuration is accessed through a dialog which I stole from a QT example (the terminal). Each thread has an instance of this settings dialog. It seems that something goes wrong when selecting the port - for instance all the selections in the dialog actually point to the same COM port if checked in a debugger.
Anyway, I chalked this up to non-thread-safe code and changed the program to just ask for the serial port name as the data rates, stop bits, parity, etc are fixed by the hardware and aren't going to change. This has fixed the problem.
There are two possible answers, I think:
Your process doesn't terminate in spite of you closing the main window. How have you verified that the process is, in fact, terminated?
Your use of qt's serialport module exposes a bug in FTDI's driver. That's not unthinkable, but I'd call it a remote possibility at the moment.
Personally I don't see any use for the serial port emulation of the FTDI driver, it's adding an extra layer for no good reason. The D2XX interface is the way to do it, if you don't want to use something like libftdi. On Windows, I've found D2XX and libftdi to be the only viable alternatives, with libftdi working much better than D2XX on virtual machines.
Don't know if this could be useful.
I have a similar issue (but not the same) with a prolific pl2303.
In my case when i close the port (or even at startup, before opening it!), data is received anyway somehow and presented immediately when i open the port.
This happens only with an usb-rs232 adapter, if I use the ttyS0 (physical serial port) the problem does not appear.
The solution for me was forcing QSerialPort::clear() to clear buffers just after QSerialPort::open(). This avoids signal readyRead to be emitted and thus unwanted data to be received.
Is there a way to create a user-mode process from kernel-mode on Windows NT platform (XP-W7)?
EDIT: I must install only the driver. This is a specific of the project.
To create a valid win32 process the driver must communicate with CSRSS (what is completely undocumented). So I ended up by queuing a user-mode APC and allocating virtual memory for the APC code in the context of the existing win32 process (that code will call CreateProcess and do the job).
It is a tricky way but it works.
I don't know an easier way to achieve this. But what about having a Windows service running which makes an overlapped DeviceIoControl into your driver? On return the service could examine the data it has received from the driver and start the according application.
This can't be directly done - Creating a win32 process requires some set up by the user mode part of CreateProcess, not just creating the process object in kernel mode.
You need some user mode code here - either a service, a desktop app, or so on, to launch the your user mode application.