Trond Lossius

I've downloaded and installed the MaxMSP and Jitter SDK for Windows. They are both installed at default location.

Furthermore I've installed the free Microsoft Visual Studio 2005. Here's additional info from the About window:

Version 8.0.50727.42 (RTM.050727-4200) Microsoft .NET Framework Version 2.0.50727 Installed Edition: VC Express

Microsoft Visual C++ 2005 76542-000-0000011-00125

When opening plussz.dsp and attempting to compile build using either Build Solution or Build plussz, I'm getting nthe following error message:

c:maxmspsdkc74supportmax-includesext_prefix.h(117) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory

I've search through my disk for windows.h, and the only file named thus is part of cygwin.

So I'm wondering: Is there a file missing in the SDK, am I missing something obvious, or is it impossible to compile using MS Visual C++ Express Edition?

Version 8.0.50727.42  (RTM.050727-4200) Microsoft .NET Framework Version 2.0.50727 Installed Edition: VC Express

Microsoft Visual C++ 2005   76542-000-0000011-00125
Microsoft Visual C++ 2005

windows-h-missing

it seems you are lacking the Windows Platform SDK.

Hi Trond,
it seems you are lacking the Windows Platform SDK.
obviously it's there: http://tinyurl.com/cew8e

I've downloaded and installed, and after having registered it with Visual C++and tweeking some of the Tools>Options>VC++ Directories pretending to know what I'm doing (I'm not) I've managed to compile plussz. I've tested it according to the help file in Max, and it seems to work OK. Still I got 4 warnings while doing so (3 of them are the same, and relate to sprintf). Should I be concerned about the warnings, or or are they mostly harmless?

.plussz.c(84) : warning C4996: 'sprintf' was declared deprecated

C:Program FilesMicrosoft Visual Studio 8VCincludestdio.h(345) : see declaration of 'sprintf'

Message: 'This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.'

.plussz.c(88) : warning C4996: 'sprintf' was declared deprecated

.plussz.c(91) : warning C4996: 'sprintf' was declared deprecated

Creating library .Release/plussz.lib and object .Release/plussz.exp

plussz.exp : warning LNK4070: /OUT:plussz.dll directive in .EXP differs from output filename '../win-output-release/plussz.mxe'; ignoring directive

Build log was saved at "file://c:maxmspsdkmax-projects1. plusszReleaseBuildLog.htm"

========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Compiling...
plussz.c
.plussz.c(84) : warning C4996: 'sprintf' was declared deprecated
        C:Program FilesMicrosoft Visual Studio 8VCincludestdio.h(345) : see declaration of 'sprintf'
        Message: 'This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.'
.plussz.c(88) : warning C4996: 'sprintf' was declared deprecated
        C:Program FilesMicrosoft Visual Studio 8VCincludestdio.h(345) : see declaration of 'sprintf'
        Message: 'This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.'
.plussz.c(91) : warning C4996: 'sprintf' was declared deprecated
        C:Program FilesMicrosoft Visual Studio 8VCincludestdio.h(345) : see declaration of 'sprintf'
        Message: 'This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.'
Linking...
   Creating library .Release/plussz.lib and object .Release/plussz.exp
plussz.exp : warning LNK4070: /OUT:plussz.dll directive in .EXP differs from output filename '../win-output-release/plussz.mxe'; ignoring directive
Embedding manifest...
Build log was saved at "file://c:maxmspsdkmax-projects1. plusszReleaseBuildLog.htm"
plussz - 0 error(s), 4 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========


if you have always been able to live with the fact that sprintf can 

crash your program under some circumstances., you can likewise ignore 

Microsoft has made variations on a few standard c library functions 

that try to be safer (or more fool-proof).

Hi Trond,
if you have always been able to live with the fact that sprintf can 
crash your program under some circumstances., you can likewise ignore 
these warnings.
Microsoft has made variations on a few standard c library functions 
that try to be safer (or more fool-proof).

I've been struggling with Microsoft's deprecation of the Unix sprintf() 

family and some of the "recommended" alternatives.

AFAICT, the biggest danger in plain-vanilla sprintf(), (according to 

MSDN as I read it) is in internet-based apps that process user-entered 

strings. A determined hacker can, apparently, feed your app a string 

that will deliberately overrun buffers and, assuming the hacker knows 

enough about your app, insert viral material. Causing untold damage and 

destruction across great swathes of the Internet like a modern day 

These concerns, as real or unreal as they may be in, say, a 

database-backed Web app, are (IMHO) not really an issue for a 

Max/MSP/Jitter externals. But I don't claim to be a final authority on 

The issue that Thomas brings up is a real one: those buffer overruns 

can also crash your external. However, with some care and a bit of 

effort these should be almost completely avoidable. Some details from 

Cycling '74 might be helpful, however. For instance: I generally work 

with 256-byte string buffers (20 years of Mac programming have left 

their mark!). This might actually not be big enough for Max symbols: on 

another thread someone mentioned getting approx 2kB into a symbol's 

My question to DDZ or JKC (or anyone else who knows)... just how big 

are string buffers in Max? IE, what's the maximum string length I might 

On around Feb 23, 2006, at 13:45, Trond Lossius said something like:

> .plussz.c(84) : warning C4996: 'sprintf' was declared deprecated

> C:Program FilesMicrosoft Visual Studio 

> 8VCincludestdio.h(345) : see declaration of 'sprintf'

> Message: 'This function or variable may be unsafe. Consider 

> using sprintf_s instead. To disable deprecation, use 

> _CRT_SECURE_NO_DEPRECATE. See online help for details.'

| Litter Power & Litter Bundle for Jitter

pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building

http://www.dspaudio.com/software/software.html

I've been struggling with Microsoft's deprecation of the Unix sprintf() 
family and some of the "recommended" alternatives.

AFAICT, the biggest danger in plain-vanilla sprintf(), (according to 
MSDN as I read it) is in internet-based apps that process user-entered 
strings. A determined hacker can, apparently, feed your app a string 
that will deliberately overrun buffers and, assuming the hacker knows 
enough about your app, insert viral material. Causing untold damage and 
destruction across great swathes of the Internet like a modern day 
Billy the Mountain.

These concerns, as real or unreal as they may be in, say, a 
database-backed Web app, are (IMHO) not really an issue for a 
Max/MSP/Jitter externals. But I don't claim to be a final authority on 
this.

The issue that Thomas brings up is a real one: those buffer overruns 
can also crash your external. However, with some care and a bit of 
effort these should be almost completely avoidable. Some details from 
Cycling '74 might be helpful, however. For instance: I generally work 
with 256-byte string buffers (20 years of Mac programming have left 
their mark!). This might actually not be big enough for Max symbols: on 
another thread someone mentioned getting approx 2kB into a symbol's 
s_name member.

My question to DDZ or JKC (or anyone else who knows)... just how big 
are string buffers in Max? IE, what's the maximum string length I might 
have to deal with in a symptr->s_name?

On around Feb 23, 2006, at 13:45, Trond Lossius said something like:
> .plussz.c(84) : warning C4996: 'sprintf' was declared deprecated
>         C:Program FilesMicrosoft Visual Studio 
> 8VCincludestdio.h(345) : see declaration of 'sprintf'
>         Message: 'This function or variable may be unsafe. Consider 
> using sprintf_s instead. To disable deprecation, use 
> _CRT_SECURE_NO_DEPRECATE. See online help for details.'

On 23 Feb 2006, at 15:09, Peter Castine wrote:

> AFAICT, the biggest danger in plain-vanilla sprintf(), (according 

> to MSDN as I read it) is in internet-based apps that process user- 

sprintf() takes a string buffer as first argument, uses the second 

argument as a format specification, and formats all the following 

arguments into the buffer. It doesn't know how big the buffer is, and 

has no idea whether or not the buffer is going to overflow as a 

This should be filed under "gobsmackingly stupid design." It's always 

been stupid, ever since it was first implemented circa 1970. It's 

even more stupid with the emergence of the web and public-facing 

servers reachable by anyone, anywhere in the world. Needless to say, 

if you're writing software for public consumption it's still a 

problem, whether Max/MSP is the delivery platform or not.

sprintf() should not be used in software unless you are absolutely 

sure what range and format of values will be passed to it. 

Pragmatically, this means it should not be used, period. IMHO, of 

(Having said that, I don't know whether Max/MSP's sprintf() object, 

as opposed to the C function sprintf(), does any kind of range 

checking. Since one is limited to Max/MSP values and symbols for the 

arguments, I've always assumed that it's capable of sanity-checking, 

and is in fact memory-safe, in the same way that pack, prepend and so 

on are. If it *is* possible to overflow, then it's violating Max/ 

MSP's semantic model and should be fixed.)

nick rothwell -- composition, systems, performance -- 

> AFAICT, the biggest danger in plain-vanilla sprintf(), (according  
> to MSDN as I read it) is in internet-based apps that process user- 
> entered strings.

sprintf() takes a string buffer as first argument, uses the second  
argument as a format specification, and formats all the following  
arguments into the buffer. It doesn't know how big the buffer is, and  
has no idea whether or not the buffer is going to overflow as a  
result of the operation.

This should be filed under "gobsmackingly stupid design." It's always  
been stupid, ever since it was first implemented circa 1970. It's  
even more stupid with the emergence of the web and public-facing  
servers reachable by anyone, anywhere in the world. Needless to say,  
if you're writing software for public consumption it's still a  
problem, whether Max/MSP is the delivery platform or not.

sprintf() should not be used in software unless you are absolutely  
sure what range and format of values will be passed to it.  
Pragmatically, this means it should not be used, period. IMHO, of  
course.

(Having said that, I don't know whether Max/MSP's sprintf() object,  
as opposed to the C function sprintf(), does any kind of range  
checking. Since one is limited to Max/MSP values and symbols for the  
arguments, I've always assumed that it's capable of sanity-checking,  
and is in fact memory-safe, in the same way that pack, prepend and so  
on are. If it *is* possible to overflow, then it's violating Max/ 
MSP's semantic model and should be fixed.)

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


On around Feb 23, 2006, at 15:44, Nick Rothwell said something like:

> This should be filed under "gobsmackingly stupid design."

Well, yes, I agree. It's only one of Unix' idiosyncracies that always 

left me wondering what Brian K. was on back in those days.

However, if you know what the longest size string a symbol can take, 

then it's perfectly possible, before you write something like

sprintf(recipStr, "%s-%s-%s", sp1->s_name, sp2->s_name, sp3->s_name);

It's a bit of a stack hog if kMaxSymNameLen is 2k, but so be it.

> Having said that, I don't know whether Max/MSP's sprintf() object, as 

> opposed to the C function sprintf(), does any kind of range checking.

Sais pas. I once asked, in another context, about range checking and 

pre-flighting in Max, and was basically told by a Very Important Person 

@C74 that I was a wuss and shouldn't be programming in C if I worried 

about stuff like that. (Maybe that's why they implemented mxj, just for 

So I tend to agree with your assessment, but I ain't takin' no bets on 

On around Feb 23, 2006, at 15:44, Nick Rothwell said something like:
> This should be filed under "gobsmackingly stupid design."

Well, yes, I agree. It's only one of Unix' idiosyncracies that always 
left me wondering what Brian K. was on back in those days.

However, if you know what the longest size string a symbol can take, 
then it's perfectly possible, before you write something like

   sprintf(recipStr, "%s-%s-%s", sp1->s_name, sp2->s_name, sp3->s_name);

> Having said that, I don't know whether Max/MSP's sprintf() object, as 
> opposed to the C function sprintf(), does any kind of range checking.

Sais pas. I once asked, in another context, about range checking and 
pre-flighting in Max, and was basically told by a Very Important Person 
@C74 that I was a wuss and shouldn't be programming in C if I worried 
about stuff like that. (Maybe that's why they implemented mxj, just for 
my benefit? Nah...)

So I tend to agree with your assessment, but I ain't takin' no bets on 
it.

Sorry to sneak into that topic, but there's something strange : Trond 

didn't had the Windows Platform SDK then windows.h was missing, but i 

DON'T have this SDK either, and my compiler never complained about 

windows.h. I've checked a project where it is needed (it's obviously 

included), and the only missing files are and ! 

How weird ?! Do i have a partial version of this SDK installed somewhere 

"en d?pit de mon plein gr?" ?! Do i have, like Trond, to download 

Windows Server 2003 SP1 Platform SDK too ??

Sorry to sneak into that topic, but there's something strange : Trond 
didn't had the Windows Platform SDK then windows.h was missing, but i 
DON'T have this SDK either, and my compiler never complained about 
windows.h. I've checked a project where it is needed (it's obviously 
included), and the only missing files are  and  ! 
How weird ?! Do i have a partial version of this SDK installed somewhere 
"en d?pit de mon plein gr?" ?! Do i have, like Trond, to download 
Windows Server 2003 SP1 Platform SDK too ??

I did in fact have a windows.h on my hard-disk, installed as part of 

cygwin while I was attempting to compile externals using Eclipse. But 

MS Visual Studio Express apparently was not able to make sense of or 

get access to that file, and I had to download the Windows Server 

2003 SP1 Platform SDK and hack some settings in order to be able to 

compile max externals using Visual Studio Express.

I never figured out how to properly remove CTD plugin and Cygwin 

tools so that I could reinstall and get Eclipse compiling to work 

properly. I got stuck in Eclipse when trying to build the empty C/C++ 

project, as I didn't get any Includes folder.

And while I'm on it, thanks for the help I got on the sprintf errors 

I did in fact have a windows.h on my hard-disk, installed as part of  
cygwin while I was attempting to compile externals using Eclipse. But  
MS Visual Studio Express apparently was not able to make sense of or  
get access to that file, and I had to download the Windows Server  
2003 SP1 Platform SDK and hack some settings in order to be able to  
compile max externals using Visual Studio Express.

I never figured out how to properly remove CTD plugin and Cygwin  
tools so that I could reinstall and get Eclipse compiling to work  
properly. I got stuck in Eclipse when trying to build the empty C/C++  
project, as I didn't get any Includes folder.

And while I'm on it, thanks for the help I got on the sprintf errors  
etc.

windows.h missing