From: Peter Olcott on

"Hector Santos" <sant9442(a)> wrote in message
> Peter Olcott wrote:
>> Fundamentally FastCGI differs from CGI in that the app is
>> held in memory rather than re-loaded every time.
> Didn't I say that a dozen times?
>> Although this feature may have limited alternatives, I
>> see
> > no reason to consider them.
> Consider what?
> It appears your concern is the 4GB meta data file. You
> have no choice but to use a memory map regardless if you
> keep the EXE active 24x7 or not.
> Your lost focus on "FASTCGI" is not solving the this
> simple design for you. You are making it far more
> complicated.
> --

That may be the case, but, the term "memory map" is
gibberish to me in this context. I envision my app reading
in all of its data, and keeping it in std::vectors. Its
going from disk to RAM. I see no need for any map.

From: Hector Santos on
Peter Olcott wrote:

>> Once again, all you need is a standard C/C++ console
>> application that reads standard input to read your HTTP
>> transfer encoded data block. You either write the
>> multi-part MIME processor or you get a library or class
>> that does it for you.
> What handles transmission errors?

Socket drop events/detection. You have to be ready for it.

> Another thing, I want to
> immediately close the connection on the first packet if
> anything besides a 24-bit PNG file is detected.

flush receiver buffer loop

> My app MUST
> be written in C++. I was envisioning this as a single app.
> One that handles the URL-encoded input, and the same one to
> process this data. In any case the one that processes this
> data must remain resident.

What web server are you going to be using?

> I have no idea what you are talking about when referring to
> a memory map.

Well you should be aware of these things around here. Other common
terms are Memory Map File (MMF) or File Map

> It is not a 4.0 GB file, it is numerous files

> making up a total of 4.0 GB.

So you open each one up as a MMF. If this is static meta data, then
merged them into one.

From: Hector Santos on
Peter Olcott wrote:

> That may be the case, but, the term "memory map" is
> gibberish to me in this context.

Look, you should of have the common respect that when people provide
FREE assistance, that you do some leg work on your own and understand
the points being made.

> I envision my app reading
> in all of its data, and keeping it in std::vectors. Its
> going from disk to RAM. I see no need for any map.


You need a vector class that offer memory map file virtualization. No
way to load up that under under 32 bit. Even you going 64 bit, you
will see need to virtualize it.

From: Joseph M. Newcomer on
See below...
On Tue, 16 Mar 2010 20:31:23 -0500, "Peter Olcott" <NoSpam(a)> wrote:

>"Hector Santos" <sant9442(a)> wrote in message
>> Peter Olcott wrote:
>>> "Hector Santos" <sant9442(a)> wrote in
>>> message
>>>>> FastCGI is portable across platforms, and most often
>>>>> faster than alternatives.
>> >>>
>>>> You are trusting the WIKI's too much.
>>> Not just Wikis, I have examined at least one book from
>>> Amazon too.
>> So? You really don't know what you are reading Peter.
>>> All That I need is a minimal cost way to keep my 4.0 GB
>>> of data loaded into memory. FastCGI is based on Sockets.
>> Independent concepts. The twain shall never meet.
>> Honestly, you will be best to use FTP. Some Browser
>> allow a Drag and Drop with FTP backends. FTP has two
>> channels, DATA and COMMAND so you can handle aborts and
>> timeouts better.
>That is not simple enough for my users. I want a browse
>button on a webpage that browses the local hard-drive. It
>seems that the only completely portable way to do this is
>HTML and this HTML is hooked up to CGI. Maybe I could build
>something from scratch at the other end to handle the input.
>I would guess that this would not provide any improvement
>over C++ FastCGI, and cost more development time.
>I am leaning toward Linux now, so a Microsoft thing ported
>to Linux may not be as good as a native Linux thing.
You have confused client-side (browsing a local directory) with server-side (CGI and
related technologies). Client-side features are usually implemented with JavaScript
embedded in HTML, or having JavaScript invoke ActiveX (a deadly combination capable of
creating security holes large enough to drive a railroad train through, sideways)

And you are making unrealisitic assumptions that massive programs will remain
memory-resident, which is host-OS-specific behavior.

You can safely ignore ISAPI, this is a dangerous technology which has been largely
replaced by CLR-based solutions (in ISAPI, if you crash your add-in, you crash all of IIS,
and if you clobber memory, or leak resources, IIS goes down, too; ISAPI is no longer
supported; for example, ISAPI projects are no longer building under VS2008 and later
versions. (And maybe under VS2005; I don't use it, so I never noticed when it went away,
but I remember it from one of the "breaking changes" lists).

For FastCGI, you need to handle connection across a full-duplex pipe, which means you have
to write platform-specific versions of your code, that is, you will need a Windows version
and a linux version if you are going to run your app on linux, and the OS interface is
going to be platform-specific (it is platform-independent only insofar as your host
language is platform-independent, e.g., PHP, PERL, Tcl, etc.; for these languages, you
rely on the implementor of the OS-interface components of the interpreter for the language
to handle the "platform independence" aspect; so my PERL or Python or PHP code remains the
same, but my C or C++ server code is going to have to change. WHich means if you wrote in
in MFC, you can't have a GUI on it, and if you wrote it in MFC, you are going to have to
use some product linke mainsoft's port of MFC to linux/unix platforms (;
not cheap). If you wrote it in pure C++ using only the stdnadrd C and C++ (STL) libraries
and no OS-specific componenents and NO GUI then you should be able to port it readily.

Note that you will have to write the platform-specific pipe interface using the
appropriate support libraries for your platform.


>> --
>> HLS
Joseph M. Newcomer [MVP]
email: newcomer(a)
MVP Tips:
From: Geoff on
On Tue, 16 Mar 2010 19:59:35 -0400, Hector Santos
<sant9442(a)> wrote:

>Some other (windows based) web servers do support a ISAPI interface,
>off hand, a early version interface. Its simple a special DLL load
>that special hooks. I believe I seen Apache. I don't think it will
>work under a wienie OS.

I did a little Wiki'ing of my own and apparently mod_isapi is
Windows-Apache-only and doesn't support filters (which is what I
envisioned for this) so it's a dead end in this case.