Separate the tor executable from the GUI

Then when a new version of tor comes out we can update it ourselves rather
than having to wait for a new precompiled version. That would also save you a
lot of effort having to keep up to date with the latest tor releases. This is
how vidalia does it

The reason I searched for an alternative to Vidalia bundle was due to me
getting Tor crashed messages from Vidalia.

As a result, I am not too excited about this sort of separation.

I would, however, like to see another kind of separation: Make all the non-GUI
parts a DLL.

This would free the devs from having to write all the visual bells and
whistles and lets other people do it.

I, for one, could do a much better GUI (or turn AdvOR into a Windows Service)
if a properly documented DLL was available.

This question was asked on another forum -
AdvOR is not just a GUI for Tor. Many things were added and many things were
changed (for example, change your system time to be 1 month in the past and
Tor will no longer work while AdvOR will have no problems). Read the changelog
to see what exactly was changed.

@ adem0x : you are right, the GUI sucks. If you want to do a better one, you
can edit the files tor_rc.rc and dlg*.c . Have you considered helping the
AdvOR development ?

hexhub,

To be honest, I am not much of a use when it comes to C/C++; so, I doubt if I
could directly help with AdvOR development.

What I can do, however, is to help with the GUI side of things --i.e. write
the GUI in Delphi/FreePascal (which is much more suitable for the purpose) as
a native Windows application or service.

And, in order to do this, the GUI should be stripped off from AdvOR.exe and
everything else in it needs to be turned into a DLL.

I did take a look at AdvOR.dll but it seems to be only a very small part of
the whole project.

What we would need would be something like this:

Separate the GUI from the rest of the engine, and make every single
data/command exchange between the the GUI and the engine as callbacks.

Once every thing is converted into callbacks, it becomes a trivial thing to
put a better GUI on top of it that displays all sorts of graphics as well as
user-friendly functionality etc.

I wish I could do this sort of separation of functionality (engine) and user
interface (GUI) myself, but I can't; I don't know C/C++ that well.

I can only help with GUI, if you could do the engine into a dll.

You can write a .dll yourself, as a plugin. Your plugin can hide the GUI and
create another one. For more information see Help\plugins.txt . If needed,
I'll add a function that disables/enables the default GUI.

I took a look at help\plugins.txt and, not surprisingly, it is far too plugin-
centric.

I don't think it would be worth the effort because it is likely to fail to act
as a proper GUI --it will be an after thought.

A much better way to go about it would be that you separate all of your GUI
from the engine and turn the engine into a dll.

But, apparently, you're not prepared to do that.

I understand --it takes some effort to decouple GUI from the engine.

Plugin support can be improved as needed.

Another option would be to link AdvOR objects with your object files made by
your favorite compiler - in my opinion this would be better than loading
another file at runtime (lower CPU + memory usage) and we'll still have one
big .exe that has everything in it.

I'll restructure the code in next versions to make it easier to include / load
at runtime other GUI libraries.

I might be asking you a little too much.

The reason I am saying this is, I took a very brief look at some of the
sources under the 'or' folder; and, that source seems to have all sorts of GUI
stuff (such as dialogs etc.) embedded right in there.

While it may have been good idea at the time, I think it is a wrong approach
to sprinkle GUI stuff (forms, dialogs etc.) within the engine.

And, one thing more: While I am a great believer in Object Oriented code, I
think it is not the route to go when you're writing an engine.

Don't get me wrong, it is more than OK to use OO in the engine, but when
you're making a DLL (or SO), you need to flatten it so that it can be used in
almost all other programming languages.

I am sure you know what I mean by flattening: If you want some information
from the GUI or if you want to update something or display some dialog, you do
all those through callbacks.

And, please, no exotic structs either --just simple plain basic data types,
such as chars and integers.

This way, AdvOR --as a DLL-- could be used in all sorts of applications by all
sorts of programming languages.

Plugins should be independent of this; they are --again-- to be used by the
GUI as functionality extenders.

End of my 2c.

You're confusing OOP with structured
programming. Don't
worry, I'm not going to slow it down with OOP.

Having the engine as a .dll is a wrong approach here. More applications can
use one instance of AdvOR that can load whatever plugins are needed, save
whatever files it has to save and host whatever services it has to host. To
prevent one exit node from knowing what you're doing with 2 different
applications you can enable the option to use exclusive exits. Also, I added a
new Socks5 extension (Help\Tor\socks-extensions.txt) for applications that
need to exit from a specific country / IP / IP range. No need for more
instances of AdvOR (or an AdvOR library loaded by more processes) that have to
download the network-status consensus independently.

Any GUI for AdvOR would need AdvOR to work but AdvOR doesn't need one specific
GUI. The replaceable part should be the GUI so the user can choose between
more GUI libraries.

"You're confusing OOP with structured programming."

Believe me, I am not. I just made those comments because you said "Another
option would be to link AdvOR objects with your object files made by your
favorite compiler " in a comment above. I thought you were going to
restructure AdvOR as OOP.

"Don't worry, I'm not going to slow it down with OOP."

That's good news.

"Having the engine as a .dll is a wrong approach here."

I don't agree with this. Separation of GUI and the engine is always a good
idea. Actually, you have said the same thing below.

"More applications can use one instance of AdvOR that can load whatever
plugins are needed, save whatever files it has to save and host whatever
services it has to host."

Making the engine into a dll has nothing to do with the dll being the single-
instance.

If it's really needed, it can be enforced in many ways.

And, I am not sure it's a good idea to assume that in all cases it's sensible
to arbitrarily dictate that there should be only one instance of AdvOR.

"To prevent one exit node from knowing what you're doing with 2 different
applications you can enable the option to use exclusive exits."

Yes. But, there may be developers who'd want to do it as one-AdvOR per app.

They may have perfectly valid reasons for doing this.

Why restrict this?

"Also, I added a new Socks5 extension (Help\Tor\socks-extensions.txt) for
applications that need to exit from a specific country / IP / IP range."

Socks5 is a good extension to AdvOR.

"No need for more instances of AdvOR (or an AdvOR library loaded by more
processes) that have to download the network-status consensus independently."

How much data are we talking about?

"Any GUI for AdvOR would need AdvOR to work but AdvOR doesn't need one
specific GUI."

Precisely. This is what I have been trying to tell.

But, at the moment, AdvOR is a monolithic exe with an integral GUI.

"The replaceable part should be the GUI so the user can choose between more
GUI libraries."

And, how do you "replace' a GUI that is an integral part of the engine?

I just made those comments because you said "Another option would be to link
AdvOR objects with your object files made by your favorite compiler "

By "objects" I meant "object files" (.o, .obj, .a, .lib, etc.).

"Having the engine as a .dll is a wrong approach here."

I don't agree with this. Separation of GUI and the engine is always a good
idea.

I didn't say the wrong approach is the separation between the GUI and the rest
of AdvOR.

And, I am not sure it's a good idea to assume that in all cases it's
sensible to arbitrarily dictate that there should be only one instance of
AdvOR.

There is a difference between recommending something and enforcing something.
Unlike Tor, which saves its settings to Application Data, you can have another
instance of AdvOR if you copy all its files to another directory or to the
same directory renamed (with the "AdvOR" prefix replaced with something else)
and execute the copy.

But, there may be developers who'd want to do it as one-AdvOR per app.

And they can do this if they use a private copy of AdvOR. That way, multiple
instances of the same application will be able to use the same instance of
AdvOR.

"Also, I added a new Socks5 extension (Help\Tor\socks-extensions.txt) for
applications that need to exit from a specific country / IP / IP range."

Socks5 is a good extension to AdvOR.

The extension is not the Socks5 protocol itself which was supported since
version 0.1.0.0 but an addition to the Socks5 protocol (5. Router selection
(AdvTor 0.1.0.7+)).

How much data are we talking about?

AdvOR-cached., AdvOR-unverified.

And, how do you "replace' a GUI that is an integral part of the engine?

"The replaceable part should be the GUI so the user can choose between more
GUI libraries." - notice the word "libraries".

I'm not sure yet if the GUI libraries will be statically linked or loaded at
runtime.

By "objects" I meant "object files" (.o, .obj, .a, .lib, etc.).

First, not many programming languages can use those kinds of files if they are
produced by other programming languages.

Secondly, even when they can, it only produces another monolithic binary.

There is a difference between recommending something and enforcing
something. Unlike Tor, which saves its settings to Application Data, you can
have another instance of AdvOR if you copy all its files to another directory
or to the same directory renamed (with the "AdvOR" prefix replaced with
something else) and execute the copy.

Why should the engine deal with where settings data is stored? That is the job
of the GUI.

If the settings should be stored, it should be handled by the GUI. In any
case, the engine should receive all the settings data from the GUI; the engine
shouldn't touch the disk at all.

And they can do this if they use a private copy of AdvOR. That way, multiple
instances of the same application will be able to use the same instance of
AdvOR.

Multiple applications will always use AdvOR over either sockets (or named
pipes).

In the case of dedicated AdvOR usage (for an individual app), access through
sockets (or named pipes) will be disabled and main app will communicate with
AdvOR engine through callbacks.

AdvOR-cached., AdvOR-unverified.

In my case, all these take up about 6.5 MB which is not much to worry about.

"The replaceable part should be the GUI so the user can choose between more
GUI libraries." - notice the word "libraries". I'm not sure yet if the GUI
libraries will be statically linked or loaded at runtime.

And, again, we've come to the most interesting part of this discussion: We
seem to be saying the same thing but meaning completely opposite things.

1) There's no reason to assume that the GUI will be a Windows executable, it
might as well be a HTML page generated by PHP, Phyton or whatever. In this
case, settings data could as well be stored in a database.

2) I for one would like AdvOR to be a 'Windows Service'. For this, all I need
to do is to write a simple 'Windows Service' applicaction (and a user GUI as a
CPL that resides in the Control Panel) which uses the AdvOR dll (if it were a
DLL).

3) Other prople might want to use AdvOR as a dedicated part of their app. They
would have to handle the settings stuff, but would want to AdvOR dll (if it
were a DLL).

4) Finally, someone might like to write a better GUI. In this case, it still
is better to have AdvOR as a dll module.

I am sure there can be a lot more scenarios.

Secondly, even when they can, it only produces another monolithic binary.

I have no problems with that. I even like this idea better than to have tons
of .dll's loaded and instantiated at runtime.

Why should the engine deal with where settings data is stored? That is the
job of the GUI.

No, the job of the GUI is to be a GUI. Where the files are saved is not an
option. The files are saved where the .exe is located and prefixed with the
name of the .exe (if you rename AdvOR.exe to AdvTor.exe everything used by it
should have the prefix "AdvOR" replaced with "AdvTor"). When someone wants to
copy or move AdvOR, all the files can be found in one directory having the
same prefix.

What about the read-only mode or compressing and encrypting everything as
AdvOR.dat ? Should the plugin developer have to rewrite this ? The plugin API
has functions to load/restore configuration settings from/to AdvOR.ini to
prevent plugins from writing anything to disk when the read-only mode is
enabled or when all configuration files are encrypted.

1) There's no reason to assume that the GUI will be a Windows executable, it
might as well be a HTML page generated by PHP, Phyton or whatever.

That would be worse than rewriting it in a dotCrap language. I like AdvOR as
it is now - fast with low memory usage. And I intend to optimize it to be even
faster and to consume less memory. I'll rewrite more parts from it in
assembly.

2) I for one would like AdvOR to be a 'Windows Service'.

If you want to host a router or hidden services you can use Tor - I didn't
improve those parts in AdvOR. When Tor/AdvOR is not hosting a router or hidden
services there's no point to make it a Windows service - a Windows service
doesn't have a GUI, it needs another process to control it and one process is
enough.

3) Other prople might want to use AdvOR as a dedicated part of their app.

This would be a problem if AdvOR was a library. As a library it would restrict
the application to be single-instance. And it would load and instantiate all
plugins, load AdvOR.dll and the network-status in each instance of that
application. If AdvOR is a separate .exe, another application has ways to
request anything it needs from AdvOR and still have its requests isolated from
other applications. Don't assume everyone who would like to use AdvOR in
his/her application wants to care about how AdvOR works and all the things it
can do that are irrelevant to that particular application. In most cases
changing the exit node is enough, and this can be done even on the proxy port
before sending the connection request.

4) Finally, someone might like to write a better GUI. In this case, it still
is better to have AdvOR as a dll module.

It's better to have the GUI as a library. You can make another GUI as a plugin
if you want. When separated, the GUI, like any other plugin cannot work
without AdvOR but AdvOR can work fine without that plugin => the application
is AdvOR not the plugin. The user who doesn't like your GUI can delete it /
replace it / disable it.

I have no problems with that. I even like this idea better than to have tons
of .dll's loaded and instantiated at runtime.

In that case, we wouldn't be talking about tons of DLLs but just one.

Plus, if you're really against DLLs, then why would you advicate the use of
plugins which are nothing but DLLs?

Because you aren't.

Anyway, as we all know, DLL count isn't an issue anymore; on the contrary,
there are some advantages of DLLs too: You can dynamically load and unload
them to preserve memory if necessary.

No, the job of the GUI is to be a GUI.

This is the bit we don't seem to resonate.

OK.

A GUI is a GUI.

Fine.

But, then there's the question of who handles the storage of settings.

If you integrate it with the engine, then you're reducing the flexibility for
no understandable reason.

Where the files are saved is not an option.

But, it should be.

The files are saved where the .exe is located and prefixed with the name of
the .exe (if you rename AdvOR.exe to AdvTor.exe everything used by it should
have the prefix "AdvOR" replaced with "AdvTor").

Storing data in the same folder as the exe is something you are no more
allowed to under Windows 7.

In fact, ATM, AdvOR stores it data in
"C:\Users{USERNAME}\AppData\Local\VirtualStore\Program Files
(x86)\Internet\AdvOR" even though AdvOR itself is installed under "C:\Program
Files (x86)\Internet\AdvOR".

When someone wants to copy or move AdvOR, all the files can be found in one
directory having the same prefix.

Then there's a security consideration: What if I don't want anything stored on
disk?

If you agreed to separete this functionality from the engine, then someone
could write a module that does this all in memory (so that it leaves no trace
on disk).

What about the read-only mode or compressing and encrypting everything as
AdvOR.dat ? Should the plugin developer have to rewrite this?

Sure. How hard could it be to (un)encrypt some data and read/write it to/from
disk/memory?

The plugin API has functions to load/restore configuration settings from/to
AdvOR.ini to prevent plugins from writing anything to disk when the read-only
mode is enabled or when all configuration files are encrypted.

I have no problem with this at all. Any plugin that works under AdvOR is
welcome to get/set settings through AdvOR.

All I am saying is this: AdvOR itself should delegate that functianlity to
another module.

That would be worse than rewriting it in a dotCrap language. I like AdvOR as
it is now - fast with low memory usage. And I intend to optimize it to be even
faster and to consume less memory. I'll rewrite more parts from it in
assembly.

I wasn't suggesting that you write AdvOR in PHP or Python (I would hate it
too), but there's absolutely no reason why the GUI cannot be written in PHP or
Python or whatever. You don't need speed for GUI.

If you want to host a router or hidden services you can use Tor - I didn't
improve those parts in AdvOR.

Frankly, IMO, Tor is hopeless. I look onto Tor as an application they made so
that they could have something for a proof-of-concept.

Then they slapped on it something called Vidalia. Since both Tor and Vidalia
are monolithic exes, they have to communicate in the clumsiest possible way.

They should have made Tor a DLL that only handles the OR protocol AND then
Vidalia could have handled the GUI and the settings side of things.

When Tor/AdvOR is not hosting a router or hidden services there's no point
to make it a Windows service - a Windows service doesn't have a GUI, it needs
another process to control it and one process is enough.

That's what I said too. If AdvOR was a DLL, I could write a Windows Service
exe that uses AdvOR.DLL. Then, I would either write a simple independent GUI
(which could be a Control Panel applet) that handles starting/stopping the
service as well as the settings data.

BTW, there's a good reason why you might want to write a Windows Service:
Imagine there are a number of users in a group. Instead of installing AdvOR on
each users machine, you can simply set the proxy client (say, FoxProxy) point
to the machine AdvOR is running as a Windows Service.

I can think of quite a few reasons why this would be ideal.

3) Other prople might want to use AdvOR as a dedicated part of their app.

This would be a problem if AdvOR was a library. As a library it would
restrict the application to be single-instance. And it would load and
instantiate all plugins, load AdvOR.dll and the network-status in each
instance of that application.

So?

Anyone doing that would also be aware of any possible drawbacks; but I think
there will be more cases this will be an advantage than otherwise.

If AdvOR is a separate .exe, another application has ways to request
anything it needs from AdvOR and still have its requests isolated from other
applications.

Why?

If you make it optional so that socket (or named pipe) communication from
internal client are disabled, this is no more a potential problem. In this
case, the app that uses AdvOR as DLL communicates wit it through callbacks
--not sockets.

Don't assume everyone who would like to use AdvOR in his/her application
wants to care about how AdvOR works and all the things it can do that are
irrelevant to that particular application.

If the interface is documented, they wouldn't have to know about the internals
anymore than we need to know about TCP/IP internals. For example, we are not
worried about the Nagle algorithm or other nitty gritties in the TCP/IP libs.
For us, TCP/IP libs is a blackbox.

I am simply suggesting that you make AdvOR a similar thing: A library that
people can use as a blackbox.

It's better to have the GUI as a library.

Actually, I find this notion obsurd: A GUI is, by definition, something that
greets the user and displays status, receives users commands etc. So, to think
of GUI as a library (something buried into the system) doesn't make much sense
to me.

You can make another GUI as a plugin if you want.

Sure. And, to do that, the engine must be modular.

When separated, the GUI, like any other plugin cannot work without AdvOR but
AdvOR can work fine without that plugin => the application is AdvOR not the
plugin. The user who doesn't like your GUI can delete it / replace it /
disable it.

I disagree.

The OR protocol (or its implementation) belongs to the same category of
communication libraries.

If only you could accept to position it that way, AdvOR would find a lot more
uses than what it does know.

I have no problems with that. I even like this idea better than to have
tons of .dll's loaded and instantiated at runtime.

In that case, we wouldn't be talking about tons of DLLs but just one.

Plus, if you're really against DLLs, then why would you advicate the use of
plugins which are nothing but DLLs?

The program is optimized to have a fast startup from slow devices. Plugins are
optional and can be disabled and/or deleted when needed. Even if I add some
GUI libraries to the default AdvOR archive I'm not removing the default GUI
from AdvOR.exe . All you need to start AdvOR is AdvOR.exe, all other files are
optional.

Plus, if you're really against DLLs

You're lucky I read the rest of your post after this remark.

Where the files are saved is not an option.

But, it should be.

The main reason all files are in the same place is to make it portable.

Then there's a security consideration: What if I don't want anything stored
on disk?

How about you read the help file for start ? Or read what I already posted
here on this topic. I remember saying AdvOR already supports a read-only mode
where no files are written.

How hard could it be to (un)encrypt some data and read/write it to/from
disk/memory?

The feature is already implemented and it will not be removed. When using
available API, plugin developers don't have to care if encryption is enabled.

All I am saying is this: AdvOR itself should delegate that functianlity to
another module.

Whatever extra functionality will be needed for file management will be built-
in. It will be faster this way.

You don't need speed for GUI.

I am one of those who delete applications that have a slow GUI when faster
alternatives are available. And we already have a fast alternative.

In this case, the app that uses AdvOR as DLL communicates wit it through
callbacks --not sockets.

An application can use a plugin if it really needs callbacks instead of using
the proxy port / control port.

I am simply suggesting that you make AdvOR a similar thing: A library that
people can use as a blackbox.

AdvOR can be used as it is just fine. Having it as a separate .exe that gives
all the options it has to the user is better - the developer doesn't have to
add to his application all the settings someone may want to change in AdvOR
like bridges, proxies, AS path restrictions, etc.

So, to think of GUI as a library (something buried into the system) doesn't
make much sense to me.

The "buried into the system" part doesn't make sense to me either. What's
wrong with keeping all the plugins inside the AdvOR-plugins\ directory ?

You can make another GUI as a plugin if you want.

Sure. And, to do that, the engine must be modular.

Read plugins.txt .

The OR protocol (or its implementation) belongs to the same category of
communication libraries.

The OR client/server functionality is only a part of what AdvOR does. Read the
help file.

AdvOR would find a lot more uses than what it does know.

Until you read the help file you probably won't know the uses it already has.
A program doesn't need special support for AdvOR. It doesn't even need to
support proxies because AdvOR can intercept it and redirect its connections.
That's what AdvOR.dll is for - to be injected into other processes, not a
common library of functions I didn't want to put into the .exe .

Waking an old thread, but I must agree with both of you. Been looking for a
Tor/I2P/Freenet library for a long time. I think the correct approach here
would be a bit honesty. I am a lazy and quite terrible coder, but if the
communications part would be in a separate library (static or dynamic or even
both, as long as it's not some strange msvc++ thingy that agrees with nothing)
I could use it for whatever suits my need without having to reinvent the
wheel.

I just want a simple solution with minimal dependencies/runtimes and that is
completely standalone for me to include in my software and make me and a bunch
of other selected people able to talk whenever, wherever, completely
anonymously using one single executable and an extremely minimalistic console
interface while having the "central server" at home, without anyone of us
involved being able to know who's controlling the server or who's on the other
end of the discussion. Easy as that.

if the communications part would be in a separate library

.

See Help\plugins.txt . If you don't want to write a plugin for AdvOR you
can still use the control port (Help\Tor\control-spec.txt).