TR Forums

Flying Fox wrote:

Usually it is because of dependencies. ... (or run the Depends utility)?

Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

Flying Fox wrote:

Is there any dependent DLL flagged in red (the dependency tree on the left)?

What does dumpbin /imports say?

sparkman wrote:

Decimal 3221225501 equals hex 0xc000001d and I found somebody with apparently that same error, here: http://www.bailopan.net/blog/?p=33

I think it's possible that this project of mine (which I inherited from somebody else no longer available) is using SSE instructions not supported by my aging Athlon XP workstation?

wibeasley wrote:

I'm curious. Why was SSE2 used in the release build but not the debug build? Was the compiler automatically optimizing something? Or did the code have a preprocessor #IF DEBUG directive?

wibeasley wrote:

I'm curious. Why was SSE2 used in the release build but not the debug build? Was the compiler automatically optimizing something? Or did the code have a preprocessor #IF DEBUG directive?

sparkman wrote:

A different section of this software uses SSE2 assembly code to accelerate some mundane tasks. So SSE2 is a requirement for this software and I'm moving to a more-modern workstation to continue development. In the C++ DLL that wouldn't load, there doesn't appear to be any explicit SSE2 code, but the Release settings enabled SSE2 code generation, I suppose just in case the compiler could find some benefit in SSE2, since SSE2 support was already required for the software.

wibeasley wrote:

It would be nice if Visual Studio had a built-in tool that displayed (on one screen) all the differences in compiler options between build configurations. When I'm troubleshooting my mistakes, I hate flipping through that 'Configuration' combo box for all 80,000 Project property pages. Off the top of their head, does anyone know of a tool that does this?

Flying Fox wrote:

Compiler optimization is disabled by default in debug builds, so there is no SSE2 instructions generated in the machine code.

Flying Fox wrote:

If I really want to study that list I usually go the other way by looking up the alphabetical listing of the compiler options and then work backwards.

wibeasley wrote:

So the release build had the "Streaming SIMD Extensions 2 (/arch:SSE2)" compiler option, but the debug build didn't?

wibeasley wrote:

It would be nice if Visual Studio had a built-in tool that displayed (on one screen) all the differences in compiler options between build configurations. When I'm troubleshooting my mistakes, I hate flipping through that 'Configuration' combo box for all 80,000 Project property pages. Off the top of their head, does anyone know of a tool that does this?

wibeasley wrote:

If you don't mind Sparkman, I have one more question. Was the SSE issue located in the DLL you were calling, or the in the assembly that called the DLL?

wibeasley wrote:

FF, do you think the error message would be the same in both cases?

Flying Fox wrote:

In a real application that error should never be seen, your application should check for it and handle the situation as designed (either provide a downlevel code path, or warn the user before loading the offending code).

just brew it! wrote:

Ahh, the joys of Visual Studio option settings and debug vs. release builds. I've wasted many an hour back in the day chasing down problems due to these.

wibeasley wrote:

just brew it! wrote:

Ahh, the joys of Visual Studio option settings and debug vs. release builds. I've wasted many an hour back in the day chasing down problems due to these.

How are you able to avoid it now? Different IDE?

wibeasley wrote:

Flying Fox wrote:

In a real application that error should never be seen, your application should check for it and handle the situation as designed (either provide a downlevel code path, or warn the user before loading the offending code).

What do you think about distributing two different dlls? One with SSE2 (or maybe higher) and one without? In the calling assembly, the SSE capability would be checked only once (maybe soon after the program loads) and then determine the correct dll version for all future calls.

From an OO/encapsulation perspective, this would a bad approach. It would be better to have the called DLL handle/hide these compatibility issues, right?

class FunkyCalculationBase
{
public:
  virtual Answer Run(InputData input) = 0;
};

class FunkyCalculationGeneric : public FunkyCalculationBase
{
public:
  FunkyCalculationGeneric()
  {
      LoadGenericFunctionDLL();
  }

  virtual Answer Run(InputData input)
  {
    // do stuff with generic DLL
  }
};

class FunkyCalculationSSE2 : public FunkyCalculationBase
{
public:
  FunkyCalculationSSE2()
  {
      LoadSSE2FunctionDLL();
  }

  virtual Answer Run(InputData input)
  {
    // do stuff with SSE2 DLL
  }
};

wibeasley wrote:

But from a performance perspective, I'd hope this approach is beneficial because it avoids repeated calls to the CPUID instruction, which I've read is an expensive operation. (I'm assuming the call to the function is brief enough that the CPUID call isn't effectively amortized).

wibeasley wrote:

Of course if numerical performance wasn't a concern, I guess the release configuration shouldn't even have the SSE compiler option.

wibeasley wrote:

Am I thinking about these (robustness vs. performance) tradeoffs the right way? Any big issues that would blindside me if I used this approach?

wibeasley wrote:

just brew it! wrote:

Ahh, the joys of Visual Studio option settings and debug vs. release builds. I've wasted many an hour back in the day chasing down problems due to these.

How are you able to avoid it now? Different IDE?