Right now I have an application written in Qt, and a shared library(dll), also written in Qt. They are working in different threads and communicate via signals and slots.
The problem: I need to make the Qt dll work for a Delphi 6 application.
The question: Is it possible to somehow use Qt dll's signals in delphi? If not, how can I make the main program(delphi) and the dll(in a different thread) communicate in some other way, not with signals/slots?
Related
I have a main QT GUI App running in the embedded linux system. Now I need to create another APP which is to monitor a rotating knob position and send this information to the main QT GUI APP, wo what's the normal way for this two APP communicate?
There are many options, though using a pipe or socket is common. What you're looking for is Interprocess Communication.
QT has an interprocess communication abstraction that you can probably use to do this:
https://doc.qt.io/qt-5/ipc.html
I'm writing a cross platform application, I want to be able to intercept keyboard input and optionally filter it from reaching the rest application. My application loads plugins, I am trying to stop the keystrokes from reaching the plugin's UI if it has focus.
On Window I use SetWindowsHookExA and on macOS I use [NSEvent addLocalMonitorForEventsMatchingMask:]
Is there an equivalent for Linux?
I'm writing a cross platform application, I want to be able to intercept keyboard input
If your application is a GUI one, consider using a cross-platform framework such as Qt or GTK (or FLTK, FOX, etc...). If your application is command-line (like e.g. grep or GCC or ninja or MongoDB are), it might not even access the keyboard, if used inside some pipeline, and you might also use cross-platform frameworks like POCO. If your software is started by crontab, it won't even have access to the keyboard, which might not even exist or be plugged in.
The same source code (for Qt or GTK or FLTK etc...) will work for Linux and for Windows.
BTW, many Linux computers (e.g. most web servers, or a RasperryPi) don't have any keyboard or mouse.
For more, read Advanced Linux Programming and syscalls(2).
Read about Xorg and Wayland.
My application loads plugins, I am trying to stop the keystrokes from reaching the plugin's UI if it has focus.
Plugins on Linux are often implemented thru dlopen(3) and dlsym(3) as ELF shared objects, conventionally in files named *.so (so see elf(5)). Read the Program Library HowTo and if you code in C++ also the C++ dlopen minihowto. If you code in Ocaml, use the Dynlink module. If you can code in Common Lisp (e.g. using SBCL), you'll just use eval. If you have to code in Java, use some class loader.
With Xorg (that is, X11) every keyboard event is generating some well defined message (some XKeyEvent) emitted - on a tcp(7) or unix(7) socket- by the Xorg server to your Xlib client application.
On the client side (in your GUI application code), an event loop (around poll(2) or select(2)...) is waiting for such messages. See also time(7).
On my Debian system (according to file /var/log/Xorg.0.log and using proc(5)...) the Xorg server is accessing the keyboard (thru udev) as /dev/input/event1 and X11 clients are communicating with the Xorg server.
Our vendor provides DLL, which works on Windows. Is this possible to load custom xxx.dll file and use its functions in Linux using Go?
Like this: https://github.com/golang/go/wiki/WindowsDLLs
The short answer is "no": when you "load" a dynamic-linked library, it's not only actually loaded (as in read from the file) but linked into the address space of your running program — by the special means provided by the OS (on Linux-based systems, at least on x86/amd64 platforms that's an external process; on Windows, it's an in-kernel facility, AFAIK).
In other words, loading a dynamic-linked library involves quite a lot of complexity happening behind your back.
Another complication, is whether the DLL is "self-contained" in the sense it only contains "pure" functions — which only perform computations on their input data to provide their output data, — or they call out to the operating system to perform activities such as I/O on files.
The way operating systems provide ways to do these kinds of activities to the running processes are drastically different between Windows and Linux.
The last complication I can think of is dependency of this library on others.
If the library's code is written in C or C++, it quite likely depends on the C library used by the compiler which compiled the library (on Windows, it's typically that MSVCRxx.DLL thing). (A simple example is calling malloc() or printf() or something like this in a library's code.)
All this means that most of a DLL written on Windows for Windows depends both on Windows and the C or C++ standard library associated with the compiler used to build that library.
That's not to mention that Windows DLL uses PE (Portable Executable) format for its modules while GNU/Linux-based systems natively use the ELF format for its shared object files.
I'm afraid not because the windows DLLs do different kernel calls than Linux shared object, both has this fancy name for system library objects
But if you need to run a windows native app on linux I would recommend give Wine a try, I doubt it works properly, and a second worthy try is dosbox, once I doubt this works too
But there is a little hope if those DLLs are written in .net framework, you could wrap them up on a nice c# code and use mono on linux side, not sure if this enables you to import those DLLs to golang, but I don't think so either
In the and with that amount of tricks to have everything working you will get some performance issues, just saying
I have an application using ThreadX 5.1 as the kernel.
The Image is flashed on to a hardware running an ARM 9 processor.
I'm trying to build a Simulator for the application that can be run on Windows (say XP, 32-bit).
Is there any way I can make it run on Windows, without modifying the entire source code to start calling win32 system calls?
You can build a Simulator for the application that can be run on Windows with "ThreadX for Win32".
"ThreadX for Win32"'s specification is hear.
http://rtos.com/products/threadx/Win32
Yes you can if you are willing to put in the work.
First observe that each threadx system call has an equivalent posix call except for events.
So your threadx program can run as a single process using posix threads, mutexes, etc.
Events can be handled by an external library (there are a few out there).
If you find this difficult in windows then the simplest thing to do is set up a linux vm. I use an ubuntu vm running on Virtual Box. It is very easy to set up. All you will need is the cdt version of eclipse.
Next you need to stub out all of your low level system calls.
This is also easier than you might think. For example, if you have a SPI driver to read and write to flash, you can replace your flash with a big array which is quite easy to work with at this level.
Having said all this, you may get more mileage if your threadx application is modular. Then you can test each module on it's own and you don't need to mess with threads, etc.
As a first approximation this may give you what you need without going the distance to port the whole thing to run under posix.
I have done this successfully in the past and developed a full set of unit tests for a module that allowed me to develop and test it (on my mac) before going to the target. Development is much faster and reliable this way.
Another option you may want to consider is to find a qemu project that supports your microprocessor. With some work you can develop a complete simulator for your platform and then run the real firmware under the emulator.
Good luck.
I'm aware of some Windows Thread Libs for Delphi(OmniThread Lib, BMThreads, etc).
But is there a lib that is built to be cross-platform and that can both be used under Delphi and FreePascal?
Although these are not links to threading libraries per se, the information on the following pages might (or might not) be of use when researching threading on Windows/Linux and MACOSX
Multithreading with Lazarus.
OSX Multithreading forum...thread.
Sorry couldn't offer anything more specific.
Both FPC/Lazarus and Delphi support TThread. FPC doesn't suppport TMREWS though (it does have the identifier but it is a simple lock).
But I assume you mean some thread pooling classes? What do you exactly need, and why is the Delphi built in support not enough?