windows.h missing

Feb 23, 2006 at 10:31am

windows.h missing

Hi,

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
Microsoft Visual C++ 2005

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?

Thanks,
Trond

#24576
Feb 23, 2006 at 11:06am

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

best greetings,
Thomas

#71334
Feb 23, 2006 at 12:45pm

Thanks, Thomas.

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?

Thanks once more,
Trond

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 ==========

#71335
Feb 23, 2006 at 12:53pm

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).

best greetings,
Thomas

#71336
Feb 23, 2006 at 2:09pm

Further to Thomas’ comments.

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.’

Mostly harmless. Greetings from Zaphod.

– P.

————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html

#71337
Feb 23, 2006 at 2:44pm

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-
> 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.)

– N.

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

#71338
Feb 23, 2006 at 3:28pm

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);

to say

char recipStr[3*kMaxSymNameLen + 3];

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
my benefit? Nah…)

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

– P.

————– http://www.bek.no/~pcastine/Litter/ ————–
Peter Castine | ^
| Litter Power & Litter Bundle for Jitter
pcastine@gmx.net |
pcastine@bek.no | iCE: Sequencing, Recording, and Interface Building
4-15@kagi.com | for Max/MSP
| Extremely cool
| http://www.dspaudio.com
| http://www.dspaudio.com/software/software.html

#71339
Feb 27, 2006 at 11:29am

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 ??

best

f.e

#71340
Feb 27, 2006 at 12:54pm

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.

Best,
Trond

#71341

You must be logged in to reply to this topic.