windows.h missing


    Feb 23 2006 | 10:31 am
    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

    • Feb 23 2006 | 11:06 am
      Hi Trond,
      it seems you are lacking the Windows Platform SDK.
      obviously it's there: http://tinyurl.com/cew8e
      best greetings,
      Thomas
    • Feb 23 2006 | 12:45 pm
      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 ==========
    • Feb 23 2006 | 12:53 pm
      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
    • Feb 23 2006 | 2:09 pm
      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
    • Feb 23 2006 | 2:44 pm
      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://
      www.cassiel.com
    • Feb 23 2006 | 3:28 pm
      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
    • Feb 27 2006 | 11:29 am
      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
    • Feb 27 2006 | 12:54 pm
      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