It is only editbin.exe you need which might floating around online on its own
somewhere...
Also I think the subsystem is specified in a byte in the header of a PE
executable so could be twizzled with a script that modifies that byte...
Probably an easy exercise for anyone who likes poking aroun
Ah! Now the light comes on. This example, with the background provided
in your previous post, make it all come together.
Thanks!
--
Richard Gaskin
Fourth World Systems
Mark Waddingham wrote:
> Just an update on my previous post. I did the following:
>
> Took a community standalone engine
Roger Eller wrote:
> Have you considered running a faceless Desktop app as a service,
> having it watch for a socket message...
Pierre Sahores and I have experimented with a wide range of socket
servers*, with some very promising results.
That said, our independent tests seem to arrive at the
Mark,
thanks a lot for taking the time to explain things here! Very valuable
information! I will certainly give it a try. Just need to install Vis Studio :-)
While you are here: would you think, that a call to cURL should work on Windows
server? For the life of me I can not get it to, even for
Hi Malte,
Just an update on my previous post. I did the following:
Took a community standalone engine from inside an installed LiveCode
distro on Windows and copied to the desktop.
Tried (from Command Prompt):
Standalone.exe -ui
Noticed that I just got a newline in the console, and nothin
On 2017-05-05 18:32, Richard Gaskin via use-livecode wrote:
Thanks for that background, Mark.
Please help me better understand the implications: does this change
mean that we can no longer run standalones facelessly on Windows by
just calling them with the -ui flag while hideConsoleWindows is t
Thanks for that background, Mark.
Please help me better understand the implications: does this change
mean that we can no longer run standalones facelessly on Windows by just
calling them with the -ui flag while hideConsoleWindows is true?
I have a number of apps that provide both GUI and fa
Mike Bonner wrote:
> Is there a specific reason you need to use a built exe for this? lc
> server can use stack files (start using path/to/stack) as well as
> "include"ing or "require"ing extra script files, so unless you're
> using functionality only available in the desktop version of lc, you
I think I see the problem here:
Any program that can read from stdin and write to stdout can be used as
a CGI, and this includes LC standalones...
- BUT -
LC Server scripts are incompatible with LC Script on the desktop.
In fact, it's that incompatibility that made me switch back to using
s
Hi Malte,
On 2017-05-04 20:34, Malte Brill via use-livecode wrote:
Hi all,
has anybody successfully done this? Especially on Windows? I would
like to launch a livecode built application from a liveCode server
script and get the output back (on a Server that I control) Is that
possible? If so, h
Is there a specific reason you need to use a built exe for this? lc server
can use stack files (start using path/to/stack) as well as "include"ing or
"require"ing extra script files, so unless you're using functionality only
available in the desktop version of lc, you might be able to bypass the
n
Could you have the LC Script pass a temp file name to the helper app
which can then write to that file rather than stdout ? (maybe not really
a "temp file", but simply a file chosen by the LC Server script based on
current millisecs time or some such thing, and deleted after everything
is finis
table -ui from LC server and get back a
result.
Hi Roger,
indeed, I have considdered that. But I have no experience on how this would
behave. Actually what I was trying to do is reducing the involved components,
instead of introducing more and more over the course of building the system. LC
- S
Hi Roger,
indeed, I have considdered that. But I have no experience on how this would
behave. Actually what I was trying to do is reducing the involved components,
instead of introducing more and more over the course of building the system. LC
- Server came natural there, as it would have allow
Have you considered running a faceless Desktop app as a service, having it
watch for a socket message, or a file, or even clipboard content to signal
it to do something. You could keep an account signed in with an app
running -with-or-without a UI.
~Roger
On Fri, May 5, 2017 at 6:48 AM, Malte Br
Hi Charles,
thanks a lot for the information. I am afraid I can not use it in this context,
as this is for an Open Source project. For other things this might be an option.
Cheers,
Malte
> Hi Malte,
>
> If you are able to use the commercial version of LC server, the tsNet
> external is suppo
Hi Malte,
If you are able to use the commercial version of LC server, the tsNet
external is supported which provides equivalent functionality to libUrl.
Regards,
Charles
On 5/05/2017 8:48 PM, Malte Brill via use-livecode wrote:
Thanks Dan, but that is not what I am after…
I have a server
Thanks Dan, but that is not what I am after…
I have a server side liveCode application, which needs to talk to a couple of
webservices from time to time. While this works nicely on the desktop, it does
not do so on Server, as Server lacks some libURL functionality. First
workaround was to shell
You can communicate between server and desktop using sockets. Chatrev is a
good example of this http://www.bjoernke.com/index.irev?target=chatrev
On 4 May 2017 7:34 pm, "Malte Brill via use-livecode" <
use-livecode@lists.runrev.com> wrote:
> Hi all,
>
> has anybody successfully done this? Especi
19 matches
Mail list logo
