No more MFC?

[Mike]

I have an ISAPI extension that is very well profiled, refined, extremely fast, rock solid and is mission critical for us.

 

I'd like to move to the next VC compiler in VS9 but it seems I cannot? Not without major surgery that is.

 

The extension implements a fair amount of mapped commands via the parsemap, about a dozen. I worked with Microsoft in a 2004 Case to get the code blessed, for lack of a better term.

 

Before porting away from the exisitng implementation, I'd be interested in a gathering a full vision of what directions we might choose for this go.

 

I guess the greatest prerequisite, is that the extention persists in memory because it is central with regards to state management.

 

I am just looking to see if the shortest hop to ATL really fits the bill? Do we consider a managed code solution, if so what are the new approaches referred to as?

 

Any help would be truly appreciated,

 

Mike

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

[David Wang]

Can you help specify a few more requirements for this code base?

For example, persisting in memory is not a pre-requisite with regards
to state management. Example would be ASP.Net SQL-based session state.
You can recycle the w3wp.exe process running the ASP.Net page to get
it out memory, but state is still persisted in SQL and the next
request picks things back up in the user session without a hitch. This
design tells you that you can have a crash in the application, and as
long as state persisted to SQL before the crash, the user would not
even notice the crash happened.

Some common requirements include:
- Cost of maintenance
- Cost of development
- Performance/Scalability
- Reliability

I am also struggling to understand why you want to move to a new
compiler. Are you trying to recompile to 64bit?

//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

[Mike]

Hi and thanks David

By new compiler I meant that when I upgraded to Visual Studio 2008, the MFC
based ISAPI project will no longer compile (aka, no longer supported?).

I understand the SQL state scenario, that is why I mentioned state, it is
similar. Though the implementation is closer to a connection manager and
performance & scalability are the reasons for that. Crashes haven't been an
issue.

So the ISAPI solution has been terriffic, really fits the bill and it is a
shame that things have changed

Now that we're standing at the crossroads, porting it from MFC to another
framework, I guess a question is which will give us the greatest lifeline?

Mike

"David Wang" <w3....@gmail.com> wrote in message
news:dfc54138-dfd2-44ab...@c18g2000prh.googlegroups.com...

[David Wang]

MFC ISAPI is no longer supported by VS.

The pure ISAPI interface remains supported by the Windows SDK and IIS
and will remain that way for quite some time.

Starting with IIS7, the native server extensibility interface changes
to a new Module based API which has both native and managed code
versions, and ISAPI becomes a compatibility shim on top of the native
server extensibility API so that existing ISAPIs can run on IIS7 with
the appropriate ISAPI extensibility module installed.

Visual Studio does not really support either IIS extensibility
interface with something fancy, which is perfectly fine since one is
usually interested in performance and dependencies with native
extensibility of IIS, and the IIS interfaces provide exactly that.

//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

On Jun 17, 3:15 pm, "Mike" <m...@m.com> wrote:
> Hi and thanks David
>
> By new compiler I meant that when I upgraded to Visual Studio 2008, the MFC
> based ISAPI project will no longer compile (aka, no longer supported?).
>
> I understand the SQL state scenario, that is why I mentioned state, it is
> similar. Though the implementation is closer to a connection manager and
> performance & scalability are the reasons for that. Crashes haven't been an
> issue.
>
> So the ISAPI solution has been terriffic, really fits the bill and it is a
> shame that things have changed
>
> Now that we're standing at the crossroads, porting it from MFC to another
> framework, I guess a question is which will give us the greatest lifeline?
>
> Mike
>

> "David Wang" <w3.4...@gmail.com> wrote in message

> //- Hide quoted text -
>
> - Show quoted text -