I'm trying to make a application that allows remote access to other applications (running on different machines). The idea is to make give users transparent accesso to certain applications, I've basically two options:
Application Streaming
Intercepting draw command and reproduce them in the client
(of course, the input is redirected from the client to the server)
I've a working version with application streaming, but I don't have a clue of how to do it through hooking in the Win API...
Any ideas ?
What you're describing sounds a lot like a Windows metafile. The metafile captures all GDI drawing commands to a file; that file can then be passed to a remote PC and rendered there.
See CreateEnhMetaFile for starters. This returns a handle to a device context, which you draw to instead of drawing to the normal screen device context.
Related
What is the best way to transfer binary data from plugin to browser.
We want to play YUV buffer received from network on browser tab.
currently am converting to base64 and giving via callback. but it is not efficient and am finding below issues
1> CPU and Memory is going up
2> Callback events are not passed when we change the browser tab, later all events are given at one shot on moving back to our tab.
I would also like to know is there any way we can directly draw YUV frame on browser using plugin thread itself.
Thanks in advance.
NPAPI has been removed from most major browsers... the last holdout, Safari, will be removing it as of macOS Mojave. That being the case, don't expect any updates of any kind to the spec -- however you're using it is likely a dying method.
That being the case, on windows there is a method (super hack, really) that you can use to draw directly to the window in the browser from a native message extension, but it's not portable and it depends on internal implementation details. I haven't actually looked into it since I wrote that other answer (linked in this paragraph) so I don't know if it still works or not.
Anyway, if you're on a browser which fully supports NPAPI then you could draw the YUV data directly to the plugin window given to you on the browser; there is an example of blitting image data in FireBreath which you could possibly trace through as an example.
You could also try some variation of listening on a TCP port in the plugin and connecting to it from the browser; you could easily run into some security issues there, but it is the only other method I can think of.
NPAPI simply wasn't ever designed to allow fast transfer of data between the plugin and the browser; I submitted a proposal to add that capability years ago but it was basically too close to the death of NPAPI (which is basically past at this point) for it to go anywhere. The issues you're seeing are 100% consistent with what I would expect, though... and it's still the best way I know.
On WindowsCE 6.0 the default OS paging settings are a bit small as discussed here
http://blogs.msdn.com/b/ce_base/archive/2008/01/19/paging-and-the-windows-ce-paging-pool.aspx
I cannot convince OS providers to fix such issues so I'm interested in whether there is a suggested workaround from the application side where we are impacted by excessive paging/thrashing.
Theoretically, a smaller exe would help but I'm not convinced of that. I'm also experimenting with avoiding all memory mapping of files.
Any other suggestions?
You can set the paging pool size when creating the OS image, see here.
If your OS image is third party (or you don't control it), then you can try to set the paging parameters at runtime using IOCTL_HAL_GET_POOL_PARAMETERS IOCTL call.
Also check this link for more information about WinCE paging pools.
I have a perl app which processes text files from the local filesystem (think about it as an overly-complicated grep).
I want to design a webapp which allows remote users to invoke the perl app by setting the required parameters.
Once it's running it would be desirable some sort of communication between the perl app and the webapp about the status of the process (running, % done, finished).
Which would be a recommended way of communication between the two processes? I was thinking in a database table, but I'm not really sure it's a good idea.
any suggestions are appreciated.
Stackers, go ahead and edit this answer to add code examples or links to them.
DrNoone, two approaches come to mind.
callback
Your greppy app needs to offer a callback function that returns the status and which is periodically called by the Web app.
event
This makes sense if you are already using a Web server/app framework which exposes an event loop usable from external applications (rather unlikely in Perl land). The greppy app fires events on status changes and the Web app attaches/listens to them and acts accordingly.
For IPC as you envision it, a plain database is not so suitable. Look into message queues instead. For great interop, pick AMPQ compliant implementation.
If you run the process using open($handle, "cmd |") you can read the results in real time and print them straight to STDOUT while your response is open. That's probably the simplest approach.
I have to run my scrolling gtk application on systems which are in network. But the display is slower when i try to run the application by doing telnet to other systems. Is there any way to render images fast on other systems? Can GdkDisplay be of any use here?
There are server-side (X server) and client-side image buffers. If your image is static it can be pushed to the server. If it is dynamic there are some ways to cache.
I've been playing around with the SDK recently, and I had an idea to just build a personal autotuner (because I am just as awesome as T-Pain).
Intro aside, I wanted to attach a high-quality microphone into the headphone jack, and I wanted my audio to be processed in a callback, and then copied to the output buffer. This has several implications:
When my audio-in is being routed through the built-in microphone, I need to be able to process this input, and send it once my input has stopped (this works).
When my audio-in is being routed through the microphone-in input from the headset jack, I want the output to be sent immediately.
Routing, however, doesn't seem to work properly when using AudioSession modes and overrides, which technically should allow you to reroute output to the iPhone speakers, no matter where the input is coming from. This is documented to work, but in practice, doesn't really work.
Remote IO, however, is not documented at all. Anyone with experience using Remote IO audio units, can you give me a reasonable high-level overview on how to do this properly? I have been using the aurioTouch example code, but I am running into errors where I get error codes like -50 and -10863, none of which are documented.
Thanks in advance.
The aurioTouch example implements remoteIO play through.
You could modify the samples before passing them on.
It simply calls AudioUnitRender in the output render callback.
NB this trick does not seem to work if you port the code
to OSX style CoreAudio. There, 99% of the time, you need
to create two AUHALs (RemoteIO-a-likes) and pass
the samples between them.