* The Business of Software

A community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.

This community works best when people use their real names. Please register for a free account.

Links:

» Business of Software FAQ
» The Business of Software Conference (held every fall, usually in Boston)
» Forum guidelines (Please read before posting!)

Movie:

"Make Better Software" is a 6 movie course designed to help you as you grow from a micro-ISV to a large software company.
Part 1: Recruiting
Part 2: Team Members
Part 3: Environment
Part 4: Schedules
Part 5: Lifecycle
Part 6: Design

Moderators:

Andy Brice
Successful Software

Doug Nebeker ("Doug")

Jonathan Matthews
Creator of DeepTrawl, CloudTrawl, and LeapDoc

Nicholas Hebb
BreezeTree Software

Bob Walsh
host, Startup Success Podcast author of The Web Startup Success Guide and Micro-ISV: From Vision To Reality

Patrick McKenzie
Bingo Card Creator

Writing web applications using C++ Web Toolkit

Here's a portable C++ library that provides an interface for building a web application: http://www.webtoolkit.eu/wt/

SourceForge Development Status : 5 - Production/Stable

The article from Dr.Dobb's Portal (February 11, 2008): http://www.ddj.com/cpp/206401952?pgno=1

Wt is a freely available library and application server that lets C++ programmers write modern web applications using a familiar C++ GUI programming style. Wt then renders the C++ applications to the web browser. Figure 1, for instance, is a running Wt application—a functional look-alike of the GMail composer, fully AJAX enabled, and written entirely in C++ using CSS for the markup.

From a programmer's perspective, the Wt API is similar to those offered by libraries such as Qt, Gtk, wxWindows, and the like. However, instead of rendering widgets to Windows/X11/ windows, Wt incrementally renders the widgets in web browsers. Wt completely hides the underlying web technologies (HTML, AJAX, XML, FastCGI, JavaScript, and DHTML), chooses a rendering and session-management strategy depending on browser capabilities, and deals with browser dialects.

Being a native C++ library, web applications developed with Wt typically enjoy greater efficiency and a smaller footprint than Java or Ruby solutions.
C++ Supporter
Friday, February 29, 2008
 
 
"...completely hides the underlying web technologies..."

In my experience, that sort of thing *always* ends up being a mistake. There are two reasons. First of all, frameworks that do that usually end up trying to abstract away things like HTTP round-trips and whether data is being passed through the client. That's a VERY BAD THING from a security standpoint.

Second, there will inevitably be problems in areas like accessibility and browser compatibility that can only be solved by dealing with HTML, CSS, and Javascript directly. If you don't know how to work with them or your framework doesn't let you, you're screwed.

Telling a desktop GUI programmer that they can be a web developer without worrying about web technologies is like telling a steelworker that they can become a carpenter without learning anything about wood.
clcr
Friday, February 29, 2008
 
 
1) Security: By exposing only a widget-level API, the Wt library can guarantee protection against the most common cross-site scripting (XSS) attacks, by built-in and automatic filtering of displayed strings for malicious tags.

2) Browser Compatibility: While Wt's rendering engine preferably uses AJAX for incremental rendering of updates made to the widget tree, Wt applications also work when AJAX or JavaScript are not available (or disabled).

Browser-side events such as button clicks, mouse movements, and drag-and-drop events are transparently converted into server-side events using Wt's signal/slot mechanism. Wt comes with a dynamic C++-to-JavaScript translation mechanism to avoid the high-latency server roundtrip for simple visual updates, while sticking to a single C++ specification of the event-handling code.

Communication over the HTTP protocol with a web browser is abstracted in Wt using a Connector implementation. Two Connector implementations are available in Wt 2.x. One connector uses the FastCGI protocol, which lets Wt applications run in conjunction with many web servers via FastCGI plug-ins. A second connector contains a lightweight, built-in web server, so that Wt applications can be developed and deployed without need for a third-party web server.

http://fastcgi.com/devkit/doc/fastcgi-whitepaper/fastcgi.htm
C++ Supporter
Friday, February 29, 2008
 
 
That's good to hear. I'm still waiting for a toolkit written in pure C.
Victor Noagbodji Send private email
Friday, February 29, 2008
 
 
C++ Supporter, are you part of the development team?
Victor Noagbodji Send private email
Friday, February 29, 2008
 
 
Re security: Is it obvious to developers when they're passing information through the client and when they're not? In my experience, confusion about that is fertile ground for serious security holes. That's especially true for developers who are new to the web, which is who your framework seems to be targeted at.

Re browser compatibility: What do I do if the HTML/CSS/JavaScript produced by your framework proves to be incompatible with some new browser version that I have to support?
clcr
Friday, February 29, 2008
 
 
Aren't you supporting pretty URLs?
Victor Noagbodji Send private email
Friday, February 29, 2008
 
 
The arguments brought forth here are besides the point I think, I'm pretty sure the html / javascript etc generated is configurable. About the first comment with the steelworker and the wood, nobody's saying that you don't need to know anything (the whole 'leaky abstraction' form one of Joel's articles applies here).

That being said, why would you want to write it in C++? You'd have to go through the whole edit/compile/run cycle every time you make a change, one of the big advantages of simple scripting languages like php, python etc. is that the development is a lot faster because you can immediately see any changes. Unless there's a big advantage to this framework that is not in one of the million other frameworks, I don't see why you'd use c++.

And is the only reason is speed, php is so much like C++ that you'd be writing applications in a few days, and you'd make that time back very fast in the time you save by not having to worry about memory management, compiling, solving linker problems when adding a new library etc.
joske vermeulen
Friday, February 29, 2008
 
 
>I'm still waiting for a toolkit written in pure C.

C++ is C with Classes (just more convenient C). For example, Cfront was the original compiler for C++ developed by Bjarne Stroustrup from around 1983, which converted C++ to C. The first C++ compiler was a preprocessor for a C compiler.

C++ methods when translated to C end up with an additional parameter. This might appear to be a big performance overhead. In reality however, the code in C will also have to access the common data structure via an array index or some other mechanism.

Whenever an object is constructed, C++ will invoke the constructor. The constructor is actually replacing a routine that would have been used to initialize the data structures in a conventional C program.

In general this turns out to be an advantage for programs written in C++. With C++ code and data locality of reference is much better than C, as all the class code manipulating object data is located together. Also all object data is located at one place. In C code and data are scattered all over the place. Thus a C++ program should offer a better locality of reference than a C program.

If you want to create C++ programs while preserving C efficiency, then just don't use multiple inheritance and virtual base classes.

> C++ Supporter, are you part of the development team?

Nope. Just enthusiastic supporter of C++, abstract C++ programming using wrappers around cross-platform libraries.

Here you can find the project team: http://sourceforge.net/projects/witty/
C++ Supporter
Friday, February 29, 2008
 
 
> why would you want to write it in C++? You'd have to go through the whole edit/compile/run cycle every time you make a change, one of the big advantages of simple scripting languages like php, python etc.

Well, in reality, PHP gives more illusion than advantage. PHP was written as a set of Common Gateway Interface (CGI) binaries in the C programming language. PHP allows developers to write extensions in C to add functionality to the PHP language. These can then be compiled into PHP or loaded dynamically at runtime. You can use these libraries from C++ in the same way.

C++ is THE best programming language, because it gives freedom. With C++ you can write code for the abstract platform using class wrappers as abstract interfaces. It means, that software will run not only on Windows, Mac or any Unix. It will run even on the Operating System that doesn't exist yet! For example, Google OS, or something else. And such abstract source code (based on wrappers) can be easily used in other projects. Wrappers are only 5% of code -- they define only interfaces (simple intermediate classes with methods). And these classes can be easily re-written for specific environment (such as MFC or QT or wxWidgets or .NET or Wt/FastCGI etc.).

It is obvious that C++ has a huge advantage over such toys like C#, VB, PHP, Ruby. C++ ALLOWS TO RUN CODE ON ANY PLATFORM, ON ANY ENVIRONMENT, EVEN MORE: ON ABSTRACT ENVIRONMENT. It means that by using C++ you will save a lot of time, because you don't need to learn new useless programming "technologies" every year, you don't need to fix bugs because some company updated framework, you don't need to re-write code. With C++ you will write your code only ONCE, and then can use it infinitely, because it is abstract. No matter what changes with some company or some framework. Abstract C++ code gives you 100% guarantee that it will work forever and everywhere.

By using C++ with abstract class wrappers you will know what is the real Rapid Application Development. Such approach gives possibility to reuse code in many other projects. With the abstract wrappers source code almost magically becomes AMAZINGLY CLEAN -- easy to understand and to support.
C++ Supporter
Friday, February 29, 2008
 
 
Well I already regret being suckered into replying to a troll...
joske vermeulen
Friday, February 29, 2008
 
 
History of one modern "technology" called Visual Basic.

Visual Basic 1.0 for Windows was first released on May 20, 1991. Microsoft surveys in the late 1990s showed that nearly two thirds of all business application programming on Windows PCs was done in Visual Basic.

Microsoft released version 1.0 of Visual Basic .NET and the .NET framework in January 2002.

Unfortunately for VB6 developers, there was no easy way to migrate their "legacy" VB6 code to VB.NET. Even though a few automated tools emerged to aid the conversion, due to the subtleties and intricacies of the languages, a significant amount of manual, error-prone labor was required.  For larger projects, one would be better off re-writing the application from scratch, than performing a mechanical port of VB6 code to VB.NET.

Many programmers devoted 11-15 years to Visual Basic. They developed a lot of software. Many of them used it as a primary language. And now their source code became "obsolete". Programmers really lost a lot of time. It is like they did nothing during these years!

Starting over from scratch means evaluating all options on the table.

So what is more stable ? 

1) To go again with Microsoft, and to start to learn C#, then D, then maybe E, then F#, then (who knows?) Iron G, then H, I, J#... etc.
How it can be called "technology" at all? This is just ridiculous.

2) Another way: to go with abstract C++ approach and TO FORGET ABOUT ALL THIS HYPE and all this nervous "technology" race. Write source code only ONCE, use it many times during the next >30 years or more. Fantastic perspective, isn't it? Real technology: portable C++ source code based on abstract class wrappers. Today it is possible to say that C++ became a programmer's saviour. Programmer's paradise on the earth.
C++ Supporter
Friday, February 29, 2008
 
 
C++ Supporter, did you by any chance just finish your C++ course in college?

Been there, done that, recognize the symptoms.

IMHO, before you try to evangelize a language in a place like this you should get enough experience with it to name a half-dozen things you dislike about it and a few problems for which it's not the right solution. Otherwise you're just opening yourself up to ridicule.
clcr
Friday, February 29, 2008
 
 
>php is so much like C++ that you'd be writing applications in a few days, and you'd make that time back very fast in the time you save by not having to worry about memory management, compiling, solving linker problems when adding a new library etc.

1) Memory management.

Abstract memory wrapper around common memory functions in the external header file:

void* Allocate(size_t Size);
void* Reallocate(void* Memory, size_t NewSize);
void  Free(void* Memory);
void* Copy(void *DestinationBuffer, const void *SourceBuffer, size_t AmountOfBytes);

Defined as malloc, realloc, free and memcpy by default.

In most cases, memory management isn't necessary. It only slows down code execution. However, if you can't find a memory leak in your code and you don't have a time for C++ code review, then just get Boehms garbage collector: http://www.hpl.hp.com/personal/Hans_Boehm/gc/  -- quickly place GC_MALLOC GC_REALLOC in your memory wrapper, and the problem is solved.

2) Compiling. C++ program consists of a number of modules (.cpp files) that are compiled separately.
Compiled separately, and then linked together before the program is run. You can place the definition for a class (and its associated function definitions) in files that are separate from the programs that use the class. That way, you can build up a library of classes so that many programs can use the same class.

So, if you change several .cpp modules, then only these modules will be recompiled. The time for such compilation is minimal (almost unnoticeable on modern 3Ghz PCs).

3) Linking. All linker questions can be solved easily. And only once and forever. In other words, it takes a lot smaller amount of time than to learn changes in new modern "technologies" every year.
C++ Supporter
Friday, February 29, 2008
 
 
C is not C++ for me, and C++ is not C.

C++ is a new language, your author has said it long before, this is the error people make when they first learn C++ and still write things with pointers all over the place.

But let's come to serious matter: you don't support pretty URLs. That's bad for SEO, bad for businesses, bad for your toolkit.
Victor Noagbodji Send private email
Friday, February 29, 2008
 
 
to joske vermeulen:

Use good words and your perceived reality will improve accordingly.
C++ Supporter
Friday, February 29, 2008
 
 
to Victor Noagbodji:

The toolkit is written and maintained by Koen Deforche (koen.deforche at gmail.com)
C++ Supporter
Friday, February 29, 2008
 
 
Thank to all participants of the discussion.
C++ Supporter
Friday, February 29, 2008
 
 
> "...completely hides the underlying web technologies..."

assuming we hide=abstracts, then _eventually_ that approach is the right one.  _Eventually_ you will be able to write 99% of apps without worrying about where the processing takes place.  _Eventually_ round-trips and security won't be a concern, because the hardware speed (round trips) and the foundation in the browser (public key encryption) will handle this.

BUT, we're no where near that point yet. IMHO of course.

It's like if you go back 25 years and look at personal computer graphics. The best graphics at the time were done on say computers like the Commodore 64 or the Atari 8 bit series. They had mixed character and graphics modes, color attributes per character cell when doing bitmap graphics, user defined characters, hardware support for sprites, scrolling and change graphics mode part way down the screen using interrupts. And, as a programmer, you needed to be aware of all this stuff to produce nice graphics. The "simple" approach of a bitmap with a fixed number of bits per pixel on the other hand gave you CGA and other similar ugliness.  The simple approach was the right approach in the long run - all modern computers use it - but the complex approach was what was needed at the time to produce results.


(BTW I'm not saying this toolkit or C++ will be the eventual solution).
Sunil Tanna
Friday, February 29, 2008
 
 
joske, he obviously means speed of execution, not speed of writing the app.

I find this solution intriguing -- I'll try to find some time to look into it...
Ben Bryant Send private email
Friday, February 29, 2008
 
 
Why use C++?
Use script or managed code would be safer for you
kevin Send private email
Friday, February 29, 2008
 
 
>Why use C++?

To protect your work against technology traps in the long-term perspective.

Here's an explanation: http://discuss.joelonsoftware.com/default.asp?biz.5.599732.8

P.S. Also read about history of Visual Basic above, about "obsolete" ASP/VB6 programmers.
C++ Supporter
Saturday, March 01, 2008
 
 
If you dont know XHTML, CSS and JavaScript, those types of "tools" are not going to help you turn your c++ into web products. Two completely separate worlds my friend. When things break on the web, you will be in trouble!
anon
Saturday, March 01, 2008
 
 
to anon:

Knowledge of FastCGI, HTML and JavaScript is required to create the library (framework).
Abstract C++ class wrapper represents a direct link between these two separate "worlds".
C++ Supporter
Saturday, March 01, 2008
 
 
Yes of course, if you are serious web developer and you want to use C++ for this purpose, then it is strongly recommended to know FastCGI, HTML and JS.

By the way, FastCGI is a language independent, scalable, open extension to CGI that provides high performance without the limitations of server specific APIs. http://www.fastcgi.com/
C++ Supporter
Saturday, March 01, 2008
 
 
Hehehe.

C++ Supporter, you should try being an evangelist. You're good at it ;)
Victor Noagbodji Send private email
Saturday, March 01, 2008
 
 
I am also a C++ supporter, albeit a more discrete one.

For me, C++ is still the best bet for a safer near-future,  against all those hyped languages/libraries out there.

Still to be fair, C++ requires a lot of work and attention, compared to other modern languages.

One good reason I see to use the toolkit mentioned here is when you have a legacy C++ application you want to port to the web.

And we have to give credit to the OP for choosing an honest nick: "C++ Supporter". No doubt about it. He's telling the truth!!!
Rui Curado Send private email
Monday, March 03, 2008
 
 
As someone who has written an ecommerce and a classifieds website in C++ (now over 10 years ago) and now develops exclusively in C#, all I can say to our C++ poster, is good luck :-)

Sure your code might run a millisecond faster, but the extra hours/days of pain and suffering to get the code to run on the O/S, to get your widgets to line up, waiting for compilations to finish, finding obscure memory leaks and pointer corruptions is just not worth it.

Sure C++ has it's place (trash can :-), but not to take advantage of the last decade of improvements in development tools is just idiotic.

Plus, I haven't yet encountered a C++ application that can be compiled on more than one O/S without being littered with #defines and various other flags to take into account different threading libraries, etc...
Frank Send private email
Monday, March 03, 2008
 
 
Frank, it sounds like it's a good thing you have moved to a virtual machine language like C#.  Well-written C++ is really good for cross platform apps, especially in the web realm.  C likewise performs very well in that realm.  That's to be expected, these languages were designed specifically to be cross platform.

Victor, if you're looking for a good C framework, albeit much more lightweight, check out http://www.boutell.com/cgic and http://www.lazarusid.com/libtemplate.shtml

By way of clarification though, I wrote the last library.  So I'm biased.  But it does make a good tool set.  They keep you pretty close to the underlying protocols so you don't get trapped in abstractions.

C and C++ are fast languages to develop in, if you have the right skill set, and they give you advantages beyond speed.  Because you aren't running in a virtual machine, your application isn't subject to configuration changes in that virtual machine.  PHP has suffered through several app-breaking changes over the years, and has multiple configuration settings that are good at breaking working apps.  Even venerable perl is subject to have its binary moved around (/usr/bin and /usr/local/bin are both common).  A C or C++ app removes a large number of external dependencies.
Clay Dowling Send private email
Monday, March 03, 2008
 
 
Well I looked at your toolkit and although I was hopeful, I didn't see anything that I liked. I think I would be more inclined to the C++ options Clay Dowling listed, knowing him on this group for a long time.

After only browsing, some of my disappointments in the toolkit recommended by the OP:

- Too many classes. C++ is by far my favorite language, but there is a danger in C++ which is over use of classes. Some developers think everything needs to be a class in object oriented coding, but it makes the code too difficult to read and understand what is going on.

- Ajax to DHTML ratio might be problematic. Controls seemed slow and I think it was actually grabbing stuff from the server on each click (i.e. making essentially synchronous calls rather than smart asynchronous calls ahead of time). One of the things about Ajax or javascript component systems is the balance between what is done on the browser side and what is supported by asynchronous calls. An asynchronous call is nevertheless a round-trip, and the goal is to minimize the round trips that you *wait* for. When you open a node in a tree, hopefully that data is already on the client side. This is what a mature component library will likely implement better than a new one such as grabbing a reasonable portion of the tree to support all of the visible clicks.

- Site is a work in progress. Not a criticism so much as an observation that the site is rough, adding to the sense of risk about using this toolkit.

But, I like to see C++ initiatives for web development. Best wishes.
Ben Bryant Send private email
Monday, March 03, 2008
 
 
Oh, Clay's were C frameworks... still I am inclined to try those over the one proposed by the OP.
Ben Bryant Send private email
Monday, March 03, 2008
 
 
Bryan:

Thank you for evaluating our toolkit, and sorry to hear that you didn'like anything of it.

As to your specific remarks.
> - Too many classes. C++ is by far my favorite
> language, but there is a danger in C++ which is
> over use of classes. Some developers think
> everything needs to be a class in object oriented
> coding, but it makes the code too difficult to read
> and understand what is going on.

I totally agree with hating over use of classes, and why you would get that impression about Wt (if you go to the class list in the reference documentation). However, I would be interested to hear what is your opinion on TrollTech's Qt widget library, which is renowned for its elegant API? Almost all of the classes in Wt have their counterparth in Qt. But, you are right, Qt does get fair criticism since it adds some keywords to make their signal/slot system work (with a meta-compiler). Guess what, Wt doesn't need that anymore...

> - Ajax to DHTML ratio might be problematic. Controls
> seemed slow and I think it was actually grabbing stuff
> from the server on each click (i.e. making essentially
> synchronous calls rather than smart asynchronous calls
> ahead of time). One of the things about Ajax or
> javascript component systems is the balance between what
> is done on the browser side and what is supported by
> asynchronous calls. An asynchronous call is nevertheless
> a round-trip, and the goal is to minimize the round trips
> that you *wait* for. When you open a node in a tree,
> hopefully that data is already on the client side. This
> is what a mature component library will likely implement
> better than a new one such as grabbing a reasonable
> portion of the tree to support all of the visible clicks.

Good to see you are very much aware of AJAX techniques. Wt only uses asynchronous calls, and loads as much ahead as you want it to do. For example, in the homepage it preloads the main menu, but not the examples menu. It also preloads all trees. Again, this is something you may chose or not, and we chose not to (because we don't want to slam the server).

For the WMenu class, Wt allows you to chose, per menu item, how loading of the contents should be handled (LazyLoading or PreLoading), see http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WMenu.html.

For the WTreeNode class, Wt offers three modes: LazyLoading, PreLoading, and NextLevelLoading. The latter preloads only the next invisible level, something I would call "smart", and that I haven't seen in any other AJAX toolkit? See http://www.webtoolkit.eu/wt/doc/reference/html/classWt_1_1WTreeNode.html.

Oh, and you cannot tell from the documentation, but WMenu and WTreeNode are actually implemented in pure C++. No JavaScript or AJAX needed to design configurable, "smart" AJAX behaviour!

Apart from this loading aspect, all navigation itself is always done entirely in client-side DHTML. But, Wt keeps track of your state server-side (unless you wrap things in WViewWidget), generating an async call in the background with empty answers -- nothing a user would ever wait for thus.

May I finally mention that all this only applies if you switched on JavaScript. Without JavaScript, your site works equally (because you wrote only C++, no JavaScript or AJAX), but of course every click generates full page loads.

> - Site is a work in progress. Not a criticism so much
> as an observation that the site is rough, adding to
> the sense of risk about using this toolkit.

Point well taken. Perhaps the new design, we deployed today, will please you more.

Again, thanks for looking at Wt.

Koen
Koen Deforche Send private email
Friday, March 07, 2008
 
 
@Koen Deforche

Well I read all through the discussion, few things are still unanswered.

I am Web Developer who works on the so-called "temporary technology languages". I have been a Web Developer far too long and have been a *good* C++ programmer only many years back(7 yrs) (read: will have to learn again).

I can see the benefits of programming with Wt but before I dirty me hand with all the C++, I need more confidence restoring answers,

1. Is it possible to have clean urls?
2. How much C++ do a developer needs to know? (wrt porting a strong site with sessions and all secured login to Wt)
3. Web developers understand the terms sessions, ssl, state of transaction- during a connection, using predefined globals variables in a Server-side scripting language, etc

Question is, how easy is it to pick the equivalent of these in Wt?
It would be nice if you could explain more on this in detail.. to get a fairly clear idea(of translation cost in man hours).
Thanks for writing a nice toolkit which can at least facilitate the easy movers a way to save there time.
Sankett Joshi Send private email
Tuesday, March 18, 2008
 
 
@Sankett Joshi,

> 1. Is it possible to have clean urls?

Currently not: I wasn't aware of the need. But it could be done -- at least if you partly give up on AJAX. Each time you wish to switch to a new "clean" url, you will need to refresh your entire page. And loose client-side state (such as input) on widgets, unless you can live with POSTing to the new URL, but that will annoy users too). And you will need to use cookies for session tracking.

Wt was not designed for websites, but web applications (not of the type of a shopping cart, but a real desktop application). How would you define URLs if [random desktop application, e.g. Microsoft Word] was in fact running in the browser ? RESTfulness is absolutely great for web sites and shopping sites -- but makes assumptions that do not extend to other types of applications.

Unless you can live with URLs that contain a hash (#). Then, anything is possible, and completely up to you.

> 2. How much C++ do a developer needs to know? (wrt
> porting a strong site with sessions and all secured
> login to Wt)

What is a strong site?

Sessions are implicit in Wt: you are not concerned with it as a developer. Switching between https and http is a matter of redirecting from one to the other.

Wt is plain old C++, with a minimum of template classes, and an API that could be familiar to you if you have ever programmed in Qt (which was well around even 7 years ago?).

> 3. Web developers understand the terms sessions, ssl,
> state of transaction- during a connection, using
> predefined globals variables in a Server-side scripting
> language, etc
>
> Question is, how easy is it to pick the equivalent of
> these in Wt?

To be honest, that is hard to answer. Desktop application developers will be more easily familiar with Wt, I suppose. Web developers tend to think in terms of technologies, not in functionality (because it usually takes so much messing around with technology that it is hard to ignore).

> It would be nice if you could explain more on this in
> detail.. to get a fairly clear idea(of translation
> cost in man hours).

Please, have a look at some example code. All examples are really small. Take a look at the GMail-like composer -- it deals with things that are non-trivial in web applications (asynchronous file uploads?), but relatively simple in Wt.

In the end, Wt is not so much a toolkit to use for porting an existing "dynamic" website to C++, as it is a toolkit for porting an existing desktop application to the web, or, more probably to the company intranet or extranet.

Regards,
koen
Koen Deforche Send private email
Wednesday, March 19, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz