DICOM @ OFFIS

I'm not sure if this is what you mean but you can cast your char* pointer to Uint8*.
e.g. like this:

The opt_ variables contain the options set by the user via the command line (e.g. --aetitle sets opt_ourTitle) or some sensible default which is set at the top of storescu.cc (e.g. static OFBool opt_verbose = OFFalse;) If you then look for opt_ourTitle you can see the dcmtk call that makes use of it...

cfwin32.h defines "windows" (#define windows 1) which resulted in hard to figure out conflicts in our own sources where "windows" was used as a variable name.

The macro doesn't seem to be used anywhere within dcmtk itself ... maybe it could be removed?

I think I fixed the memory leak. The memory allocated for the association was left unreferenced and unfreed in the parent process in case of DULC_FORKEDCHILD. The following diff amends the one in my previous post and also fixes handle leakage (missing closesocket in the parent) and compilation of dc...

Index: dcmnet/apps/storescp.cc =================================================================== --- dcmnet/apps/storescp.cc (revision 4) +++ dcmnet/apps/storescp.cc (revision 6) @@ -963,17 +963,17 @@ // child process DUL_markProcessAsForkedChild(); - char buf[256]; DWORD bytesRead = 0; HANDLE hS...

Replacing DuplicateHandle with WSADuplicateSocket does seems to solve the problem for me but it requires winsock2 and changes in both dcmnet and storescp.
I ran about a hundred associations from local and remote without failure.
... memory is still leaking though.

I had the same problems with the dcmtk_20080317 cvs snapshot (on Windows XP Professional with Service Pack 2). I can't really say if this is new behaviour. I might have overlooked it before, since it's rather rare for me to open this many associations in one session. One thing I found is that the MS...

I was just about to report the same problem. (funny how this shows up now considering that 3.5.4 is already over two years old) If I start storescp with --fork (on windows) and echoscu to it from localhost a lot of times it will stop responding after a while. This might be the result of sockets not ...