Delphi needs a Remote Control component set
tony
I recently did a application that uses the regular VNC view and launches
it via a thread with create process and then the thread waits for the
viewer to close, it also uses zebadee to securely tunnel the VNC traffic
via local host, it all works, but is clunky and prone to syncro problems
with createprocess and slow PCs.
Delphi really needs a nice remote control component that you can just
drop on a form and use, like the VNCx component (activex).
VNC is slow, so I don't recomemd using that as a protocol.
Remote Office was great, but no longer supported and does not run on
windows server 2003 as a service(and possibly XP SP2).
Remote Office should be used as a benchmark, as it is excellent, it's a
shame it is no longer supported by the original author.
Is anyone interested in creating a new Remote Office type application or
component set? I would recommend it use Synapse as the TCP/IP transport
as it already has excellent SSL support built in and is super fast.
This type of project is to big for me to take on by myself, but it could
be done by a group of good coders.
It could be licensed under the BSD style license or similar.
If anyone is interested email me at sup...@amsoftwaredesign.com
Tony Caduto
Periklis
Just in time ! ... In few days we will release the most sophisticated remote
control component set ever done.
Why sophisticated ? It uses a _unique_ screen scanning algorithm and a
_extreme_ optimized tcpip library. Out test showed that our library BEATS
overall by 20%-40% RADMIN, VNC and PCANYWARE (we reach 20 screen updates on
an ISDN dialup connection and 1200 on a 100MBit LAN !)
So ... stay tuned
Periklis
"tony" <to...@yahoo.com> wrote in message
news:42a1cd78$1...@newsgroups.borland.com...
Periklis
Periklis
Dean Hill
> Just in time ! ... In few days we will release the most sophisticated
> remote control component set ever done.
>
> Why sophisticated ? It uses a unique screen scanning algorithm and a
> extreme optimized tcpip library. Out test showed that our library
> BEATS overall by 20%-40% RADMIN, VNC and PCANYWARE (we reach 20
> screen updates on an ISDN dialup connection and 1200 on a 100MBit LAN
> !)
>
> So ... stay tuned
> Periklis
Any idea on the what sort of pricing will be attached.
Cheers
Dean
tony
That sounds good, is it going to be a true component, where I can drop
it on a form? And will it be affordable? I won't be able to buy
anthing that is super expensive.
Tony
tony
also, i don't want to do any tunneling.
tony
If you can provide this in the price range of 99 to 200 dollars I guess
there would not be a need for another project.
But like I said before it would have to be affordable and have
encryption capabilities.
What about the option to use other TCP/IP transports like Synapse?
Synapse is very fast and has excellent SSL support built in that is
super easy to use.
Tony
Nils Haeck
- Does it also capture DirectX surfaces?
Nils
"Periklis" <peri...@mail.com> schreef in bericht
news:42a1...@newsgroups.borland.com...
Periklis
>- How does it transport the image? Losslessly?
Yes ... but _ONLY_ the changed portions ... it means that if u have the
cursor blinking, only few bytes will be sent (just the cursor blinking)
> - Does it also capture DirectX surfaces?
yes but there is limited support for directx (just for now) ...
regards
periklis
Periklis
About "us" first ...
We are 2 professional developers working in Greece in military
(telecommunication) sector. After 2 years of research and development we
make our dream come true ... we developed the best (so far) remote desktop
engine. After many tests and comparisons we decide to go public coordinated
by an experienced project manager.
About the product ...
We tried everything ... from RADMIN (which is far the best remote control
tool in the market at present time) and VNC to Remote Office (VCL) ... and
we came to the conclussion that nothing can compare to our engine .... So a
product was formed. Yes there will be a commercial product on the market
such as RADMIN and PCANYWARE utilizing our engine. We got cash but we did
NOT sell the engine ownership rights.
About the security ...
We use Diffie-Hellman key exchange algorithm with a 4098 bit key and 256Bit
AES encryption for everything (speed cost 1% throuhg fast asm routines) and
a very, very fast and extremely optimized TCPIP library.
About the component set pricing ...
FREE for non commercial usage, 10-30US$ for non competing ommercial usage
and 150-200US$ for competing commercial usage ...
The commercial product is a full mature remote control tool with more than
10 services such as filetransfer, multi user text and voice chat and more
... the component set includes only the tcpip library and the remote desktop
control engine as VCL components with all the security routines invloved ...
The hack is that there will be no engine, tcpi and security source code ...
Regards
Periklis
"tony" <to...@yahoo.com> wrote in message
news:42a1dfac$1...@newsgroups.borland.com...
Ingvar Nilsen
Interesting topic!
> Delphi really needs a nice remote control component that you can just
> drop on a form and use, like the VNCx component (activex). VNC is
> slow, so I don't recomemd using that as a protocol.
Yes, VNC is sloooow..
What about routers, would they let a proprietary protocol through?
--
Ingvar Nilsen
http://www.ingvarius.com
Periklis
> where the additional co-ordinate information for each pixel will eat up
> this advantage, and you need to send the whole screen instead.
Hehe ... that is generally true ... but NOT in our case ... that is where
the word "sophisticated" fits, believe me ...
Regards,
Periklis
Ingvar Nilsen
> Hello,
>
>
>> - How does it transport the image? Losslessly?
>
>
> Yes ... but _ONLY_ the changed portions ... it means that if u have
> the cursor blinking, only few bytes will be sent (just the cursor
> blinking)
That is fine, but you will eventually reach the point of intersection
where the additional co-ordinate information for each pixel will eat up
this advantage, and you need to send the whole screen instead.
Ingvar Nilsen
> and you need to send the whole screen instead.
Or at least define upper left and lower right co-ordinates for a
rectangle where something is changing.
I worked with similar things some years ago, a task where Delphi really
excels because of its versatility and power and speed.
Periklis
> I would bet ...
it is ... I wouldn't bet
Regards,
Periklis
Periklis
I would bet ...
Look ... winsock is veeery tricky ... in case you want to stream something
really fast ...
Nick Rollas
to server, not only server to client. That way, users behind firewall can
allow their pc to be remotely controlled. Like Remote Office does.
Nick
"Periklis" <peri...@mail.com> wrote in message
news:42a1...@newsgroups.borland.com...
Nick Rollas
"tony" <to...@yahoo.com> wrote in message
news:42a1cd78$1...@newsgroups.borland.com...
![Rudy Velthuis [TeamB]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWU6JIYTx6kJCxK1P9qy-0IkTLb3QUOOaGRszn1aPNSjVyUm9M=s40-c)
Rudy Velthuis [TeamB]
> Remote Office: I use it for months in 2003 and XP/SP2 and it works FINE
Nick, your message contained 39 lines although the only new content was
the line above. Could you please snip those parts of the the quotes that
are not important for the reply, next time? Thanks.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"Those are my principles. If you don't like them I have others."
-- Groucho Marx
George Karatsiolis
E, perimenw na kanw beta testing empeiro !
George Karatsiolis
Altext Software
"Periklis" <peri...@mail.com> wrote in message
news:42a1...@newsgroups.borland.com...
Rudy Velthuis [TeamB]
> Dont forget to put "Back connect" ability. That means the client can
> connect to server, not only server to client. That way, users behind
> firewall can allow their pc to be remotely controlled. Like Remote
> Office does.
Nick, please cut your quotes. No need to send a 68 line message to say
the above.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"Police arrested two kids yesterday, one was drinking battery acid,
the other was eating fireworks. They charged one and let the other
one off." -- Tommy Cooper
George Karatsiolis
E, perimenw na kanw beta testing empeiro !
George Karatsiolis
Altext Software
"Periklis" <peri...@mail.com> wrote in message
news:42a1...@newsgroups.borland.com...
Ingvar Nilsen
> Nick, please cut your quotes. No need to send a 68 line message to say
> the above.
While I agree, this:
===============
"Police arrested two kids yesterday, one was drinking battery acid,
the other was eating fireworks. They charged one and let the other
one off." -- Tommy Cooper
===============
is not needed to correct him <g>
Ingvar Nilsen
> <sigh>
Again?
> And any discussion on this is not required either. FWIW, most popular
> Usenet guidelines I know of agree that up to 4 or 5 lines of sig are
> OK.
With me it is perfectly ok. But so is also "overquoting" by a
non-regular here. What irritates me is you showing muscles when there is
no need.
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] wrote:
> > Nick, please cut your quotes. No need to send a 68 line message to say
> > the above.
>
> While I agree, this:
>
> ===============
> "Police arrested two kids yesterday, one was drinking battery acid,
> the other was eating fireworks. They charged one and let the other
> one off." -- Tommy Cooper
> ===============
>
> is not needed to correct him <g>
<sigh> And any discussion on this is not required either. FWIW, most
popular Usenet guidelines I know of agree that up to 4 or 5 lines of sig
are OK.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"Death is a low chemical trick played on everybody except sequoia
trees." -- JJ Furnas.
Rudy Velthuis [TeamB]
> What irritates me is you showing muscles when there is
> no need.
I think there is a need.
And I can't really consider whether that irritates you, or not.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"If Stupidity got us into this mess, then why can't it get us out?"
-- Will Rogers (1879-1935)
Ingvar Nilsen
> At 23:46:20, 04.06.2005, Ingvar Nilsen wrote:
>
>
>>What irritates me is you showing muscles when there is
>>no need.
>
>
> I think there is a need.
>
> And I can't really consider whether that irritates you, or not.
Likewise!
tony
inspect the packets. Where I work they don't inspect packets and I can
connect back to my house via ssh on port 443.
But a lot do inspect packets, so a http tunnel option would also be
needed for those circumstances.
I still think Synapse would be a great base to start something with
since it has the SSL part already working.
Tony
tony
why, I am going to try to completely disable the terminal services on
teh server to see if M$ put something in there that won't allow access
to the logged off desktop while their stuff is running.
It works fine once someone is logged in on the console, Some versions of
VNC also have the problem.
Ingvar Nilsen
> A lot of firewalls would let it through on port 80 or 443 if they don't
> inspect the packets. Where I work they don't inspect packets and I can
> connect back to my house via ssh on port 443.
>
> But a lot do inspect packets, so a http tunnel option would also be
> needed for those circumstances.
>
> I still think Synapse would be a great base to start something with
> since it has the SSL part already working.
Ok! Thanks. Sounds like we should roll our sleeves up!
tony
application created with the components to as many PCs as needed?
The pricing sounds good as long as it's royalty free and not a per
machine license.
>
> About the component set pricing ...
>
> FREE for non commercial usage, 10-30US$ for non competing ommercial usage
> and 150-200US$ for competing commercial usage ...
>
> The commercial product is a full mature remote control tool with more than
> 10 services such as filetransfer, multi user text and voice chat and more
> ... the component set includes only the tcpip library and the remote desktop
> control engine as VCL components with all the security routines invloved ...
I am not super concerned about the source to the whole thing, but can
the TCP/IP library be used
to add additional functionality like sending messages that the user
accepted your remote control request?
Or could I create my own chat protocol with your TCP/IP library and
combine it all into one server?
tony
Should a sourceforge project be started?
I have not done much graphic programming with Delphi, I can stream a
snapshot of the desktop back now with Synapse right now, that is not to
difficult,but things like getting the current desktop, capturing the
state of the cursor on the controled PC and updating sections that have
changed are new to me.
I do have a simple chat program already built with Synapse that works
just great, and I could donate that part, and I could do the file
transfer piece.
We need to recruit coders that know all about the graphics part, if we
can do that I think we could come up with something pretty nice.
Calling all graphics Gurus :-)
Tony
Ingvar Nilsen
> So I take it you are interested in doing something like this?
Yes.
> Should a sourceforge project be started?
At the time, I have no spare time, I have to use my time on projects
that bring me money. OTOH, I am open to discuss it with you.
See my tag line, use the sales mail adress.
> I have not done much graphic programming with Delphi
I have done tons of it :)
> I can stream a snapshot of the desktop back now with Synapse right
> now
I can not..
> but things like getting the current desktop, capturing the state of
> the cursor on the controled PC and updating sections that have
> changed are new to me.
This I can.. :)
Periklis
> Geia sou re patridaaaaaaaaaaa !!!
> E, perimenw na kanw beta testing empeiro !
Ela re megale ... stile mail sou sto periklis@-remove-mail.com
Sorry guys for the greek part of our conversation with George .... but we
greeks do not meet so often ... lol
Regards,
Periklis
Periklis
> Dont forget to put "Back connect" ability. That means the client can
> connect to server, not only server to client. That way, users behind
> firewall can allow their pc to be remotely controlled.
Is already implemented ... all done throught the same server and the same
port ...
Regards,
Periklis
Periklis
> Is the pricing per developer or per machine, I mean can I deploy a
> application created with the components to as many PCs as needed?
The prices are per developer, so u can install/deploy as many times you want
> The pricing sounds good as long as it's royalty free and not a per machine
> license.
Yes it is royalty free ...
Regards,
Periklis
tony
Periklis wrote:
> The prices are per developer, so u can install/deploy as many times you want
>
Ingvar Nilsen
> Hello George,
>
>
>>Geia sou re patridaaaaaaaaaaa !!!
>>E, perimenw na kanw beta testing empeiro !
>
>
> Ela re megale ... stile mail sou sto periklis@-remove-mail.com
This is Greek to me!
Periklis
> I am not super concerned about the source to the whole thing, but can the
> TCP/IP library be used
> to add additional functionality like sending messages that the user
> accepted your remote control request?
> Or could I create my own chat protocol with your TCP/IP library and
> combine it all into one server?
There is a ready to use multi-stream messaging framework implemented using
our tcpip library which can be used to define your own messages.
Regards,
Periklis
Rudy Velthuis [TeamB]
And if you do, you use the Roman alphabet? Or did it just look like that
to me?
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"When you hear hoofbeats, think of horses, not zebras."
-- Old saying
Dean Hill
> This is Greek to me!
:)
Rudy Velthuis [TeamB]
> Hello Rudy,
>
> > And if you do, you use the Roman alphabet? Or did it just look like
> > that to me?
>
> Sometimes it is easier to use the Roman alphabet (greeklish) because we
> can type faster without the need of typing the different types of "i"
> or "o" for example (there is i, y, ei, oi) ...
Amazing, I wasn't aware of that.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning."
-- Rich Cook.
Periklis
> And if you do, you use the Roman alphabet? Or did it just look like that
> to me?
Sometimes it is easier to use the Roman alphabet (greeklish) because we can
type faster without the need of typing the different types of "i" or "o"
for example (there is i, y, ei, oi) ...
Regards,
Periklis
Periklis
where the special greek characters are notated and we have to find where
o=w(?), x=ks(?) are ... :)
Regards,
Periklis
Periklis
Regards,
Periklis
Rudy Velthuis [TeamB]
> ... not to forget that some of us (greeks) do not habe a greek keyboard
> where the special greek characters are notated and we have to find
> where o=w(?), x=ks(?) are ... :)
I see.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"We had gay burglars the other night. They broke in and rearranged
the furniture." -- Robin Williams.
M Tuttle
remote
> control component set ever done.
You've got my attention too.
Will you have a Delphi demo available to show it in use?
Will it have a good help file availiable right away?
Do you have a website yet?
Don't tease us too long ;>)
Thanks
Mike
tony
If it's as good as you claim, I will probably buy two copies right after
I see a demo or try the non comercial version.
One for my personal business, and one for my corp "day" job :-)
Are you really going to release it this week?
Tony
Periklis
> If it's as good as you claim, I will probably buy two copies right after I
> see a demo or try the non comercial version.
> One for my personal business, and one for my corp "day" job :-)
Nice to hear that ... :)
> Are you really going to release it this week?
We are trying to settle some things down (with the company which will
release the commercial product utilizing our engine). We have to wait until
they come out ... We are told that it will be in 1 or 2 weeks ... but it is
not in our hands ....
It was a really hard game to keep the engine ownership ...
Regards,
Periklis
Periklis
> Will you have a Delphi demo available to show it in use?
Yes, there will be an extensive set of delphi demos
> Will it have a good help file availiable right away?
A good help file is always a must.
> Do you have a website yet?
Nope.
> Don't tease us too long ;>)
Hehe, I know ... I know ....
Regards,
Periklis
tony
ok) out on the net?
It's good you did keep the ownership, most developers will probably use
it (the components) for internal use and not release a competing stand
alone solution like PC Anywhere.
For me I currently use VNC to integrate with our HP radia system
management software and fire off the viewer with create process and use
the SQL tables to provide the users with all the Device IDs.
I could do all this much easier and cleaner with a Delphi component
based solution.
Thanks,
Tony
Billy
L505 @
> ===============
> "Police arrested two kids yesterday, one was drinking battery acid,
> the other was eating fireworks. They charged one and let the other
> one off." -- Tommy Cooper
> ===============
>
> is not needed to correct him <g>
>
>
hahahahahaha!
Periklis
I have attached some old screenshots of the remote control tool utilizing
our engine ...
see borland.public.attachements for "remote control tool screenshots" ...
PS: The name of the tool is not iDesk as seen in one screenshot ... the name
has been changed since the screenshots are pretty old ...
Regards,
Periklis
Jonathan Neve
We are shortly going to come out with a new component set for doing
this. It's based on Remote Office by Danijel Tkalcec, but we're in the
process of greatly reworking it:
1) It's going to be a set of components, not just a library (it will
also be available as an stand-alone application, but that's another matter).
2) It's being reworked to use Danijel's new Real Thin Client networking
framework. This means that it will be a plug-in to that framework, and
the two will probably be sold as a bundle.
3) We're implementing the whole thing over _standard HTTP_. We also
support going through the standard HTTP proxy, if one is set up on the
host machine.
4) We are also implementing a "gateway" feature, meaning that it will be
possible for both sides (admin and host) to connect to a gateway server,
from which they will be able to choose to be put in communication with
one another, and thereafter, all will work as though it had been a
direct connection. This is especially useful if the admin is behind a
corporate firewall, or if you could be roaming, with no permanent IP.
You can simply connect to the gateway, and provide service to you
clients no matter where you are!
5) We are working in partnership with Acclimate Inc, who purchased the
rights to Remote Office. We are therefore not bound by the Remote Office
licence, that forbade to sell the source code. However, I cannot promise
that the source code will be available, since I'm not the decider as far
as that's concerned. But it is a possibility.
There will surely be many more aspects, but these are the main lines. We
are currently working on it, and plan to release it soon. I'll post an
announcement here as soon as it's ready.
Regards,
Jonathan Neve.
Keith Blows
> Hi tony ...
>
> Just in time ! ... In few days we will release the most sophisticated
> remote control component set ever done.
>
> Why sophisticated ? It uses a unique screen scanning algorithm and a
> extreme optimized tcpip library. Out test showed that our library
> BEATS overall by 20%-40% RADMIN, VNC and PCANYWARE (we reach 20
> screen updates on an ISDN dialup connection and 1200 on a 100MBit LAN
> !)
>
> So ... stay tuned
> Periklis
Have you compared your engine against NetOp (http://www.netop.com)?
That has got to be one of the best remote control packages I have ever
seen.
Kind Regards,
Keith Blows
Danijel Tkalcec
Best Regards,
Danijel Tkalcec
Periklis
> Have you compared your engine against NetOp (http://www.netop.com)?
> That has got to be one of the best remote control packages I have ever
> seen.
It is one of the best indeed ... but we get 10% _more_ screen updates than
netop.
To be honest, netop uses also a very sophisticated driver technology which
parses the whole screen activity and send it as commands. But in most cases
you will not get a "clean" output using that mode.
There was no need for us to go so far ...We can set (in our engine) the
maximum screen updates to 25 (we reached 1300) and we get a REALTIME screen
output with no more than 1%-2% CPU usage (pentium 4 2.8Ghz, nvidia GForce4
MX 4000 graphic card and without the mirror driver in use !). Besides the
setup package of the remote control tool utlizing our engine is not bigger
than 800kb (client+server) ...
Regards,
Periklis
PS: Netop became too bloaded for an everyday user (and not only) ..
Jonathan Neve
> Have you compared your engine against NetOp (http://www.netop.com)?
> That has got to be one of the best remote control packages I have ever
> seen.
Looks like a very interesting product. There are lots of good ideas
there: some I had already planned on implementing, others already are
implemented.
But there is at least one big difference: they are only selling it as an
end-user application, not as a developper component set. Also, the fact
that they don't state the price anywhere (or least, I can't find it)
indicates that it's probably very expensive.
Still, it does look very good, and I'll do my best to make sure all the
features of NetOp are made available in SupportBridge (except that I
don't plan, in the foreseeable future, to support other platforms than
Windows, and Linux in part). :)
Regards,
Jonathan Neve.
Keith Blows
> Hello Keith,
>
>
> > Have you compared your engine against NetOp (http://www.netop.com)?
> > That has got to be one of the best remote control packages I have
> > ever seen.
>
>
> It is one of the best indeed ... but we get 10% more screen updates
> than netop.
>
> To be honest, netop uses also a very sophisticated driver technology
> which parses the whole screen activity and send it as commands. But
> in most cases you will not get a "clean" output using that mode.
>
> There was no need for us to go so far ...We can set (in our engine)
> the maximum screen updates to 25 (we reached 1300) and we get a
> REALTIME screen output with no more than 1%-2% CPU usage (pentium 4
> 2.8Ghz, nvidia GForce4 MX 4000 graphic card and without the mirror
> driver in use !). Besides the setup package of the remote control
> tool utlizing our engine is not bigger than 800kb (client+server) ...
Wow. Whoops, lemme wipe up that drool...!
> Regards,
> Periklis
>
> PS: Netop became too bloaded for an everyday user (and not only) ..
Yes, I'm afraid it did become a bit bloated, but still a lot more
compact than pcAnywhere...
Keith Blows
> Hello Keith,
>
>
> > Have you compared your engine against NetOp (http://www.netop.com)?
> > That has got to be one of the best remote control packages I have
> > ever seen.
>
>
> It is one of the best indeed ... but we get 10% more screen updates
> than netop.
>
> To be honest, netop uses also a very sophisticated driver technology
> which parses the whole screen activity and send it as commands. But
> in most cases you will not get a "clean" output using that mode.
>
> There was no need for us to go so far ...We can set (in our engine)
> the maximum screen updates to 25 (we reached 1300) and we get a
> REALTIME screen output with no more than 1%-2% CPU usage (pentium 4
> 2.8Ghz, nvidia GForce4 MX 4000 graphic card and without the mirror
> driver in use !). Besides the setup package of the remote control
> tool utlizing our engine is not bigger than 800kb (client+server) ...
Wow. Whoops, lemme wipe up that drool...!
> Regards,
> Periklis
>
> PS: Netop became too bloaded for an everyday user (and not only) ..
Yes, I'm afraid it did become a bit bloated, but still a lot more
compact than pcAnywhere...
Keith Blows
NetOp v8.x for Windows - Combo Pack (1 Guest/1 Host) $199.00
NetOp v8.x for Windows Guest (1) + 10 Host Pack $900.00
NetOp v8.x for Windows - Gateway $405.00
NetOp v8.x for Windows - Guest Only $155.00
NetOp v8.x for Windows - Guest 10 Pack $1,145.00
NetOp v8.x for Windows - Guest 25 Pack $2,710.00
NetOp v8.x for Windows - Host Only $155.00
NetOp v8.x for Windows - Host 10 Pack $760.00
NetOp v8.x for Windows - Host 25 Pack $1,460.00
NetOp v8.x for Windows - Host 50 Pack $2,460.00
NetOp v8.x for Windows - Host 100 Pack $4,385.00
NetOp v8.x for Windows - Name Server $680.00
NetOp v8.x for Windows - Security Server $1,380.00
Regards,
Keith Blows
Keith Blows
> Keith Blows wrote:
> > Have you compared your engine against NetOp (http://www.netop.com)?
> > That has got to be one of the best remote control packages I have
> > ever seen.
>
> Looks like a very interesting product. There are lots of good ideas
> there: some I had already planned on implementing, others already are
> implemented.
>
> But there is at least one big difference: they are only selling it as
> an end-user application, not as a developper component set. Also, the
> fact that they don't state the price anywhere (or least, I can't find
> it) indicates that it's probably very expensive.
NetOp v8.x for Windows - Combo Pack (1 Guest/1 Host) $199.00
NetOp v8.x for Windows Guest (1) + 10 Host Pack $900.00
NetOp v8.x for Windows - Gateway $405.00
NetOp v8.x for Windows - Guest Only $155.00
NetOp v8.x for Windows - Guest 10 Pack $1,145.00
NetOp v8.x for Windows - Guest 25 Pack $2,710.00
NetOp v8.x for Windows - Host Only $155.00
NetOp v8.x for Windows - Host 10 Pack $760.00
NetOp v8.x for Windows - Host 25 Pack $1,460.00
NetOp v8.x for Windows - Host 50 Pack $2,460.00
NetOp v8.x for Windows - Host 100 Pack $4,385.00
NetOp v8.x for Windows - Name Server $680.00
NetOp v8.x for Windows - Security Server $1,380.00
> Still, it does look very good, and I'll do my best to make sure all
> the features of NetOp are made available in SupportBridge (except
> that I don't plan, in the foreseeable future, to support other
> platforms than Windows, and Linux in part). :)
Problem is: when? SupportBridge has been a lot of talk, but I've seen
very little recent development and I believe you are only getting
started with it now? I am impressed with RO/SupportBridge, but it
hasn't advanced in some time...
Regards,
Keith Blows
Rudy Velthuis [TeamB]
<snip>
I cancelled that. Such lists only belong in thirdpartytools.general.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"What I am against is quotas. I am against hard quotas, quotas they
basically delineate based upon whatever. However they delineate,
quotas, I think, vulcanize society. So I don't know how that fits
into what everybody else is saying, their relative positions, but
that's my position." -- George W. Bush
Tony Caduto
Office, is not a true component set.
Antonio Alcázar
http://www.multite.es/granprimo
Really, is not the same concept than the other products than you say , and
is a mix of Delphi (server) and Java (for remote desktop access)
Is http oriented, and have delphi and activex version.
Really is a remote control engine not based in any socket library, and there
is examples for use it in Indy, Intraweb and an 'alone' version (with mi
little socket library).
So I think than maybe its easy to move it to other TCP/IP transport library
like Synapse,
But here is my questions;
Realy, what library is more used for TCP/IP platform ?
Is good than the remote control system use a standart library for TCP/IP or
better any other a bit more optimized but not so reusable ?
I read msg in this thread for the rating of screen refresh even greater than
1000 x second, is really this necesary ? (When great the refresh rating,
great the resources used in the net and CPU)
That is only my sand grain.
Thank you
Antonio Alcázar
> Is anyone interested in creating a new Remote Office type application or
> component set? I would recommend it use Synapse as the TCP/IP transport
> as it already has excellent SSL support built in and is super fast.
Tony Caduto
That sounds great, we will at last have some choices for remote control
then. For years there was nothing.
Full source is not that big of a deal, as long as it's the DCUs.
Also pricing is pretty important, I won't pay more than 99 to 199 for
such a set.
you might want to thing about having a corp version, because corps can
pay more, but I wouldn't go about 599.00 for a corp version.
Just don't forget about us non corp developers :-)
Jonathan Neve
> Support Bridge seems a little pricy,and if it is still like Remote
> Office, is not a true component set.
As I explained, I'm planning to making it into a component set shortly.
I'm reworking it completely, and that's one of the things I'm going to do.
As for the price, Support Bridge is indeed quite pricy at present, but
that's for the full-source code. When we start commercializing SB as a
component-set (plug-in to RTC), we will have to make a new pricing
model. I can't give you more detail than that for now, because I'm not
in charge of the pricing (as I said, I'm not from Acclimate), but I'll
let you all know as soon as it's ready.
Regards,
Jonathan Neve.
Jonathan Neve
> Problem is: when? SupportBridge has been a lot of talk, but I've seen
> very little recent development and I believe you are only getting
> started with it now? I am impressed with RO/SupportBridge, but it
> hasn't advanced in some time...
You're quite right, it hasn't advanced much since the purchace of RO.
First of all, we spent a bit of time getting organised (I'm not from
Acclimate, I'm just a partner, but I'm in charge of the development),
before doing any actual development. Then, I must admit that I found
Danijel's code a bit complex; good code, but not easy to get into. This,
along with the fact that we're not making any money off it yet,
contributed to making it difficult to find time for it...
Anyway, we've recently decided to rework SB to use Danijel's new
framework, RTC, which, as I explained offers many advantages, as well as
making the code considerably simpler, due to the component-based
architecture. I'm currently working on this, and I promise that
development will start advancing much faster than it has until now.
Anyway, I'll let you know shortly, as soon as there's something to try out.
Regards,
Jonathan Neve.
Danijel Tkalcec
"Rudy Velthuis [TeamB]" <velt...@gmail.com> wrote in message
news:xn0e36fb840nn...@www.teamb.com...
Danijel Tkalcec
I never post to more than one group (unless it's a reply to someone's post).
Best Regards,
Danijel Tkalcec
Danijel Tkalcec
can tell you why you have the low CPU usage. It's mostly because of the
Graphics Card. You will have the same results with RemoteOffice and
Support-Bridhe on the same configuration, since RO and SB also use a highly
optimised assembly code for screen capturing and compression. To get the
real CPU usage on an average PC (which is what a lot of customers have), you
would need to use a bit slower host PC (up to 1 GHz) with some other
(non-nVidia) graphics-card.
Best Regards,
Danijel Tkalcec
Danijel Tkalcec
> of CPU.
The problem was solved after I implemented the Hooks.
Best Regards,
Danijel Tkalcec
Danijel Tkalcec
screen hooks, or you will end up using more than 50% CPU, especially on high
resolutions, no matter how fast your compression algorithms are. Even the
first RO version (before I optimized the compression algorithms) worked with
average 5-10% CPU on a 1 GHz pentium with 1024x768 in true-color mode with
the n-Vidia Graphics card and 25 FPS. Since I only used nVidia Graphic
Cards, I was surprised when someone complained about RemoteOffice using up a
lot of CPU.
Best Regards,
Danijel Tkalcec
Danijel Tkalcec
the time to come, a lot of them based on the original RemoteOffice source
code. I'm sure there's also parts of RemoteOffice in the product being
offered from Periklis, since he's also one of licensed RemoteOffice users.
And I can tell you that this is a great feeling. I just wonder why it took
so long for someone to get the idea to implement something like that with
Delphi ;)
Best Regards,
Danijel Tkalcec
Periklis
I don't want to start any discussion with you about what my engine uses and
why this and why that. We know better how _our_ engine works and why it
outperforms anything else on the market .... In a few days you will test it
yourself ...
Jsut my 2 cents,
Periklis
Danijel Tkalcec
want to point out that in your configuration, RemoteOffice will perform the
same. You can try it out for yourself. And since you're a licensed
RemoteOffice user, I guess you already did.
Best Regards,
Danijel Tkalcec
Danijel Tkalcec
RemoteOffice a year ago (with full source code for something like 95 EUR), I
will most likely be one of your first customers, since I'm very interested
to see how other people solved the same problems I had to solve in
RemoteOffice.
Best Regards,
Danijel Tkalcec
Danijel Tkalcec
Best Regards,
Danijel Tkalcec
Periklis
THERE IS NOT A SINGLE LINE OF YOUR CODE USED IN OUR ENGINE. HOW CAN YOU
ASSUME SOMETHING LIKE THAT !
we bought your code to see what technology is used ... after half an hour of
struggling ... we convinced ourselves that we just lost our money ....
We had a conversation you on your forum in the past if you can remember
about the bad quality and the poor performance of your code and about the
GDI hooks that are NOT GDI hooks ... so how could we use something like that
?
(I can repost it here if you continue lying offending and beeing rude)
Danjiel,
your code had nothing serious to offer ... just undocumented spaggeti ....
we are doing serious business here.
Just my 2 cents,
Periklis
PS: I said in my post below that I dont what to start a discussion with you,
but your post here was too much.
Danijel Tkalcec
wrong that you used my code to learn something from it, but it wasn't a lie.
After all, it's almost 2 years since you bought the RemoteOffice license,
which would give you enough time to studdy it and build something new, even
without using lines from the original RemoteOffice code. Anyway ... I don't
remember any discussions about "poor performance" of my code after I
implemented the "GDI" Hooks (it's actually a global message hook, capturing
update messages sent to windows, but I didn't find a better word for it than
GDI). And when you bought the code (this was October 2003), if you really
spent only half an hour on struggling with it, I wonder how you could have
argued with me about its poor performance with "GDI" Hooks, since I added
those Hooks in February 2004 (almost 4 months later).
Well, I don't think I need to comment your remarks about throwing my
"undocumented spaghetti" code after spending half an hour on "struggling",
since there are other commercial solutions which use RemoteOffice source
code and people who manager quite well to use the code.
Best Regards,
Danijel Tkalcec
Periklis
we didn't solve anything because we do NOT use third party code ... we use
"homemade" well tested code ....
Periklis
Danijel Tkalcec
If you wrote the remote desktop code, you had to solve a lot of problems
related to remote desktop control, or you wouldn't have a working product.
Or did you use some existing remote desktop solution which already
implemented the remote decktop control part?
Regards,
Danijel Tkalcec
Danijel Tkalcec
You seem to react pretty unforgiving to anything I write.
Best Regards,
Danijel Tkalcec
Periklis
get a life ... period ... i don't waste my time with you anymore
Periklis
If you want to here it so much and you do NOT stop it ...
... because I do not like your attitude in the past and in the present ...
Periklis
PS (for the reader): Sorry guys for the famming ... my "contribution" stops
here ... sorry again ....
Periklis
> After all, it's almost 2 years since you bought the RemoteOffice license,
> which would give you enough time to studdy it and build something new,
> even without using lines from the original RemoteOffice code.
study what, where ???
> Anyway ... I don't remember any discussions about "poor performance" of my
> code after I implemented the "GDI" Hooks (it's actually a global message
> hook, capturing update messages sent to windows, but I didn't find a
> better word for it than GDI).
global message hook = GDI => I am NIGERIAN
> And when you bought the code (this was October 2003), if you really spent
> only half an hour on struggling with it, I wonder how you could have
> argued with me about its poor performance with "GDI" Hooks, since I added
> those Hooks in February 2004 (almost 4 months later).
I visited ONCE your forum because I made a url cleanup .... and there I saw
people trying to convince you to help them out and you had the
"do-it-yourself" attitude .. it was so unfair, so I decided to give my 2
cents ....
> Well, I don't think I need to comment your remarks about throwing my
> "undocumented spaghetti" code after spending half an hour on "struggling",
> since there are other commercial solutions which use RemoteOffice source
> code and people who manager quite well to use the code.
commercial usage ? huh who ? where ? 1 or 2 or 3 ? ... lol ... be serious
....
Support Bridge didn't manage to do a thing with your code.
The fact that they are reworking (!) the "ready-to-go" code (!) that they
had paid MONEY trying to find a developer (see SB forum) shows my point ....
And the "Remote support" product, it was the only serious try to make
something nice (more GUI ) out of your work.
But in his case his is ALSO integrating his own code (see his post)
replacing yours (!). ... the "ready-to-go" code the he paid MONEY for it ...
Danijel,
I told you when we had that conversation, the world is small ... once bad
reputation .. always bad reputation ....
Periklis
PS: Respect the others in order to be respected ....
Danijel Tkalcec
Nice to meet you. I am CROATIAN ;)
> I visited ONCE your forum because I made a url cleanup .... and there I
> saw people trying to convince you to help them out and you had the
> "do-it-yourself" attitude .. it was so unfair, so I decided to give my 2
> cents ....
You're just pulling rabits out of your hat. I was wotking by butt off to
implement anything someone would want. There were mor people annoyed by me
doing more than one update a day, than people not geting their feature
added. Here's a snippet from the updates which I did, on requests from my
RemoteOffice customers:
--------------------------
-----------
19.04.2004. > version 2.12b
-----------
* Disabling Keep-alive signal for custom transports
If you've tried the "Custom Transport Test" program after version 2.11, you
may have noticed
that it didn't work. The reason for this are newly added keep-alive signals,
which I didn't
implement for the test transport. From version 2.12b, this test program will
also work correctly.
Since custom transports are not implemented in the same manner as standard
Winsock transport
that comes with Remote Office, I added the possibility to disable the
keep-alive control.
This is done simply by defining the "CUSTOM_TRANSPORT" compiler directive
for the project.
-----------
09.04.2004. > version 2.12
-----------
* Keep-alive signal changed
Seems like the theory about 2 and 6 seconds is not as good as I thought.
Anyway ...
to get on the safe side, I changed the keep-alive signal intervals from 2 to
3 seconds
and the connection control from 6 to 15 seconds. That should be enough for
any kind of
connection, even the slowest one.
-----------
10.03.2004. > version 2.11
-----------
* Keep-alive signal
- All Remote Office tools now transmit "ALIVE" signal if no other data is
being sent. This ensures keeping the connection open even if there is no
real transmission happening. This signal is transmitted automatically if
there was nothing else to send for the last 2 seconds.
- To ensure that all connections we see are still alive, we need to close
all connections that ere "dead". Since all tools send "ALIVE" signals
out
every 2 seconds, we will be receiving something if the connection is
alive.
So, all Remote Office tools will automatically close each connection if
nothing has been received through that connection over the last 6
seconds.
Those periods (2 and 6 seconds) have been chosen for two reasons:
1. Two seconds between each "ALIVE" signal is long enough period to keep the
bandwidth usage low when there is no activity, but high enough to tell
any
connection daemon that we are still using the connection.
2. Six seconds is three times the period other side uses to transmit the
"ALIVE"
signal. Six seconds is more than enough time to open a connection and
send the
first ALIVE signal out, using the slowest transport I can imagine.
Auto-connect feature ensures that a new connection will be open once the old
connection is closed. Using this new enhancements, you can rest assured that
you WILL get a new connection from Server once your active connection drops.
Version 2.11 is not backwards compatible with any other old version,
because:
1. In version "2.11", all tools send a new code out, which is unknown to all
old versions. Once the old version receives an unknown code, it will
close the
connection automatically, because that is treated as a communication
error and
can't be tolerated. New version behaves the same when they receive an
unknown code.
Codes are not procedures, they're procedure types and there is a fix
number of
codes in use in Remote Office communication protocols, no matter how many
procedures you may add yourself.
2) Old versions don't send keep-alive signals, which will make the new
version
close the connection if nothing is received for 6 seconds. But, since the
new
version will send the "ALIVE" signal out if there's nothing else to send
for
2 seconds, it is more likely that the old version will close the
connection
because of receiving an unknown code.
* Abort procedure removed
- removed the "SendAbort" procedure from TDataCom, since it's of no use.
- also had to remove this call from File Explorer (that's where it was
"used").
-----------
09.03.2004. > version 2.10
-----------
* Internal patch
- changed some internal string limitations to accept more chanarters.
-----------
06.03.2004. > version 2.09 +
-----------
* RemHook.dll
- Added thread safety, in case some apps send and process window messages
in threads other
than the main thread. Also added aditional check for "hooked" processes.
It sounds more
complicated than it really it. Changes made only to "RemHook.dpr"
project.
-----------
02.03.2004. > version 2.09
-----------
* Desktop Veiwer as a VCL component
- From this version on, it will be much easier for you to customize the
Desktop Viewer,
since all the functionality is being kept in one VCL component.
- There are still a lot of events to be defined and set up for this
non-visual component
to work, but I took the challenge ;) and replaced the old Remote Desktop
Viewer with
a new one, by using the VCL component.
- To avoid the need for registering the component implemented in
"dcDesktopVCL" unit,
I decided to create the component dinamically on Forms create event and
destroy it on
forms Destroy event. If you want, you can also do this by registering
the component in
Delphi palette ("Remote") and setting all its properties at design time.
-----------
28.02.2004. > version 2.08
-----------
* WinSock transport
- For whatever reason, Microsoft split TCP/IP protocol into TCP and IP. On
some systems,
searching for the TCP protocol fails. On other systems, searching for IP
protocol fails.
And on third systems, no protocol can be found, although there is the
TCP/IP protocol
installed and functioning. To aviod all those problems, I changed the
way how protocol
search is done. Now, I'm searching for TCP, then for IP and if none
found, use a fixed
protocol number "0" (normaly assigned to "IP"). That should solve this
problem.
-----------
26.02.2004. > version 2.07
-----------
* GDI Hooks update
- when auto-connect feature is active and GDI Hooks are loaded,
Windows doesn't want to log current user out. To be able to log out
while
keeping both features available, I changed GDI Hooks to load dynamically
when first user activates it and unload after the last user deactivates.
- Since GDI Hooks only work when you're logged in, you should deactivate
GDI Hooks before you log out. If you try to log out while GDI Hooks are
still active, nothing bad will happen, but you won't be able to log out
until you deactivate GDI Hooks.
-----------
25.02.2004. > version 2.06
-----------
* GDI Hook update
- "RemHook.DLL" updated to scan whole screen on Menu events
* RemService update
- Better support for multiple user accounts
- Can also be installed as a non-interactive service
(GDI Hooks won't work if service is non-interactive,
but the standard screen-scanning mode will work correctly)
- Renamed the TService component to "Remote_Service" (it was named
"Service1" before)
-----------
08.02.2004. > version 2.05
-----------
* Chat update
- checking username and displaying it instead of "Anonymous"
- sending username on every keypress
- enabling Edit field automatically
- using RichEdit with colors instead of simple Memo for history
* Desktop session Info-Window
- bringing the Window to foreground and activating it
* TCP/IP Winsock protocol patch
- Check if the TCP protocol is installed and throwing the right exception.
Older versions would just generate Access Violations if TCP protocol is
not installed.
-----------
02.02.2004. > version 2.04
-----------
* GDI Hooks update
- optimized for better performance and updated to catch more screen
updates.
- now also working with RemService.
-----------
01.02.2004. > version 2.03
-----------
* Full screen mode can now display:
- Larger server desktops using scroll-bars
(when "Scale to screen" is not down)
- Smaller server desktops scaled to full screen
(2nd click on "full screen" with "Scale to screen" down)
- Smaller server desktops centered to full screen
(2nd click on "full screen" with "Scale to screen" up)
* Second GDI Hooks implementation (beta)
-----------
30.01.2004. > version 2.02+ beta GDI
-----------
* First GDI Hooks implemenation
-----------
27.01.2004. > Version 2.02
-----------
* Remote Desktop Server-side Bugfix
- The fix for Remote Desktop that allowed using Close/Minimize
buttons from Client to close/minimize the Server created a
problem for some other applications, which didn't like the fix.
So, now I did another change, so that the fix will now only
be applied for Windows which the Server Application owns.
This means, we now have a clean solution for this problem :)
Library changes: dcCapServer
-----------
26.01.2004. > version 2.01+
-----------
* Remote Desktop default options
- now you only have to set "Down" properties for buttons and "Checked"
properties for Menu items in the Delphi form Designer if you want to use
different default Viewer settings for your Remote Office (for example,
full-screen mode instead of scaled window, auto-refresh on open, etc).
Library changes: dcDesktop
-----------
26.01.2004. > version 2.01
-----------
* Minimize to Tray
- Now all Applications main forms can be minimized to Tray icon.
One click on the Tray icon is enough to bring the Form back up.
RemServer and RemRouter are now automatically minimized to tray when
you click "GO!" (just click on the Tray icon to bring them back up).
Using this new feature, you won't have to close the Client and Admin every
time
you don't need them. Just minimize them to Tray and they'll be out of your
way.
Library changes: none
Form changes: all
-----------
24.01.2004. > version 2.0
-----------
* "Waiting to accept connection" bugfix
- Changed the way that "accept remote desktop session" feature is working,
so that no modal dialogs are used and all things work as they should.
Just take a look at it and tell me what you think ;)
I tested this version myself and found it working as stable as it goes.
Since there were no unresolved problems reported until now, I decided to
declare this release a stable one. Having all known problems solved,
I'm happy to announce the next bug-free and stable release, version 2.0
Library changes: dcProcess, dcCapServer, dcDesktop, dcWinRemUserAsk
-----------
24.01.2004. > update 1.9.9+
-----------
* Waiting for the remote user to accept Desktop session
- using configuration settings, you can configure your RemServer to wait
with sending data to RemClient/RemAdmin until the user sitting in front
of the remote PC clicks on "YES, Thats OK" or some timeout period
expires.
To configure this, use this parameters in the CFG file:
[User]
Ask => do you want to not allow access until confirmed?
(accepts: yes, y, 1 for TRUE, everything else for FALSE)
Timeout => time to wait until automatically confirmed (time in seconds).
If left empty, no automatic configmation.
If number specified, automatic confirmation after specified
time in seconds (dialog closes with "OK").
-----------
24.01.2004. > update 1.9.9
-----------
* Bugfix when connecting/disconnecting
- when connecting/disconnecting, CPU would jump to 100% on older versions.
This was because there was no Sleep in the loop that processed messages.
This caused all CPU being used for this loop. The problem is solved in
this version, using Sleep(1) after every Application.ProcessMessages :)
Library changes: dcProcess
-----------
23.01.2004. > update 1.9.8+
-----------
* Bugfix in Wallpaper function
- Wallparew would be removed, but could not be restored.
This is fixed in this update. Now, I don't ever relly remove
the wallpaper from Registry. I just do it temporarily and call
Update to hide it. Then I rerutn it back to registry. This way,
hiding the Wallpaper doesn't really change any system settings.
Library changes: dcCapServer
-----------
23.01.2004. > update 1.9.8
-----------
* SILENT_MODE compiler directive
- changed compiler directive "SILENT_MODE" to "SILENTMODE"
Library changes: dcCapServer, RemService_Unit
* Desktop: Hide/Show Wallpaper
- Now you can choose to hide desktop Wallpaper directly from Remote
Desktop.
Desktop wallpaper will be returned to its previous state automatically
when you close Remote Desktop, when connection is closed or when you
choose the "Show Wallpaper" option.
Library changes: dcCapServer, dcDesktop
* Desktop: context-menu in Passive mode
- When you're in passive mode (view only mode), you can use the right
mouse button anywhere on Desktop View to open the Menu. All options
that have some meaning in Passive mode are now available there.
The same Menu opens when you click on the Eyes icon in Remote Desktop.
Library changes: dcDesktop
* Desktop: Passive mode behaviour
- Now, going to passive mode doesn't change any options you set before
(like "mouse clicks", "keyboard", etc), it just disables them. So, when
you return to Active mode, all options are the way you left them. Also,
Server input lock is now not deactivated when moving to Passive mode (no
options are changed). You can (Un)Lock server input from the popup Menu.
Library changes: dcDesktop
-----------
22.01.2004. > update 1.9.7
-----------
* Desktop: Passive mode (minimal viewer)
- Passive mode hides Window Caption and options palette, transforming
Remote Desktop window to a minimal viewer. A simpel double-click on
the Viewer changes it back to normal Remote Desktop form, with all
options visible.
- When mouse clicks and movements are not activated (not sent to server),
you can drag desktop window by using left mouse button anywhere
on Desktop image. You can also use double-click or right mouse button
to immediatelly switch to/from Passive mode (minimal viewer).
- Using this feature, you can use a number of minimal monitor forms to
have instant active view into several Remote PC Desktops, with the
abbility to remotely control any of those PCs using a simple
double-click
on the viewer form and choosing the control level you want.
- This is client-side implemented and also works with old Server versions.
Library changes: dcDesktop
-----------
22.01.2004. > update 1.9.6
-----------
* Remote Desktop can Lock Server Input
- Now you can lock remote PCs mouse and keyboard input from remote
Desktop.
When remote PCs mouse and keyboard are locked, users sitting in front of
those PCs can't use mouse or keyboard to interfere with your actions.
But,
they can use <Ctrl+Alt+Del> combination to unlock input (if they know
this).
Library changes: dcCapServer, dcDesktop
* Remote Desktop option palette redesign
- Replaced Combo boxes with a popup menu, accessible from one speed
button.
This saves a lot of space and gives me the opportunity to add new
features to Remote Desktop, without making the options palette to wide.
- Removed child Panels & added a small line to group related options.
- Changed Get/Send clipboard buttons to something more meaningful (IMO).
Library changes: dcDesktop
* Unwanted disconnects for unregistered options fixed
- Changed core lib behaviour, so that we won't be disconnected from Server
if we call remote procedures which are not registered. Instead, if we
define a callback routine to accept the result, we will receive the
error message from server (TDataCom.LastErr), so we can react to it
(for example, show a message "Option not available" and close the
window).
- Used this new option to check if Chat/File Explorer/Desktop functions
are available on the server to which we're connected. When you click
on the option that is not available, you will get to see a message like
"XYZ option is not available. Remote procedure "abc" is not
registered.".
Library changes: dcProcess, dcDesktop, dcFileExplorer, dcChat
-----------
21.01.2004. > update 1.9.5
-----------
* Service logout/restart/shutdown problem solved
Only by not using Forms from the Service version of Remote Server, all
problems regarding Windows logout/restart/shutdown dissapear. Since
Services
normally work in the background with no visible user interface, and only
Admins
can install them, I think it's OK if Service doesn't interract with the
user.
To do that, I did some changes:
- added "SILENT_MODE" compiler directive to RemService project.
- when "SILENT_MODE" is declared, Server doesn't doesn't display the
remote desktop notification forms (dcCapServer unit).
- also, Chat is not compiled into Remote Service (dcChat unit)
if you declare the SILENT_MODE compiler directive.
You can choose for yourself if you want to compile your Service version with
or
without those Windows. Since everything works OK in Windows XP, you may want
to
turn the Windows ON for your version. To do this, you just need to remove
the
new compiler-directive "SILENT_MODE" from your Project.
Library changes: dcProcess, dcCapServer
Form Changes: RemService_Unit
* created RemDesktop -> minimal Remote Server
Using a config file, you can use the RemDesktop server version the same
way
as you use RemService, only that it runs as a process in Background (no
visible
windows until Desktop session or Chat is started) and doesn't have to be
installed.
Since this is a process version (and not service version), you can put it
into
Windows "AutoStart" folder or register it to start from Registry (Run).
You can
design the splash screen as you like. It will be displayed for 1 second
(or longer,
if you change timer Interval value) and be hidden if Server started
normally.
You can use the Server as normal Listener or to Auto-Connect to RemAdmin.
Forms added: RemDesktop_Unit
Projects added: RemDesktop (only for Delphi)
-----------
21.01.2004. > update 1.9.4
-----------
* Auto-connect feature changed
- Changed the way auto-connect is working. Old version used a Timer to
wait for
a while if a connection was lost before trying to connect again, while
this
new Version works without a timer and tries to open the connection again
immediatelly (when it gets the message that the connection is lost).
Hope this
will solve the problem of not being able to shut the Service down while
Auto-connect feature is active.
* Closing all forms manually
- Added a loop to close all open forms "manually" when app receaves the
WM_QueryEndSession message (meaning Windows is shutting down).
- Doing the same thing on Service Stop and Shutdown. Hope this one solves
the
Chat Window shutdown problem for RemService.
Library changes: dcClientCon, dcProcess
Form changes: all
-----------
20.01.2004. > update 1.9.3
-----------
* Auto-Connect shutdown
- Added shutdown procedure to close all active auto-connecting objects and
called it on WM_QueryEndSession before Halt;
Library changes: dcClientCon
Form changes: all
* Removed Message processing from Threads
- Since Threads don't get any messages (they communicate using Events),
I've now removed massige processing from read/send/process Threads and
returned timeout value to INFINITE, as it was before. In all my tests,
this version performed equal or better than the old version, without any
side-effects. If someone should encounter some problems that in his
oppinion can relate to Threads not processing messages (although they
shouldn't be receiving any messages), please post the problem to the
Remote Office forum.
Library changes: dcProcess
-----------
19.01.2004. > update 1.9+ (3rd)
-----------
* Handling WM_QueryEndSession message by hand to kill the Server.
- Hate myself for doing this, but it just won't work any other way.
There are no problems when you close the program and if you call
Application.Terminate will also close it without exceptions, but
Windows doesn't want to shut down if application doesn't close
immediatelly. And the only way I found for doing this was to kill
the process when it receives the WM_QueryEndSession from Windows.
This doesn't do us any harm, because we do need to close immediatelly,
but it's not a nice approach for doing it.
If anyone finds a better way for clean application shutdown when
Windows wants to close all programms, I'll be happy to embrace it.
Library changes: dcProcess
Forms changed: all (RemService got new Event: "OnShutdown").
-----------
19.01.2004. > update 1.9+ (2nd)
-----------
* Changed servers read priority to equal Clients
- This change makes Server respond better to Remote Desktop actions.
If read buffer is full, server will process packages even if output is
not ready to receive new data. This case happens when you move a mouse
or type something on Keyboard while Server wanted to send you new screen
updates. Instead of sending you "old" updates, Server will now first
process the packages received and then send you new updates.
* Changed shutdown
- New shutdown procedure sends close messages to all threads and Quits,
without waiting for the threads to terminate.
* Changed "connection closed" notification:
- Now only Window caption will be changed to DISCONNECTED!, followed
with a short sound to annouce something happened. Desktop will jump to
normal mode if it was in full-screen mode and options will disssapear.
Library changes: dcProcess, dcChat, dcDesktop, dcFileExplorer, dcWinRemUser
Forms changed: all
-----------
18.01.2004. > update 1.9+
-----------
* Remote Desktop optimization
- changed mouse capture rate to 4 times per frame
- mouse position change sensibility changed from 10 to 2 pixels
- optimized palette capture: now uses 2x2 pixel image instead of default
block size
- set default block size to 16KB
Units changed: dcCapServer, dcDesktop
* StartClient/RestartClient functions updated
- changed this procedures to accept "wantToConnect" parameter,
so you can choose if you want to wait for the connection or just
use the object before the connection is ready. If you choose to use
the connection object before connection is open (default choice),
all data you send using the object will be cached and sent out
once the connection is available. You will also receive the close event
if connection can't be open or if it was closed from peer.
- Since this parameter is optional, old code will work as it did before,
while new code can choose if it wants to wait for the connection.
Note: you can also use "TDataCom.connected" property to wait for the
connection to be open if you use "false" (default) parameter
on this functions.
Library Changes: dcWinSockets
Form changes: RemServer_Unit, RemClient_Unit
* Updated ZLib:
- updated old ZLib version 1.0.4 to Fast ZLib 1.2.1
* New Desktop compression algorithm:
- new Desktop compression alrogithm is 100% ASM and uses 4-byte
compression instead of old 1-byte compression. This compression
method is much faster than byte-by-byte comparrison and works
extremely fast for all even color modes (16, 256, 16-bit & 32-bit).
Now, on some graphic cards, 32-bit color mode is much faster than
the old 256-color mode (depends on connection speed).
This compression method, combined with ZLib, gives best
performance and optimal image compression for most cases.
Note: If you should notice any speed degradation on slow connections because
of this new compression algorith, you can still switch to old compression
method by using "Ver3Pack" procedure instead of "Diff_MaxCompress".
But, before you do this, please test your case with old and new
Remote Office server, maybe it's only because of temporary bandwidth
problems. In all cases I tested, new compression method did equal or
better to the old one.
Library changes: dcProcess, dcWinSockets, "Zip" folder
Other changes: gCapture, dcCapServer, dcDesktop
-----------
10.01.2004. > update 1.9
-----------
* Made some changes to core lib:
- enabled New/Close connection Events (can be set to any 2 methods)
- function "StartClient" now Waits for connection to be open, returns nil
if unable to connect.
Calls "ProcessMessages" in a loop, until connection is open or closed
(doesn't block).
- fixed a BUG from last version. In last version, Server could stop
responding when
connection was closed. Not allways, but in most cases. Now everything
works just fine.
* Implemented events for all Remote Tools, so they're all useable now :)
- take a look at all Remote Tools main forms and test them executables,
then you'll see what I mean.
Changes to Library: dcProcess, dcWinSockets, dcWinRemUser, dcDesktop,
dcClientList,
dcWinFileClient, dcPickDrive, dcFileExplorer, dcChat,
dcServerCon,
dcClientReg
Changes To Forms: all forms changed
-----------
08.01.2004. > update 1.8
-----------
* Making Remote Desktop session visible to Remote user
- Now, every time someone starts a Remote Desktop session to some PC,
a Window will be displayed for the user who sits in front of that PC,
saying that a Remote Desktop session has started from IP ... and the
user will then have the possibility to close this session if it was
unwanted.
- Also, as long as a Remote Desktop session is active, a small window
displaying Eyes will be visible on the screen. This window can be freely
moved arount, but it can't be hidden nor closed as long as Remote
Desktop
session is Active. Using right mouse click on that window, User can see
from which IP the connection came. Using this small Window, user can
also
End this Remote Desktop session and close the connection.
Library units changed: dcDesktop, dcProcess, dcCapServer, dcChat, gCapture.
Form units changed: RemServer_nit, RemClient_Unit, RemAdmin_Unit,
RemRoute_Unit.
Library Units added: dcWinRemuser, dcWinRemUserAsk.
Form units added: LicenseUnit.
Also, for downloadable freeware version, Freeware License Agreement will
be displayed every time a user starts any Remote Office Tool.
From version 1.8, there is one change in the Freeware License,
which makes Remote Office binaries Freeware only for non-commercial use.
----------
07.01.2004. > update 1.7+
----------
* Mouse cursor and shape
- Optimized Server and Client side for intelligent mouse position and
shape transfer. Mouse cursor shape is now transfered only if we
positioned
the mouse to current location. Servers cursor position is now transfered
only
if mouse was moved by another user. This eliminates the "red mouse
cursor tail"
I've experienced on slow connections in version 1.7
As for my experience, I announce this update Stable.
If anyone should have any problems with it, please contact me.
----------
06.01.2004. > update 1.7
----------
* Mouse cursor position from Server
- if another user moves the mouse on Server while you view/control its
Desktop,
you will now see where the mouse is going (in remote Desktop window).
Servers Mouse cursor will be displayed as a small red arrow when it's
coordinates are atleast 20 pixels away from your current mouse location.
This way, you won't be disrupted by two mouse cursors while working,
while
at the same time you'll see if and where the mouse moves without your
control.
(dcDesktop, dcCapServer and gCapture units)
----------
05.01.2004. > update 1.6+ (3rd)
----------
* Mouse cursor update
- Mouse cursor shape did not update immediatelly,
although Client received the new shape info.
From this version, cursor shape does update immediatelly.
To do this, I had to fake mouse movement on the Client side:
-> called GetCursorPos/SetCursorPos.
(dcDesktop.pas unit)
----------
05.01.2004. > update 1.6+ (2nd)
----------
* Mouse cursor problem
- Mouse cursor shape transfer didn't work as it should, now it does again.
(dcCapServer.pas unit)
* Data Processor:
- Had to make small change to dcProcess.pas unit
(hope this was the last one).
(dcProcess.pas unit)
-----------
04.01.2004. > update 1.6+
----------
* Windows Sockets access
- Added read-only properties to TSocketDataProcessor
for reading socket-relevant information:
-> IPAddr, PeerIPAddr, PeerPort, LocalIPAddr, LocalIPAddrs.
(dcProcess.pas unit)
-----------
04.01.2004. > final update 1.6
-----------
* Data processor:
Modified Data Processor to increase stability and reduce CPU usage:
Units modified ...
- dcProcess.pas
- dcWinSockets.pas
- dcDataStream.pas
- dcDirectDataStream.pas
-----------
03.01.2004. > update 1.6
-----------
* Custom transports:
Interface for methods "ReadBytes" and "SendBytes" changed to return
"True/False" as Result.
Returning "False" as result will do the same as raising an exception.
-----------
02.01.2004. > update 1.6
-----------
* Custom Transports:
You can add custom transports (like TStreamSocket)
by inheriting from TDataStream and implementing 2 methods:
ReadBytes() and WriteBytes()
Take a look at "dcDataStream.pas" for explanation on how to do it and
"dcDirectDataStream.pas" for one example on doing it.
There is also one Delphi project "RemTest" using "dcDirectDataStream"
to show how dcDirectDataStream works.
-----------
01.01.2004. > update 1.5+ (4th)
-----------
* Remote Desktop fix:
- Delphi 4 doesn't support setting ItemIndex property of TComboBox
directly on the form,
so now I'm setting it programatically from the FormShow event.
-----------
01.01.2004. > update 1.5+ (3rd)
-----------
* Remote Desktop fix:
- Dissapearing Mouse cursor fix
-----------
31.12.2003. > update 1.5+
-----------
* Remote Desktop enhancements:
- Mouse Cursor shape from Server mirrored in Client window
(gCapture, dcCapServer & dcDesktop units)
-----------
29.12.2003. > update 1.5
-----------
* Remote Desktop enhancements:
- Clipboard copy/paste (text-only)
(dcDesktop and dcCapServer units)
- "File Explorer" and "Chat" calls
(dcDesktop, RemClient_Unit and RemAdmin_Unit units)
- Disabling the "Refresh" button while in auto-refresh mode
(dcDesktop unit)
- Turning off the "Display Auto-refresh" when opening the File Explorer
from Desktop control in Admin mode (since only one connection
available).
(dcDesktop unit)
- Bug repair: Window handle now released if connection lost in Full Screen
mode.
(dcDesktop unit)
- Buttons reorganized to save place (Dwop-Down lists instead of multiple
switch buttons)
(dcDesktop unit)
- "25" and "Max" Frames/sec rates added:
"max" sets refresh rate to 48 FPS, can be changed up to 100 FPS.
(dcDesktop & dcCapServer units)
-----------
27.12.2003. > update 1.4+b
-----------
* All configuration related access placed in one separate unit
(dcConfig.pas).
if you want to add some other configuration settings or change the place
where configurations will be read from, you won't have to make the changes
in every new update, since now all versions will access configuration
using the "Config" object which is auto-created on initialization.
-----------
22.12.2003. > update 1.4+
-----------
* Folder/File name Sorting in FileExplorer
- Changed property of MyList2.SortType and MyList.SortType to "stBoth"
- Added "Compare" event handler for MyList2 and MyList.
* Bugfix in remote Desktop
- "gDesktop.pas" unit changed to recognize palette changes better.
---------------------------
Starting from April, Acclimate Technologies took over. The fact that there
hasn't been a lot of updates to Support-Bridge, has nothing to do with my
"unreadable code", but with the fact that they got other things to worry
about also.
I'd like to see your product evolve as fast as RemoteOffice did.
Best Regards,
Danijel Tkalcec
tony
I think your code could have been optimized a bit more, I found lots of tight while loops that just needed a
sleepex(0,true) in them and the CPU use went down even without using he hooks driver.
--
Tony Caduto
AM Software Design
Home of PG Lightning Admin for Postgresql 8.x
http://www.amsoftwaredesign.com
OBones
> Never thought about using a "sleep" inside a loop to reduce the CPU. After
> all, all the loops there are in RemoteOffice code, do something that I
> thought is important to complete as fast as possible (no sleeps). Maybe I
> was wrong about that.
>
> Btw ... can you post the loop here (to this NewsGroup) inside which you
> added the "sleep"? I'm sure a lot of RemoteOffice users will find this
> information useful. Thank you! :o)
The Sleep(0) simply tells the OS that you are ready to relinquish your
time slot to any other thread that needs it.
If noone requires it, you get the slot back. This is a collaborative
behaviour which is REQUIRED by the OS in order not to use 100% CPU,
especially if what the thread does is simply waiting in a loop.
Danijel Tkalcec
all, all the loops there are in RemoteOffice code, do something that I
thought is important to complete as fast as possible (no sleeps). Maybe I
was wrong about that.
Btw ... can you post the loop here (to this NewsGroup) inside which you
added the "sleep"? I'm sure a lot of RemoteOffice users will find this
information useful. Thank you! :o)
Best Regards,
Danijel Tkalcec
Sergio
> Never thought about using a "sleep" inside a loop to reduce the CPU.
LMAO
Danijel Tkalcec
> time slot to any other thread that needs it.
I know that :o) I was just wondering which loop helped to lower the CPU,
without slowing the remote desktop part down. Since even sleep(0) takes some
time to call (even if it's a few nano-seconds), it could reduce the
execution speed if put inside the wrong loop (for example, image compression
algorithm). I guess, Tony used the sleep(0) somewhere else, that's why I
asked where.
Anyway ... if a few sleeps here-and-there don't harm the RemoteOffice
execution speed, lowering the CPU usage at the same time, I guess this
information would be interesting for a lot of RemoteOffice users.
Best Regards,
Danijel Tkalcec
Rudy Velthuis [TeamB]
> I thought we are in thirdpartytools.general.
Look at the headers. This entire thread seems to be cross-posted. I only
realized that before.
Followup set to thirdpartytools.general
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"Whatever is begun in anger ends in shame."
- Benjamin Franklin (1706-1790)
Danijel Tkalcec
>> Never thought about using a "sleep" inside a loop to reduce the CPU.
> LMAO
It may sound funny, bit it's true. I spent days optimizing the code, even
using assembly for critical parts. I know that you can make it appear as if
your app needs less CPU (is more optimized) by using sleep's a lot, but it
can also slow things down. Well, it all depends where you use the sleeps.
Anyway ... I didn't see this as code optimizarion, since your code will
still need the same time to execute (actually, a bit more). But for the
remote desktop control app, it is probably more important how much of your
CPU time is available to other apps, than how long your app needs to prepare
a new package.
Regards,
Danijel Tkalcec
Rudy Velthuis [TeamB]
> Having the knowledge needed to implement ...
Please everyone, either move this to thirdpartytools.general (set
followup, or remove non-technical from the groups), or risk to be
cancelled.
Followup set.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"My occupation now, I suppose, is jail inmate."
-- Unibomber Theodore Kaczynski, when asked in court what his current
profession was
Rudy Velthuis [TeamB]
> What ever you say.
If you can't prove it, I think you should at least apologize for making
an unfound accusation like that.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"Never interrupt your enemy when he is making a mistake."
- Napoleon Bonaparte (1769-1821)
Rudy Velthuis [TeamB]
> I'm sure there's also parts of RemoteOffice
> in the product being offered from Periklis
That sounds like a very bold accusation. You'd better be able to prove
that.
--
Rudy Velthuis [TeamB] http://velthuis.homepage.t-online.de
"Death is one of the few things that can be done as easily lying down.
The difference between sex and death is that with death you can do it
alone and no one is going to make fun of you." -- Woody Allen.