>> What exactly is this fixation and or fascination you have with me?

None, which is why I am commenting on what you say, generally. You see, you say A LOT of weird stuff. You usually present it as reasoned and logical and many, many times as the obvious truth. Weird stuff fascinates me. What you say fascinates me.

Yeah well let's just not get too clingy here, I am a happily married man and I'm not in any dire need of a following.

Been watching the FCP crowd being able to process the Canon 5D Mark II files a heck of lot more quickly than most PC users. Little jealous. Thought I'd go with Vegas 9 and had high hopes for the 64 bit (still running 32bit here) with Cineform. Now, I'm not so sure.

Anybody tried the Canon native .mov files in version 9? Do they play in realtime? Edit any faster?

Anyway, this was too long a read, but at least it saves me the upgrade money for a while.

How odd....

If it's any consulation Blink, these guys are like a burr under a horse's saddle.. they are quite small & insignificant, yet will irritate the hell out of the much more powerfull & larger horse... 'till removed

.. of 'course... in a metaphorically 'sorta way...

"Mongo only pawn in game of life"......

"How odd...."

Funny.... that's what I keep saying. Careful though, you aught to be wary of taking my side in this absurdity.... burrs are sticky... and they don't mind who they cling to :)

MS does change things,,,,,,,,,,,,,, sometimes fast, after they work it thru the committees.... ;-)

-------------------------------------------------------
Unsafe at any speed: Memcpy() banished in Redmond


Larry? Steve? Linus?

By Dan Goodin in San Francisco • Get more from this author

Posted in Security, 15th May 2009 00:39 GMT

Memcpy() and brethren, your days are numbered. At least in development shops that aspire to secure coding.

Microsoft plans to formally banish the popular programming function that's been responsible for an untold number of security vulnerabilities over the years, not just in Windows but in countless other applications based on the C language. Effective later this year, Microsoft will add memcpy(), CopyMemory(), and RtlCopyMemory() to its list of function calls banned under its secure development lifecycle.

Memcpy has long served as a basic staple of C-based languages, providing a simple way to copy the contents from one chunk of memory to another. Its drawback comes when the source to be copied contains more bytes than its destination, creating overflows that present attackers with opportunities to remotely execute code in the underlying application.

"That's definitely one of those notoriously dangerous C commands," said Johannes Ullrich, CTO of the SANS Institute, who teaches secure coding classes to developers. He likened memcpy() to other risky functions such as strcpy() and strcat(), which have Microsoft has already banned after exacting untold misery over the years.

Developers who want to be SDL compliant will instead have to replace memcpy() functions with memcpy_s, a newer command that takes an additional parameter delineating the size of the destination buffer. The command is already supported in Microsoft's Visual C++, but according to Ullrich, native support doesn't yet seem to be available in the GCC compiler. (This evidently can easily be worked around, according to this discussion. Readers who know other approaches are encouraged to leave a comment).

---------------------------------------------------------


This is the reference article.............................

This paper is derived from the book The Security Development Lifecycle

--------------------------------------------------------
Security Development Lifecycle (SDL) Banned Function Calls


Michael Howard
Senior Security Program Manager
Security Engineering
Microsoft Corporation

March 2007

Note: This paper is derived from the book The Security Development Lifecycle, by Michael Howard and Steve Lipner, Microsoft Press, 2006.

Prohibiting the use of banned APIs is a good way to remove a significant number of code vulnerabilities — this practice is reflected in Stage 6 of The Microsoft Security Development Lifecycle: "Establish and Follow Best Practices for Development." It can also be referenced in Chapter 11 of the Microsoft Press Book The Security Development Lifecycle.

When the C runtime library (CRT) was first created about 25 years ago, the threats to computers were different; machines were not as interconnected as they are today, and attacks were not as prevalent. With this in mind, a subset of the C runtime library must be deprecated for new code and, over time, removed from earlier code. It's just too easy to get code wrong that uses these outdated functions. Even some of the classic replacement functions are prone to error, too.

This list is the SDL view of what comprises banned APIs; it is derived from experience with real-world security bugs and focuses almost exclusively on functions that can lead to buffer overruns (Howard, LeBlanc, and Viega 2005). Any function in this section's tables must be replaced with a more secure version. Obviously, you cannot replace a banned API with another banned API. For example, replacing strcpy with strncpy is not valid because strncpy is banned, too.

Also note that some of the function names might be a little different, depending on whether the function takes ASCII, Unicode, _T (ASCII or Unicode), or multibyte chars. Some function names might include A or W at the end of the name. For example, the StrSafe StringCbCatEx function is also available as StringCbCatExW (Unicode) and StringCbCatExA (ASCII).

Table 1. Banned string copy functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
strcpy, wcscpy, _tcscpy, _mbscpy, StrCpy, StrCpyA, StrCpyW, lstrcpy, lstrcpyA, lstrcpyW, strcpyA, strcpyW, _tccpy, _mbccpy String*1Copy or String*CopyEx strcpy_s

1 For StrSafe, * should be replaced with Cch (character count) or Cb (byte count)

Table 2. Banned string concatenation functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
strcat, wcscat, _tcscat, _mbscat, StrCat, StrCatA, StrCatW, lstrcat, lstrcatA, lstrcatW, StrCatBuffW, StrCatBuff, StrCatBuffA, StrCatChainW, strcatA, strcatW, _tccat, _mbccat String*Cat or String*CatEx strcat_s

Table 3. Banned sprintf functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
wnsprintf, wnsprintfA, wnsprintfW, sprintfW, sprintfA, wsprintf, wsprintfW, wsprintfA, sprintf, swprintf, _stprintf String*Printf or String*PrintfEx sprintf_s

Table 4. Banned "n" sprintf functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
_snwprintf, _snprintf, _sntprintf, nsprintf String*Printf or String*PrintfEx _snprintf_s or _snwprintf_s

Table 5. Banned variable argument sprintf functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
wvsprintf, wvsprintfA, wvsprintfW, vsprintf, _vstprintf, vswprintf String*VPrintf or String*VPrintfEx _vstprintf_s

Table 6. Banned variable argument "n" sprintf functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
_vsnprintf, _vsnwprintf, _vsntprintf, wvnsprintf, wvnsprintfA, wvnsprintfW String*VPrintf or String*VPrintfEx vsntprintf_s

Table 7. Banned "n" string copy functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
strncpy, wcsncpy, _tcsncpy, _mbsncpy, _mbsnbcpy, StrCpyN, StrCpyNA, StrCpyNW, StrNCpy, strcpynA, StrNCpyA, StrNCpyW, lstrcpyn, lstrcpynA, lstrcpynW, _fstrncpy String*CopyN or String*CopyNEx strncpy_s

Table 8. Banned "n" string concatenation functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
strncat, wcsncat, _tcsncat, _mbsncat, _mbsnbcat, StrCatN, StrCatNA, StrCatNW, StrNCat, StrNCatA, StrNCatW, lstrncat, lstrcatnA, lstrcatnW, lstrcatn, _fstrncat String*CatN or String*CatNEx strncat_s

It is common wisdom to replace functions like strcpy with the counted "n" version, such as strncpy. However, in our experience, the "n" functions are also hard to secure (Howard 2004), so we have banned their use in new code.

Table 9. Banned string tokenizing functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
strtok, _tcstok, wcstok, _mbstok None strtok_s

Table 10. Banned Makepath functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
Makepath, _tmakepath, _makepath, _wmakepath None _makepath_s

Table 11. Banned Splitpath functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
_splitpath, _tsplitpath, _wsplitpath None _splitpath_s

Table 12. Banned scanf functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
scanf, wscanf, _tscanf, sscanf, swscanf, _stscanf None sscanf_s

Table 13. Banned "n" scanf functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
snscanf, snwscanf, _sntscanf None _snscanf_s

Table 14. Banned numeric conversion functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
_itoa, _itow, _i64toa, _i64tow, _ui64toa, _ui64tot, _ui64tow, _ultoa, _ultot, _ultow None _itoa_s, _itow_s

Table 15. Banned gets functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
gets, _getts, _gettws String*Gets gets_s

Table 16. Banned IsBad* functions and replacements
Banned APIs
IsBadWritePtr, IsBadHugeWritePtr, IsBadReadPtr, IsBadHugeReadPtr, IsBadCodePtr, IsBadStringPtr These functions can mask errors, and there are no replacement functions. You should rewrite the code to avoid using these APIs. If you need to avoid a crash, wrap your usage of the pointer with __try/__except. Doing this can easily hide bugs; you should do this only in areas where it is absolutely critical to avoid a crash (such as crash recovery code) and where you have a reasonable explanation for why the data you're looking at might be invalid. You should also not catch all exceptions, but only types that you know about. Catching all exceptions is just as bad as using IsBad*Ptr.

For IsBadWritePtr, filling the destination buffer using memset is a preferred way to validate that output buffers are valid and large enough to hold the amount of space that the caller claims they provided.

Table 17. Banned OEM conversion functions and replacements
Banned APIs Windows Replacement
CharToOem, CharToOemA, CharToOemW, OemToChar, OemToCharA, OemToCharW, CharToOemBuffA, CharToOemBuffW WideCharToMultiByte

Table 18. Banned stack dynamic memory allocation functions and replacements
Banned APIs Windows Replacement
alloca, _alloca SafeAllocA

For critical functions, such as those accepting anonymous Internet connections, strlen must also be replaced:

Table 19. Banned string length functions and replacements
Banned APIs StrSafe Replacement Safe CRT Replacement
strlen, wcslen, _mbslen, _mbstrlen, StrLen, lstrlen String*Length strnlen_s
Why the "n" Functions Are Banned

The classic C runtime "n" functions (such as strncpy and strncat) are banned because they are so hard to call correctly. The authors have seen numerous errors calling these functions in an attempt to make code more secure. Note that we're not saying the replacements are perfect, but issues with the current "n" functions include non-null termination of overflowed buffers and no error returns on overflow.

The newer StrSafe and Safe CRT functions are more consistent on failure.
Important Caveat

Simply replacing a banned function call with a better replacement does not guarantee that the code is secure. It's possible to misuse the replacement function, most commonly by getting the destination buffer size wrong.

Review all instances of replaced function calls, and verify that the destination buffer size is correct.

Choosing StrSafe vs. Safe CRT

There is an overlap between these two sets of replacement C runtime functions. Which you choose depends on your specific situation; the following table should help you make the decision. In some cases, you might have little choice but to use one over the other; for example, if your code calls itoa a great deal, there is no replacement in StrSafe, but there is in Safe CRT. You would need to either code around the itoa call or use Safe CRT.

Table 20.
StrSafe Safe CRT
Distribution Method Web (msdn.microsoft.com) Microsoft Visual Studio 2005
# Headers One (StrSafe.h) Numerous (various C runtime headers)
Library Version Available Yes Yes
Inline Version Available Yes No
Industry Standard No Not Yet (Secure C Lib Functions)
Kernel Mode Yes No
Return Type HRESULT (user mode) or NTSTATUS (kernel mode) Varies by function (errno_t)
Requires Code Changes Yes Yes
Main Focus Buffer overrun issues Various, including buffer overruns
Using StrSafe

To use StrSafe in your C or C++ code, simply add the following header:
Copy Code

#include "strsafe.h"

This will make the functions inline. If you want to use the library version, strsafe.lib, add the following to your code:
Copy Code

#define STRSAFE_LIB
#include "strsafe.h"

Note that all the StrSafe functions include Rtl versions for kernel use.
StrSafe Example

The following code
Copy Code

void Function(char *s1, char *s2) {
char temp[32];
strcpy(temp,s1);
strcat(temp,s2);
}

when converted to StrSafe might look like this:
Copy Code

HRESULT Function(char *s1, char *s2) {
char temp[32];
HRESULT hr = StringCchCopy(temp,sizeof(temp),s1);
if (FAILED(hr)) return hr;
return StringCchCat(temp,sizeof(temp),s2);
}

Using Safe CRT

The Safe CRT is included with Visual Studio 2005. When you compile code using this compiler, it will automatically warn you of the deprecated functions in the code. Also, in some cases, the compiler will change some function calls to safe function calls if the destination buffer size is known at compile time and CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES is #defined in the code.

For example, the following code
Copy Code

int main(int argc, char* argv[]) {
char t[10];
...
if (2==argc)
strcpy(t,argv[1]);

...
return 0;

}

is changed by the compiler to this:
Copy Code

int main(int argc, char* argv[]) {
char t[10];
...
if (2==argc)
strcpy_s(t,_countof(t),argv[1]);

...
return 0;
}

Safe CRT Example

The following code
Copy Code

void Function(char *s1, char *s2) {
char temp[32];
strcpy(temp,s1);
strcat(temp,s2);
}

when converted to the Safe CRT might look like this:
Copy Code

errno_t Function(char *s1, char *s2) {
char temp[32];
errno_t err = strcpy_s(temp,sizeof(temp),s1);
if (!err) return err;
return strcat_s(temp,sizeof(temp),s2);
}

Other Replacements

If you are using C++, you should seriously consider using the std::string template class rather than manipulating buffers directly.

Many *nix variants, including OpenBSD and some Linux operating systems, include support for string copy replacements strlcpy and strlcat (Miller and de Raadt 1999).
Tools Support

The Visual Studio 2005 compiler has built-in deprecations for these functions; all C4996 compiler warnings should be investigated to make sure that the function in question is not on the preceding banned list. Also, look out for code that disables this warning, such as #pragma warning(disable:4996).
ROI and Cost Impact

Removing banned APIs is one way to reduce potential security bugs with very little engineering effort, as can be seen at the start of this document. Some Microsoft security bulletins would not have been necessary if banned APIs had not been used.
Metrics and Goals

The metric to track is the number of banned APIs in former code and in new code. The quantity should be zero for new code and should follow a glide path down over time for earlier code.
References

(Howard, LeBlanc, and Viega 2005)

Howard, Michael, David LeBlanc, and John Viega. 19 Deadly Sins of Software Development. New York, NY: McGraw-Hill, 2005. Chapter 1, "Buffer Overruns."

(Howard 2004)

Howard, Michael. "Buffer Overflow in Apache 1.3.xx fixed on Bugtraq—the evils of strncpy and strncat," http://blogs.msdn.com/michael_howard/archive/2004/10/29/249713.aspx, October 2004.

(Miller and de Raadt 1999)
-------------------------------------------------------

Well I find that we should give the focus back to the original topic. Also I don't see the point in posting copies of articles found somewhere else. A link to the articles would have been more than enough. Or are we currently doing a contest of who can post the longest message ? If so, why not post the Vegas documentation ?

Well... Apit is quite correct. Microsoft DOES change things and sometimes they do it pretty fast. And guess what.... they're allowed to. It's their software and making it better is their job. and when they do change things, other 3rd party operations or otherwise Dependants of M$ fall in line and issue the various updates so that their software continues to work and give them an income.

I see absolutely NOTHING different here between Sony and Cineform. Sony is allowed to make their software better (and I for one thank them for that) and now it's Cineform's turn to issue the various updates to see that their software continues to be compatible..... that is if they still want to see an income from Vegas users.... and my guess to that is a big YES.

And please don't state this absolute nonsense about how SCS is going to lose millions of dollars and thousands of customers over this.... "really critical error in judgement." I only see a relatively small crowd here being extremely vocal and while it certainly is an inconvenience to those who depend on Cineform, it's not incorrectable.... Cineform simply needs a bit of time to adjust..... but they will.

And BTW:
I guess you're........... "paraphrasing" here Cliff:
"Ehh,...so what? Cineform doesn't work in V9,...we don't think that enough of our valued fan-base will be upset about that..."

Because I looked high and low and could not find anything remotely CLOSE to this. Are you sure you didn't do something like go through an old Sony manual and cut/paste words until you came up with something sensational in an attempt to raise levels of anger?

What I did see in my search of this thread was:

"We are working with CineForm on addressing the slow playback in Half and Quarter size resolutions. - from Forum Admin.

And:

"For what it's worth, after installing Vegas v9-32 it wasn't seeing the Cineform codec from my Neo Scene installation. I reinstalled Neo Scene and everything is fine now." - From John Cline

The reference article did not paste well.

The issue of Cineform "preview" in vegas MAY be related to a buffer management issue, which MS has been patching the OS over the last couple of years. MS now is officially removing a number of APIs that number vendors have used in their apps. Since vegas is a new compiled app while Cineform appears to be have an older compiled date; the buffer management calls and parameters in vegas may not align with Cineform.

It seems that some individuals would prefer to accuse SCS of evil behaviour or second-guess SCS performance using poor or weak market examples, apples and oranges. ;-) While everyone can have an opinion, it seems that SCS is guilty of war crimes in the business market and its a moral crime to point out the problem maybe more complex and not directly SCS fault. It's possible that Cineform and SCS are playing catchup in comparability. Cineform has been a good company about responding to issues and I'm sure they will fix their issues if needed. They just need a little time and data.