A
A
Alexander2013-01-21 06:11:12
linux
Alexander, 2013-01-21 06:11:12

Remote desktop from Linux and driver DLL - how is it possible?

There is:
a device connected to COM1 workstation (fiscal registrar bar-fr-k, kkm)
workstation - Lubuntu 12-04 LTS
terminal server - MS server 2003 (no admin access, only user and immediately into the application)
Problem - Application on the server uses a special driver written ONLY for windows, application and driver developers refuse to provide source code, documentation, or develop a driver for linux (*a lot of angry words*). Writing a driver yourself without documentation probably also fails.
Needed: Connect a remote desktop using two DLLki as a driver.
I tried: 1) running MSTSC from under wine - to no avail, I tried several versions of mstsc, climbed APPDB
2) shoveled through the manuals for rdesktop and xfreerdp - I didn’t find anything suitable.
3) tormented search engines with requests like “compiling from .dll to .so” (it sounds strange, of course, but I did not lose hope), etc.
I don’t pretend to be direct, Maybe someone knows how to do this, and after all, mstsc v.7 was somehow launched in the same APPDB, but unfortunately I didn’t succeed.
I note that the kkm works fine, first I installed the driver from the manufacturer in the wine, linked the port for the vine and printed to the kkm from the vine - everything is ok, then I put the driver for kubuntu into the system, connected via rdesktop to another terminal server that uses the usual driver of this kkm (and not the aforementioned developers) - everything is also ok.
Where can you dig? is it possible somehow to force for example Rdesktop paired with Vine to use these dlls? How else can you get out?
Dear gurus, I've been fighting for a week now, I ask for help!

Answer the question

In order to leave comments, you need to log in

5 answer(s)
M
merlin-vrn, 2013-01-21
@merlin-vrn

You can try to reverse-engineer the protocol. To do this, install a virtual machine with Windows, throw a COM port into it and listen to how they communicate. Well, or directly in Windows running on hardware, install software for eavesdropping on COM ports and reverse it like that.
Well, then the driver based on the information received.

4
4dmonster, 2013-01-21
@4dmonster

and under

2) shoveled through the manuals for rdesktop and xfreerdp - I didn’t find anything suitable.

did you mean and
  -r: enable specified device redirection (this flag can be repeated)
         '-r comport:COM1=/dev/ttyS0': enable serial redirection of /dev/ttyS0 to COM1   or      COM1=/dev/ttyS0,COM2=/dev/ttyS1

N
Nikolai Turnaviotov, 2013-01-21
@foxmuldercp

in Ukraine there are Silpo supermarkets
. So, at the cash desks of the nearest supermarket, KDE is very unobtrusively lit up, as if not 3 more versions.
It’s interesting to find out if they have 1C somewhere on the farm or locally running a client under Linux. Because the barcode scanner, cash register and receipt printer are attached to this case.

R
Ruslan_Voloshin, 2013-01-27
@Ruslan_Voloshin

I have experience in implementing Atoll cash desks on Linux software. there were some problems with the lump. I can’t say - the secret of the company, I advise you to try USB-to-COM and work through it

A
Alexander, 2013-01-28
@metis

Thanks, but I don't think this will solve my problem. (
Now I’m trying to create a minimal LiveCD windows image, put the necessary driver there, and load it in a virtual machine, after which I can connect to the program from it, maybe such a crutch will work ...

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question