Polity, Here's my recommendation based on your last message. I think you are doing the correct thing by writing low level libraries in C++ and then use C++/CLI as the bridge between managed and unmanaged code. That was exactly the approach I took with my project. However I would not worry about supporting MFC unless there is an absolute business reason. The reason I'm saying this is because if you are going to support .NET then I would use Windows.Forms to supply the user interface. If you are to going to be running mulit-platform then Windows.Forms is supported by Mono. If your application is going to run on Vista you can also write to Windows Presentation Layer. My general point here is that why support MFC and all of its overhead when you are willing to accept the overhead of .NET. In fact WTL is much lighter than MFC anyway. Just another case in point was that Mike Blazack (sp?) the lead developer of MFC was extremely skeptical of .NET Windows Forms initially. I was meetings where he voiced his skepticism. However after a while he began to embrace MFC. I was also a member of the original AFX team that wrote MFC. I liked MFC 1.0 but hated every incarnation of MFC after 1.0 when in 2.0 they added the OLE Doc/View support. The whole Doc/View stuff in MFC was poorly designed and intrusive. A former dev started his own open source initiative (now defunct) that I participated in of a window wrapper that was much light weight than MFC. I would mothball MFC. If you need to do UI in C++ I greatly suggest WTL. If you want a very good open source C++ UI then I'd suggest FoxToolkit, WXWidgets, and I think Qt even has one that is open source for Windows now. Another point if you go .NET. If you write an installer for your application you can include the .NET redistributable in your installer. Microsoft allow you to redistribute the .NET runtime library files so you can install the .NET runtime and write to .NET without having to worry whether or not the client has .NET. >>First: What do you recommend from the story above: .NET or MFC? I guess I already answered that question. >>Second: What about DirectX? just a small mind bothering There are .NET wrappers for DirectX. I haven't written a DirectX app in years however I did write a small DirectX application from C# PRIOR TO the release of the DirectX wrappers. You can do that because DirectX is supported by COM. There is a sample in Adam Nathan's .NET Interoperability book. I think there were some tweaks needed in the IL to m

See if this article[[^](http://this article)] helps led mike

Gotcha man :) I was just extending my comment about TCP sockets on an HTTP server :)

For socket operations you should't be touching (or looking at) anything in the OVERLAPPED structure. None of it applies to IOCPs and especially the "Internal" fields which are for use by the system so they have NO meaning to your code. Ok, you can look at them, but don't expect any specific values :) I would suggest clearing the OVERLAPPED struct to 0s before every operation. If you need to add your own fields (I'm not sure how one would do overlapped ops without doing this) then define your own struct which includes an OVERLAPPED struct. You may have seen these, but here's a couple articles that helped me alot when I first used an IOCP... Writing Windows NT Server Applications in MFC Using I/O Completion Ports [^] Windows Sockets 2.0: Write Scalable Winsock Apps Using Completion Ports[^] INFO: Design Issues When Using IOCP in a Winsock Server[^] And this one's in the online help - <--edit -- modified at 13:21 Tuesday 16th January, 2007

ok, thnx :)

Nope, that aint the proble. would be really quick ;) and srry about the code, its just a test project. when i got it all working i'm gonna merch it and mostly rewrite it. Thanks anyway

thanks, gonna test it asap

thanks, its working :)

thanks, i've declared one static object already and used the extern keyword in nearly every file. but i see yours is better

yes i am, as i already said, that piece of code is all messed up :)