Why do built-in JScript functions not appear in the typeinfo?

A reader sent me an email over the weekend asking about some odd behaviour in the guts of the JScript engine.  Unfortunately, they didn't include an email address that worked; I just got a bounce message back, Ben.  Therefore I'll just answer the question here.

To briefly describe the problem: the user fetches the JScript "Math" object from the script engine by calling ParseScriptText to evaluate the expression "Math". This returns an IDispatch object. The dispatch object can be queried for dispatch ids for "sin" and "cos" and all that. It can be successfully invoked. Everything appears to be good. But when the user calls GetTypeInfo, the type description structure says that the object has zero functions. What's up with that?

Clearly the typeinfo is out of step with reality. The user has in fact found two bugs. The first is that the typeinfo building code only adds to the typeinfo those functions which have already been dereferenced. So, had you called "sin" once already, "sin" would be added but nothing else.

However, the second bug trumps the first one; built-in functions are automatically skipped when adding function descriptions to the typeinfo. I'm not sure what I was thinking when I wrote that logic; it was a long time ago. So even if you have already dereferenced a built-in function object, it won't get added to the typeinfo.

User-defined functions should be always correctly added to the typeinfo; they are automatically dereferenced when they are created.

I wrote almost all the typelibrary code, and I regret the errors. However, it's unlikely that either of these flaws will ever be fixed, and clearly both would have to be fixed in order to make the given scenario work correctly. Both fixes would touch a lot of complex code and are therefore quite risky. We try to not apply risky fixes to fix a problem that, to my knowledge, only one person has ever noticed in the last seven or eight years!  If there's a massive outcry to make typeinfos for built-in objects work correctly, I'll pass that along to the sustaining engineering team; I wouldn't hold my breath waiting for a fix if I were you.

Thanks for bringing this to my attention.

Comments (14)
  1. Dave says:

    Was GetTypeInfo trying to implement the ECMAScript semantics that say builtin functions are not returned by the for..in operator? Yeah, that’s the ticket!

  2. Eric Lippert says:

    That might have had something to do with it, but if so, it’s not very good logic. The type info and the dispatch object should be consistent; that some propertys are DontEnum should not imply that they are omitted from the type info.

    More likely is that it was just a straightforward mistake. The scenario we were going for was a bunch of "macro" user-defined functions exposed to a host. So I implemented and tested the code to meet that scenario, and did not consider the more general applicability of the operation. That’s my best guess.

  3. Norman Diamond says:

    > We try to not apply risky fixes to fix a

    > problem that, to my knowledge, only one

    > person has ever noticed in the last seven or

    > eight years!

    Don’t count on that. What you have observed is that only one person reported it to you through your blog. There might have been thousands seven or eight years ago, who refused to pay Microsoft’s fees to report Microsoft’s bugs to Microsoft, who didn’t know how to slide one past them and e-mail you directly.

    For comparison, to the best of my knowledge only one person harps noisily about the amount of damage that Windows 95 did in destroying all files in SCSI disk partitions, but that doesn’t mean there was only one victim. In those days external SCSI disks were flying off the shelves of computer stores just as USB2 disks do now, and PCMCIA-SCSI interface cards were flying off the shelves. One vendor of PCMCIA-SCSI interface cards was aware of the brokenness of Windows 95 FDISK and they distributed their own formatter with it (but they aren’t the vendor of any of the cards I bought). Some other vendors gradually became aware of the problem and belatedly added similar tools, but some didn’t. How is it that Microsoft remained unaware? (And how is it that Windows 98 FDISK didn’t have the same disastrous bug, considering that Microsoft remained unaware of it in Windows 95?) No one paid your company’s fee to inform your company about it, but that sure doesn’t mean the number of victims was zero (or one).

  4. Eric Lippert says:

    > There might have been thousands seven or eight years ago, who didn’t know how to e-mail you directly.

    Presumably these thousands of people also did not post to newsgroups, which Peter Torr and I read religiously looking for exactly such problems. Presumably they also did not send email to the publically available "report a bug against scripting" email address. And presumably they didn’t go to msdn.microsoft.com/scripting, where they could read Andrew Clinick’s Scripting Clinic, and email him directly as well.

    We did our best to make it easy for people to report bugs to us.

  5. Fahd Khan says:

    Out of curiosity, what is the test suite for the scripting infrastructure like? It seems like a decent set of automated unit tests would make this sort of fix effortless.

    I agree that the bug is too trivial and the feature too rarely unused to bother with though. Plus I’ve heard what the MS validation team is like.

  6. mschaef says:

    "It seems like a decent set of automated unit tests would make this sort of fix effortless. "

    I think that getting "a decent set of automated unit tests" is quite difficult. I’m in the middle of writing such a suite for a small Scheme-like interpreter with limited external interfacing capabilities. Right now I’m at about 1000 test cases, and that’s a small fraction of what it’ll need to be to be comprehensive.

    As an example, take the (to-upper-case <x>) function. It takes a string and converts it to uppercase. Here’s what I’m looking for in my test suite for this function:

    * The input string isn’t changed

    * Upper case and non-alphabetic letters are left alone

    * Lower case letters are converted to their correct match

    * It handles the empty string

    * It correctly handles the first character of the string

    * It correctly handles the last character of the string

    * It handles very long strings

    At this point, I look at the code and write test cases for code paths I haven’t hit yet in my more functional testing.

    That’s one test script for one simple function out of over three hundered in my base library. I don’t handle internationalization, or fancy character sets, and I don’t have multiple string formats to test.

    I can’t even begin to imagine what a comprehensive test suite for JScript would look like. I’d be fascinated to find out more, though. I’m sure that Microsoft has the resources to develop a test system that boggles the mind.

  7. Eric Lippert says:


    Ha ha ha ha ha ha ha!

    Oh, wait, you’re serious.

    The script team testers developed several hundred thousand automated test cases which verify that the language and runtime behave as specified. We also have access to the IE team’s compatibility suite, which contains on the order of several million real-life web pages culled from the web over the last decade.

    However, we have almost no tests which test the script engines at the _COM interface_ level.

    We devoted our big-in-talent-few-in-number test team to verifying the behaviour of the part of the engines that affects hundreds of millions of end users: the language itself. The behaviour of the engines at the interface level is of interest to only those few people who develop custom hosts; there are hardly any tests that target specifically those interfaces. For all I know, there might be zero tests which test the type library generation behaviour.

  8. mschaef says:

    "The script team testers developed several hundred thousand automated test cases which verify that the language and runtime behave as specified."

    If this is propriatary, I understand, but I have a couple questions:

    * Do you target a 100% success rate?

    * When Microsoft develops script engine test cases, are you looking for code coverage, requirements coverage, or both? Are there seperate suites for code and requirenments coverage?

    * How do you test something like floating point addition? I assume that JScript floating point depends on the underlying library, so do you focus on the behavior of the JScript engine’s math code, or do you actually test the behavior of the underlying math logic?



  9. Eric Lippert says:

    Before a release goes out to the public we do a complete test pass — which takes a couple days — and investigate all failures and regressions. We are hard-core about not introducing accidental regressions in the language.

    Primarily we design the tests to cover the specified behaviour. However, at some point during the test case development process we do a coverage run to figure out whether there are large areas of untested code or not.

    I don’t know the details of our specific floating-point library tests, but there is a LOT of JScript-specific float logic in there, which must be tested. Clearly something as basic as addition is going to be done by the FPU, but stuff like converting floats to strings, etc, is all custom code.

  10. Eric Lippert says:

    One other test suite that I forgot to mention. We do language semantics testing, IE does compatibility testing, ASP does stress testing. The ASP team will run a web server doing a lot of JScript and VBScript under the system debugger. They stress the hell out of the machine, and then tell us about every caught and uncaught exception. Sometimes they’ll track contended critical sections as well. These tests help us keep the performance acceptable and look for crashing bugs under stress conditions.

  11. Norman Diamond says:

    12/6/2004 5:48 PM Eric Lippert

    >> There might have been thousands seven or

    >> eight years ago, who didn’t know how to

    >> e-mail you directly.


    > Presumably these thousands of people also

    > did not post to newsgroups, which Peter Torr

    > and I read religiously looking for exactly

    > such problems.

    Then you are right. Also I congratulate you and Mr. Torr for your dedication. Imagine how much different your company’s reputation could be if your colleagues on other products (e.g. Windows 95) had done the same.

  12. Norman Diamond says:

    By the way, again re. 12/6/2004 5:48 PM Eric Lippert

    > newsgroups, which Peter Torr and I read religiously

    Does that mean newsgroups that are hosted by Microsoft’s servers or Usenet newsgroups that are hosted by most ISPs? Most ISPs carry things like alt.os.windows-xp and carried comp.os.ms-windows.win95.moderated in its day, but I rarely saw postings from Microsoft. There were a lot of people whose corporate firewalls didn’t pass NNTP and/or for other reasons weren’t accustomed to Microsoft-hosted newsgroups, but had access to ordinary newsgroups. Which kind did you read?

  13. Eric Lippert says:

    I don’t remember the exact list — this was like five years ago — but pretty much every newsgroup that had "Javascript" in the title somewhere.

    One day I was reading the newsgroups and someone asked a really complicated question. I was going to answer it myself but then I though no, let’s wait and see if that hard-core guy in Australia answers it for me. And sure enough, he gave a more complete and cogent answer than I would have. So I sent him an email and asked if he wanted to work for us. Fortunately we managed to convince Peter to move from Australia to beautiful Redmond, and the world has never been the same since.

  14. ScottT says:

    Yeah, I was such a Peter fanboy back then. (well guess I still am. After he had gone to work for you, he asked and answered all sorts of crazy questions about how we all liked to try to break the script engines. I had written some crazy stuff, and had noticed this typeinfo anomole, but didn’t and probably still don’t know a good way to explain it. The main scripting tool that I use, that I wrote back then, still has that weirdness in it, that I can use the TLI.Typelibinfo activeX to get members of any running object as long as it wasn’t one of the built-in objects. I figured it was a limitation or deliberate and something I thought I could work around. Point is, I guess, that I don’t think I could have reported it, what I was doing seemed a miracle it worked anyway, so that small limitation didn’t seem a big deal. Wish you’d have been blogging like this back then. . .

Comments are closed.

Skip to main content