alank2

I've been using:

unsigned char data[]={
255,216,255,225,7,132,69,120,105,102,0,0,77,77,0,42,0,0,0,8,0,12,1,0,0,3,0,0,0,1,1,144,0,0,1,1,0,3,0,0,0,1,1,11,0,0,1,2,0,3,0,0,0,3,0,0,0,158,1,6,0,3,0,0,0,1,0,2,0,0,1,18,0,3,0,0,0,1,0,1,0,0,1,21,0,3,0,0,0,1,0,3,0,0,1,26,0,5,0,0,0,1,0,0,0,164,1,27,
0,5,0,0,0,1,0,0,0,172,1,40,0,3,0,0,0,1,0,2,0,0,1,49,0,2,0,0,0,31,0,0,0,180,1,50,0,2,0,0,0,20,0,0,0,211,135,105,0,4,0,0,0,1,0,0,0,232,0,0,1,32,0,8,0,8,0,8,0,10,252,128,0,0,39,16,0,10,252,128,0,0,39,16,65,100,111,98,101,32,80,104,111,116,111,115,104,

...

};

But it is a large amount of data and I wonder if there is a better way?

Thank you - I disabled the warnings and that did solve the problem:

#pragma warn -8026
#pragma warn -8027
#include <shlobj_core.h>
#pragma warn .8027
#pragma warn .8026

I like that better than my other approach.

I found this page:

https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Standard_RTL_Path_Functions_across_the_Supported_Target_Platforms

And then found this:

UnicodeString us;

us=System::Ioutils::TPath::GetPublicPath();

I am trying to get the programdata folder.  I've been using:

cppbuilder 10.3.3

LPITEMIDLIST pidl

SHGetSpecialFolderLocation(NULL, CSIDL_COMMON_APPDATA, &pidl)

SHGetPathFromIDListW(pidl, APath)

This works fine in a VCL application, but a FireMonkey application, none of it is recognized.

I tried to include <shlobj_core.h>, but this gives 1500+ warnings about the below and then fails.

[bcc32 Warning] shobjidl_core.h(26477): W8026 Functions with exception specifications are not expanded inline
  Full parser context
    mycode.cpp(33): #include c:\program files (x86)\embarcadero\studio\20.0\include\windows\sdk\shlobj_core.h
    shlobj_core.h(86): #include c:\program files (x86)\embarcadero\studio\20.0\include\windows\sdk\shobjidl_core.h
    shobjidl_core.h(26477): decision to instantiate: ACTIVATEOPTIONS |(ACTIVATEOPTIONS,ACTIVATEOPTIONS) throw()
    --- Resetting parser context for instantiation...

I was using this function because this code has to run on some older compilers, but if I can't get it to work I can use something else.

Interesting - I was reading the differences page and this came up:

Clang-enhanced C++ compilers do not allow the use of sizeof in a preprocessor directive, such as #if sizeof(ATypeName) > 20.

How can one then test for sizes if this is not an option - is there a workaround/alternative method?

Three?

clang

classic

What else?

6 hours ago, Roger Cigol said:

To make sure we understand what you are trying to do. You are trying to use the DEF file to specify to the linker which functions to export (and the names of the functions you want them exported as).   <can you confirm this, please?>

Yes, that is exactly what I am trying to do.

>Can you confirm that you are using the clang32 compiler for your 32bit code  (if not then first thing to try is to use the clang32 compiler - maybe it's name mangling will be the same as the clang64 (I haven't checked this)).

I am using the classic compiler, I just have more experience with it so I stick with it.  I would think the clang compiler would still mangle/underscore the names for 32-bit code.

Thanks for checking!

I found the option -WU mentioned in the help and it works at the command line, but putting it in CFLAG1 in the BPR file did not accomplish anything.

Sorry Remy; I saw the "General Help", but didn't look at its parent folder.  I appreciate the help.

2 hours ago, David Heffernan said:

Doesn't

EXPORTS
  CCfgClassNew

work?

No, it comes up with an error:

[ilink32 Warning] Warning: Attempt to export non-public symbol 'CCfgClassNew'

The problem is that 32-bit mangles the name with an underscore and 64-bit does not, which is why I am using the DEF file to unmangle the 32-bit version of the DLL so it and the 64-bit version have consistent names.

ALSO, one more odd thing.  if the DEF file changes in any way, this error is produced when trying to build:

[ilink32 Error] Invalid command line switch for "ilink32". Parameter "ItemSpec" cannot be null.

The way to fix it is to remove the DEF file and add the DEF file back again, then it will build without the error.

Everyone, maybe I should have specified C++Builder.  The DEF files are for compiling two different versions, 32-bit and 64-bit DLL's.

32-bit version top two lines:

EXPORTS
  CCfgClassNew=_CCfgClassNew

64-bit version top two lines:

EXPORTS
  CCfgClassNew=CCfgClassNew

The 64-bit lacks the underscore, my goal here being to produce a DLL that uses the same name for the function no matter whether it is 32-bit or 64-bit.  I want to access it as CCfgClassNew either way.

Maybe there is no way to do this in a DEF file and I have to do different projects.

I am surprised at this.  Clearly it can't assign a value before it evaluates a value.  I can put the increment on the next line to appease it.

Isn't there a definition or design about evaluation order?

I still have some projects in the old bcb6 that I need to compile sometimes.  One thing I noticed is that if I create a new win32 console mode application, it doesn't let me replace main;

int main(int argc, char* argv[])

With wmain:

int wmain(int argc, wchar_t* argv[])

In cppb10 there is an option _TCHAR maps to where you can select char or wchar_t and this seems to clue the linker in to look for main or wmain.  Is there an equivalent option for bcb6? (for anyone who remembers this old compiler!)

I tried looking in the compiler/linker settings, but I am missing it or it doesn't exist.

The line of code is this:

AData[ui3++]=(AData[ui3]<<4) | (tow_lower(AString[ui1])-'a'+10);

I know I am incrementing ui3 in the destination AFTER it is being set.  I am using ui3 in the expression, but it shouldn't be changed until the end.  Why the warning?

I don't think these directives work in a DEF file.

I have a project that builds a DLL and I have two different .DEF files (one for WIN32, and for WIN64).  I want to avoid making two projects and so I've been removing/adding the correct .DEF file before I build that platform, is there a better way?

Is there a way to do this?  What I have done successfully is create functions that access the class, put them in a DLL, and then call that DLL from Delphi which does work, but if there is another way it is probably an easier way.

How would you wait for the thread to stop?  The current method does wait for any process running to finish.  I get how to trigger the thread to stop using the onstop/onshutdown events, but where do you actually make it wait on the thread?

Thanks for the tip Remy; I'll give that approach a try as well.

Thanks Anders; my code snippet above was from within ServiceExecute.  I appreciate the explanation, that makes sense!

I have a C++ Builder service application that uses a timer TProcess to do something every 60 seconds.  The "something" was processing some data and making a SQL call.  I was accessing one of the query columns outside of a try catch block and it was throwing an exception because I was accessing it as an integer and it was a bit type and needed to be accessed as a boolean.  I get the error and how to fix it, but I am trying to troubleshoot how to stop the exception from being unhandled at a higher lever then leaving the service in a stuck state.

  try
    {
      while (!Terminated || !TProcess->Enabled) //do not quit if process is running until it is finished
        {
          ServiceThread->ProcessRequests(true);
          Sleep(250);
        }
    }
  catch(Exception &exception)
    {
      log1.Logf(L"ERROR: %s (main loop)", exception.Message.w_str());
    }

At first I just had what was in the try block above on its own.  Then I wrapped it in the try block and expected that this would catch the exception and at least log it.  What I don't understand is why the above did not catch the exception.  I repeated the test and it still hung with no log message.  When I moved the code that accesses the SQL field into its own try catch block with logging, it did log the error related to the issue.

I saw those notes, but I wondered if they meant that a system follows the compatibility level of the registry setting.  I figured the compatibility level that the library/components were using was separate from that, or is LmCompatLevel picked up someone from the registry somewhere?

After looking through the source recommended above (OverbyteIcsHttpProt.pas and OverbyteIcsNtlmMsgs.pas), I found a LM compatibility level.  It was set to 0 and I don't see it exposes in the properties of SSLHTTPCli, but I changed it using:

SslHttpCli1->LmCompatLevel=1;

And this fixed the issue!

Thanks FPiette and Angus for the help; I appreciate it!

Thanks for the tips - I'll take a look at the two pas files and see if anything jumps out.

>You might also try tracing through the different messages passed during the handshaking to see where it dies.

I'm not sure how to do this exactly.  Could I attach the .pas to my project and then set some breakpoints?

>Are your two environments running the Windows Server version?  

They say they are the same, but I have to think there is something different.

I appreciate the help!