Converting a mini C# program to a standalone (C++) binary

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Ted Lyngmo - 28 Sep 2007 17:15 GMT

Hi!

I'm new (but please do continue reading) to C++ in the VS environment
and wanted to create a standalone program (or preferably, a static
library, compatible with other Windows compilers) that;

1. Takes an URI as an argument.
2. Prints the proxy for that URI to stdout (or in the static
library case, returns the resulting string).

Needless to say, I was unsuccessful, but I managed to create the below
in C#, which works just like I want to.

Now, how would I go about to convert this into a standalone binary? I
don't even know what kind of project I should create or how to make use
of the .net framework standalone program. Maybe it's not possible? Well,
any pointers in the right direction would be helpful.

Best regards,
Ted Lyngmo
VS 2005
~~~~~~~~~~~~~~~~~~
using System;
using System.Net;
public class Test
{
public static void Main(string[] args)
{
IWebProxy iwp20 = WebRequest.DefaultWebProxy;
if (args.Length>0)
{
string retval;
try
{
retval = iwp20.GetProxy(new Uri(args[0])).ToString();
Console.WriteLine(retval);
}
catch
{
Console.WriteLine(args[0]);
}
}
}
}

Reply to this Message

Ted Lyngmo - 29 Sep 2007 05:35 GMT

Hi

I'm trying to use the functions in WINHTTP.DLL in my VS 2005 Standard
Edition C++ project on an XP SP2 box to build a standalone binary (exe,
dll or lib) that;

1. Takes an URI as an argument.
2. Returns the proxy for that URI.

I've been looking at these functions:

WinHttpOpen
WinHttpGetDefaultProxyConfiguration
WinHttpGetProxyForUrl
WinHttpGetIEProxyConfigForCurrentUser

...but my first problem is Winhttp.h. I can't find it. I've searched
from C:\ for it.

Both WINHTTP.DLL and WINHTTP.LIB are present though.

Is there anything wrong with my development environment or what?

Best regards,
Ted Lyngmo

Reply to this Message

Ted Lyngmo - 29 Sep 2007 06:09 GMT

> ...but my first problem is Winhttp.h. I can't find it. I've searched
> from C:\ for it.

Do I need to install "Microsoft ® Windows Server® 2003 R2 Platform SDK"
to get Winhttp.h?

Best regards,
Ted Lyngmo

Reply to this Message

Ben Voigt [C++ MVP] - 01 Oct 2007 16:33 GMT

> > ...but my first problem is Winhttp.h. I can't find it. I've searched
> > from C:\ for it.
>
> Do I need to install "Microsoft ® Windows Server® 2003 R2 Platform SDK" to
> get Winhttp.h?

That's definitely worth a try.

Worst case, you could cut+paste the declarations yourself, I'd wouldn't
prefer that, but for only four functions it isn't so bad.

> Best regards,
> Ted Lyngmo

Reply to this Message

Ted Lyngmo - 01 Oct 2007 22:58 GMT

Howdy Ben!

Thnaks for the reply!

> > >...but my first problem is Winhttp.h. I can't find it. I've
> > > searched from C:\ for it.
[quoted text clipped - 3 lines]
>
> That's definitely worth a try.

Yeah, I installed it and found out that it contained all I needed and I
was able to make a test program that did what I needed. Unfortunately, I
wasn't able to convert the VC++ lib to a lib that could be used by the
(very old) Borland environment used in the rest of the project. The lib
conversion tool couldn't handle it...

> Worst case, you could cut+paste the declarations yourself, I'd
> wouldn't prefer that, but for only four functions it isn't so bad.

Well, I did a little bit of this and that:
After having gotten familiar with the WinHttp* functions in VC++, I
found someone who'd made a "bccSDK" (Borland specific SDK) out of
winhttp.lib and all the rest. Unfortunately the include files he'd made
wasn't useful in the old BCB environment but when I had almost ported
the original files myself, I found someone who'd made most of that too.
I just had to add one #define. :-)

I've now made a first beta version of a AutoProxy lib (and class) for
BCB4 and so far it seems to be working like a charm.

Things still in the works:
* WinHttpGetProxyForUrl() can't handle anything else but http(s) calls.
Why? Is there a more "universal" GetProxyForUrl() somewhere?

* WinHttpGetProxyForUrl.lpszAutoConfigUrl can't handle pac files given
as a UNC path. Any special reason for that? IE handles that just fine.
My (temporary) solution is to set up an http server and to give that
server as "lpszAutoConfigUrl" instead. When I get a connection request,
I just feed the caller the file found at the UNC path. Is that how IE
does it too or is it a smarter, less resource consuming, way?

* Precedence: Although I think I've figured out in which order IE uses
the settings, it'd be nice with a facit.

* Testing WinHttpGetProxyForUrl() without feeding it a
lpszAutoConfigUrl: Two days ago I didn't know that there was a "WPAD
protocol" and I haven't figured out what I need to do to set my LAN up
like it would be in a real corporate network.

* What happens if programs using WinHttp* are executed in W98 etc.? If
the calls to those functions just returns with an error I'd be happy,
but if the programs crashes, I would not :-)

Best regards,
Ted Lyngmo

Reply to this Message

Ben Voigt [C++ MVP] - 02 Oct 2007 21:49 GMT

> * What happens if programs using WinHttp* are executed in W98 etc.? If the
> calls to those functions just returns with an error I'd be happy, but if
> the programs crashes, I would not :-)

You would need to use LoadLibrary and GetProcAddress to test for the
presence of those functions, instead of using the import library.
GetProcAddress will return NULL if the function does not exist.

> Best regards,
> Ted Lyngmo

Reply to this Message

Converting a mini C# program to a standalone (C++) binary

Free Magazines