DICOM @ OFFIS

No, unfortunately you cannot - unless you port the application to the Win32 service API by yourself of course.

Weird problem indeed - in this case the linker seems to optimize away some code that is really needed in the global destructors. The problem you observe now is related to the global data dictionary. Any access to the data dictionary from the main application should fix this. Try something like "...

In our project we have never had a need to support multi-byte characters, which means that this kind of functionality is totally untested in DCMTK. It may or may not work. In the case of Unicode (UTF8), however, I would expect things to work since UTF8 never introduced null bytes in the middle of a ...

There is one other thing I am wondering: the DcmTCPConnection::networkDataAvailable method is using select() to determine the availability of... data? As far as I understand, select() will determine the availability of a network resource as opposed to finding whether there is data in a certain sock...

Actually this was an omission in the default configuration file in DCMTK 3.5.3. This has been fixed meanwhile in our CVS and the next release will have a config file supporting the Verification Service Class.

Well, lots of manual work
You will have to uncompress each frame, create a valid multi-frame PixelData element out of this and create all other attributes needed to make this a valid multiframe SC object according to part 3 of the DICOM standard.

The "web client" user interface for the worklist server has never been ported to Windows - you will need to compile and run this on Linux/Posix/Unix system or do the port on your own. In the latter case you will have to make sure that file locks created through the Perl scripts are compati...

Your application is crashing in the destructor of a global const object that libofstd declares (EC_Normal), which is strange because the destructor of this class and the corresponding base class are actually empty. The libraries you have linked against are sufficient, that is not your problem. It se...

Unless you can make sure that the files including DCMTK headers and the files using AssertMacros.h are mutually exclusive, there is probably no other way than to #undef the macro. Calling a macro "verify()" in lower case is right away stupid - there are certainly thousands of libraries tha...

First of all, DICOM image data in most cases OW uses encoding, and you should use findAndGetUint16Array() in this case to access the array, otherwise your code will have to cope with byte order issues. Secondly, the content of attribute DCM_PixelData is raw data that needs to undergo a certain numbe...

This some very old code (> 12 years) you are digging in. The timeout parameter that is passed to ASC_initializeNetwork() is only used for very specific things, mostly for determining the timeout used when reading incoming PDUs in mode DIMSE_NONBLOCKING. The global object dcmConnectionTimeout specifi...

That should not happen - dcmj2pnm should not convert the image to grayscale. If you send a sample image to <dicom at offis dot de>, we will check whether this is a bug in the tool, a problem with the image or possibly something local to your installation.

In directory config, a file named "config.log" is produced during the configure process. Check the content of this file - there should be an indication of what has gone wrong.

It should be easy to verify whether or not the code your compiler generates can be executed - write a "hello world" program, compile, link and run. If it does not work, most likely some environment variable such as LD_LIBRARY_PATH needs to be set.

This is a bug in the scanner. Viewers ignoring this bit either contain another bug that happens to compensate the one in the viewer, or they recognize defective images and then enable some internal workaround.