My first steps with C++

[Mike Stefanik]

I know I *always* get shot down when I mention this, but XP is going end of like in April 2014.  I'm sure there will be a lot of people try to keep using it, but without security updates, it would not be wise.

That's generally the case, but not entirely accurate. Microsoft has left the door open that they may issue hotfixes for what they described as "very critical security flaws", but aside from that, after April 8th, 2014 they will only be providing updates for corporate customers with custom support plans (typically those are support agreements that a company has with Microsoft for their fleet of PCs, where they are charged a certain amount per PC, per year with the costs increasing for each year after the product has reached its end-of-life).

And just so folks are aware, all things XP will not be going dark in April. Windows Update will continue to work, and you'll continue to be able to install and activate XP on new systems. It's just that there won't be any new updates published, normally. I suspect that if there was some particularly nasty zero-day vulnerability that shows up, Microsoft might feel compelled to push out a security update for XP, but you can't count on it.

I know when we've talked to our customers, a lot of them plan on continuing to support XP beyond it's end-of-life and that means we will need to continue to support them. I'm sure it will reach a point where Windows XP becomes like Windows 2000, but with still over 30% marketshare, XP will continue to be around for a while. My concern is with malware that is being kept on the shelf right now because it exploits an as-of-yet undiscovered flaw in XP and they only want to deploy it after April, 2014 for maximum effect.

[Jim Dunn]

Mike, thanks for your reply, well said, and... thanks for going easy on me.

[Patrice Terrier]

I have been faced with a nasty problem while allocating dynamic memory from inside of a DLL.

I am using this to allocate the memory inside of the DLL
BYTE* lpArray = (BYTE*) malloc(Xin * Yin * 4);
then i return the BYTE* to be used outside of the DLL, within the calling EXE,
and after i am done with it, i am freeing back the memory using this:
free (lpArray);

And bim, bam, badaboum, i am throwing up an exception error as soon as free.c is performing
        retval = HeapFree(_crtheap, 0, pBlock);
        if (retval == 0)
        {
            errno = _get_errno_from_oserr(GetLastError());
        }

I have never been faced with this problem with PB (using REDIM to allocate dynamic memory), thus i was taken by surprise by that one.

I have found this article: http://msdn.microsoft.com/en-us/library/ms235460%28v=vs.110%29.aspx
that seems to match this case.

[James C. Fuller]

Patrice,
It appears you should be using free as you use malloc to allocate the memory?

James

[Patrice Terrier]

James--

Yes, I am using free already, what i have posted is the debug code that shows, that the matching C code that does the work under the hood at the time we use free, is causing the havoc.

I know how to solve the problem (allocating memory in the calling application, rather than in the DLL), but it is just to warn those who may allocate dynamic memory from within a DLL, especially when using the "Multithread /MT" flag option with another DLL or main application using a different setting.

[Mike Stefanik]

You should never use malloc or new to allocate memory from within a DLL and then free that memory in an external function (i.e.: in the executable or another DLL). If you want to allocate a block of memory that will be released by another function in your executable, then you want to use HeapAlloc:

Code Select Expand


LPBYTE lpArray = (LPBYTE)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, (Xin * Yin * 4));


And you would free that memory by calling:

Code Select Expand


HeapFree(GetProcessHeap(), 0, lpArray);


Another option would be to provide your own function that explicitly frees the memory with your DLL. The reason is that when you statically link to the CRT, your DLL has its own instance of the runtime heap which is different than the heap that is allocated for your executable.

[Patrice Terrier]

I thougth that C++ malloc was an encapsulation for HeapAlloc, my mistake.

Thanks Mike!

[Mike Stefanik]

Both new and malloc do eventually call HeapAlloc, but the runtime allocates it's own heap rather than using the default process heap. It also does things a bit differently if you have a debug build to make it easier for it to track allocations, etc. Note that this also impacts allocations that go the other way (i.e.: your DLL should never attempt to free a block of memory that has been allocated by your main executable using malloc or new).

[Patrice Terrier]

Mike--

Actually, malloc() (and other C runtime heap functions) are module dependant, which means that if you call malloc() in code from one module (i.e. a DLL), then you should call free() within code of the same module or you could suffer some pretty bad heap corruption (and this has been well documented). Using HeapAlloc() with GetProcessHeap() instead of malloc(), including overloading new and delete operators to make use of such, allow you to pass dynamically allocated objects between modules and not have to worry about memory corruption if memory is allocated in code of one module and freed in code of another module once the pointer to a block of memory has been passed across to an external module.

I found it there: http://stackoverflow.com/questions/8224347/malloc-vs-heapalloc

a confirmation of your previous post, thanks!

[Patrice Terrier]

After using C++ for several monthes now, i can share this feedback with you...

Once the initial learning phase is over:
the first thing that really make a big difference is that you don't have to mess with includes and headers anymore,
second you can type in ALL the Windows API without restriction,
third you can use the latest technology and produce 32-bit and 64-bit from the same source code.

Switching to UNICODE is the thing that you must do as soon as possible,
then learn how to use VECTOR (dynamic array replacement, and much more),
and move to wstring (just as easy as BASIC strings).

Then try to keep as close as possible to the syntax indentation you are using in PB, to ease the reading of the source code.
Use Hungarian notation to easily detect the variable type.

Learn how to cast one variable type to another, because C++ is using strong typing.
ALWAYS assign your variables, your arrays, your type structures, before using them.

Be careful on the / (divide) optimization, always use (float) to avoid rounding errors.

Never try to compare strings with == (because C++ does a pointer comparison), instead use the string.compare() function.

After a while, you will realize that for a SDK programmer, C++ is not that harder to use than PB, as long as you stay away of the C++ encapsulation, that is just another kind of DDT.

...

[Patrice Terrier]

Does anyone has used the 64-bit version of BASS.dll ?

...

[Brice Manuel]

Does anyone has used the 64-bit version of BASS.dll ?

No, but I was planning to very soon.