Why was Pinball removed from Windows Vista?

http://blogs.msdn.com/b/oldnewthing/archive/2012/12/18/10378851.aspx

by pavel_lishin • 14 years ago

271 142 14 years ago

blogs.msdn.com

moepstar• 14 years ago

Heh, 's nice to read about that and as a pinball-enthusiast i'm a bit saddened for it to be gone, even if it is more for retro-reasons as opposed to it being special in some way...

Maybe MS should team up with someone who understands making (digital) pinballs, like the guys that created Zen Pinball?

streptomycin3• 14 years ago

Too bad it wasn't open source, then someone would have fixed it for free.

MatthewPhillips• 14 years ago

Someone asked that in the comments, and he responded that it was licensed from a 3rd party company.

ben0x539• 14 years ago

Take the argument a step further: Microsoft "should" have required the 3rd party to provide the code under an open-source license.

crpatino2• 14 years ago

Assuming you are not just trolling, please elaborate.

streptomycin3• 14 years ago

Elaborate on what? It seems rather obvious that a popular game with a minor bug rendering it unplayable would have that bug fixed by someone for free if it was open source.

Or do you want me to elaborate on why it's too bad? Well, pinball is the best game that was ever included with Windows, so it's unfortunate that it's not still there.

prezjordan• 14 years ago

Not Microsoft's jurisdiction, unfortunately. They license those games from dev shops.

I am surprised, however, that it hasn't been cloned yet.

LeonimuZ• 14 years ago

It was licensed from MAXIS; I don't think EA will release the source any time soon.

ww5205• 14 years ago

There are plenty of open source pinball games. Why can't people just download them?

amorphid• 14 years ago

Nostalgia.

randomdrake4• 14 years ago

This is an excellent example of why comments in code are so very useful, helpful and in my opinion, necessary.

... nobody at Microsoft ever understood how the code worked (much less still understood it), and that most of the code was completely uncommented, we simply couldn't figure out why the collision detector was not working. Heck, we couldn't even find the collision detector!

To all those folks out there who keep finding reasons to try and be clever with their language, or omit comments from their code: now you can remember Pinball. It's very possible that with some minimal commenting about what functions did, or what the intentions of block of codes were, Pinball could have lived on. Heck, we could have even seen a Modern UI version of Pinball.

mikeash3• 14 years ago

It's an argument for clear code that's readily understandable by other people. It's not an argument for any particular technique for achieving that goal. I've never seen any programmer seriously suggest that code should be deliberately made difficult to understand.

mgkimsal3• 14 years ago

"I've never seen any programmer seriously suggest that code should be deliberately made difficult to understand."

Then you've not worked with some of the people I've worked with. The clever "it was hard to write, it should be hard to read" mantra has been thrown out by a few ex-colleagues trying to be clever, and a couple of them really meant it. Whether it was a hatred for others, or a misguided attempt at "job security", I'll never know, but some of these people do exist.

Often, however, the same effect is had under the guise of "clever hacks" - look how clever and awesome I am! What? Of course everyone else can read and understand this (they just have to understand that I compiled this with my own custom-built compiler I rolled myself on gentoo so I could squeeze out an extra .0001% improvement!)

hoka• 14 years ago

yeah, +1. In this religious war, I side with "if anyone who has a reasonable level of competence with my code can't grasp it at first reach, I have failed in writing it."

Or, famously, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." --Brian Kernighan

stephengillie• 14 years ago

Respectfully, commenting code and making it easily readable don't usually add to the bottom line. So while we all miss playing Pinball, it would be a waste of money to the shareholders.

This game was another casualty of maximizing value towards shareholders and away from all other stakeholders.

h2s2• 14 years ago

I can't agree with you emphatically enough about this. Cargo cult commenting is one of the easiest ways to damage the readability of a codebase.

Comments should be an edge-case solution for explaining unusual quirks, not the go-to approach for explaining the entire codebase. Using comments to explain what the code is up to is like using exceptions for flow of control. A large proportion of the comments I see should actually be function or method names for a more well factored version of the block of code that follows.

randomdrake4• 14 years ago

I haven't heard the argument about making code deliberately hard to understand either.

I agree that clearer code and/or commenting would have been suitable.

I only latched on to the example because they specifically mentioned that the code wasn't commented. In this case, a few lines of comments might have helped them find what they were looking for. Even if they original programmer was one of those people who just can't stop writing code like:

  $a = ($b)?($ab):$c;
  d($a);

Maybe some amount of convincing could lead them to leave a comment every once in a while so we can at least get:

  // Detect collision
  $a = ($b)?($ab):$c;
  d($a);

Since it seems like both clear code and comments were absent, either one would have been helpful.

klibertp• 14 years ago

What other technique do you have at your disposal in a code originally written in assembly and then translated to C, and then refactored several times without rewrite?

I personally didn't hear of one that would be usable in this case.

Also, I'm starting to think I should write a script to cut out every comment here that has "code" and "comments" in it - among with several other phrases that signify neverending debates.

joezydeco• 14 years ago

This is also a great example of what happens during acquisitions.

Space Cadet was developed by Cinematronics (apparently no connection to the classic arcade game manufacturer) and published by Maxis. Maxis eventually bought Cinematronics. Then (according to Wikipedia) "The studio was closed and the employees were laid off when Maxis was acquired by Electronic Arts in 1997."

So someone out there knows how to fix it. I bet Microsoft called EA looking for a quick/free fix, EA called the employee (or lost track of them, more likely), and the employee told them to stick it.

TeMPOraL• 14 years ago

There is no reason not to "be clever with your language", as long as you separate the "cleverness" behind a clear interface.

bunderbunder6• 14 years ago

There are some readability problems that stem from a lack of comments, and there are other readability problems that stem from exceedingly poorly-written code.

Heck, we couldn't even find the collision detector!

This sentence tells me that the big problem here comes from the latter, much worse, source of of readability problems. The fact that they couldn't find the collision detector implies that the code had no class named CollisionDetector, no procedure named DetectCollisions, nothing of the sort. Which implies (if not conclusively) that there was a whole lot spaghetti code floating around in there. Or at least a whole lot of very poorly-factored code.

I do think that comments are an important part of making code readable and maintainable. But comments are there to handle less drastic readability concerns. Documenting what units a parameter should be in, for example, or saying, "The following code implements X algorithm with Y and Z optimizations applied." Comments should never just be a substitute for using language-level code organizational and structuring constructs to organize and structure one's code.

viraptor• 14 years ago

To me that fragment says that the story is a bit more colourful than what really happened. This quote comes from Raymond Chen. The guy who includes ISA bus, interrupts and starting up a debugger in one post (http://blogs.msdn.com/b/oldnewthing/archive/2007/01/30/15574...); or analysing chip issues and software workarounds for them (http://blogs.msdn.com/b/oldnewthing/archive/2011/01/12/10114...).

Maybe the code was really messy and hard to work with... but it's hard to believe that he couldn't find the collision detector ;)

MartinCron• 14 years ago

The fact that they couldn't find the collision detector implies that the code had no class named CollisionDetector

The fact that it was written in assembly and then C makes a stronger implication that they had no class named CollisionDetector.

MichaelApproved• 14 years ago

This is an excellent example of why comments and well documented code should be part of the licensing agreement.

eps2• 14 years ago

If they weren't able to find the collision detector, I seriously doubt the comments would've been of a usable quality.

recycleme• 14 years ago

//Collision detector logic starts here

^That might have helped a little.

kamjam• 14 years ago

I read that comment and immediately thought of this HN post and why i disagreed with everything in that article.

http://news.ycombinator.com/item?id=4934417

augustl• 14 years ago

I usually argue that version control history is often as useful as code comments. In this case, though, I suppose comments would have been better than some arcane 15 year old VCS :)

shabble2• 14 years ago

I'm pretty sure I saw a library somewhere that could be purchased in both "raw code" and "commented, documented code" forms.

Which I can only assume meant they had the comments/documents and were intentionally stripping them out for the cheaper version. The difference in price was also actually quite significant as well, as I recall.

That, along with the fact that the person doing the purchasing is not necessarily the person who would be using the product, makes this IMO a particularly nasty sales tactic.

I've also heard war stories from Big Company folks about contracting out for a large software project, and per contract receiving the full source for the app, but none of the (particularly convoluted) build scripts or Makefiles.

Lessons Learned are why BigCo has a 900 page specification document including glossary of what the word "means" means.

dfox3• 14 years ago

Comments under the article seem to imply that most of the relevant code was somehow hand converted from (probably well commented) assembly to C which I only assume was done by someone who had no interest in how or why the code actually works, which seems to perfectly explain the lack of comments (or meaningful structure for that matter).

crescentfresh• 14 years ago

Wait, can't 64-bit windows run 32-bit programs?

zspade• 14 years ago

same question was asked and answered in the comments of the original article.

missing_cipher• 14 years ago

Answer is in the article:

[That would have been even more work, because there was at the time no infrastructure in Setup for having 32-bit-only components. (And then automatically uninstalling it when WOW64 was disabled.) And besides, all the people who criticized Windows 96 as "not really a 32-bit operating system because it has some parts in 16-bit" would use the same logic to say that 64-bit Windows is "not really a 64-bit operating system." -Raymond]

chimeracoder• 14 years ago

Man, if that's the case, does using a BIOS mean I'm still running a 16-bit operating system?

If so, then I guess I've got to marvel at how popular "16-bit" Linux is - I can run 64-bit only applications, watch Flash, Netflix... whoever knew a 16-bit OS could be so powerful!

dmlorenzetti• 14 years ago

http://software.intel.com/en-us/articles/collection-of-examp...

bunderbunder6• 14 years ago

Yup. All you've got to do is copy it over from a Windows XP machine, if you have one laying around.

Aside from the explanation others have quoted, I'm guessing some of it was also an aesthetic decision. They could probably still go and bring it back using WOW64, but it still looks like a Win95-era program, whereas all the other games have been replaced with better-looking rewrites. That and I think it only supports a resolution of 640x480.

tolos• 14 years ago

argh

> The source code was licensed from another company. If you want the source code, you have to go ask them.

Twice this mystery company is referenced, but never a name is mentioned.

bunderbunder6• 14 years ago

Google to the rescue!

http://en.wikipedia.org/wiki/Full_Tilt!_Pinball

barbs2• 14 years ago

Look for Danny Thorpe's comments, he mentions that it was created by a company called "Cinematronics", which was later acquired by Maxis, which was then acquired by EA.

isabre• 14 years ago

I used to play Pinball at school whenever I was in the Computer Lab. I also spent the bulk of my time in the computer lab at recess. Brings back old memories.

cjensen4• 14 years ago

To me, the lesson is: Do not duplicate code! and keep it simple stupid

When implementing Unicode, MS said "hey let's copy all of our API functions to new names". Now they have two problems.

When implementing 64-bit, MS said "hey let's have a completely different OS for 64-bit." Now they have four problems.

Compare this to Unix/Linux/MacOS where Unicode is just implemented as a standard way (UTF-8) of encoding characters into the existing API. And there need only be one shipping OS which supports both 32-bit and 64-bit process types equally since there are only a handful of kernel APIs compared to thousands for Windows.

barrkel• 14 years ago

MS implemented NT, which only worked in Unicode. They had to add a compatibility layer to run Ansi apps.

Which is MS's separate OS for 64-bit?

OS APIs are distinct from kernel APIs. You're comparing a kernel (Linux) with a distribution (Windows).

eridius3• 14 years ago

Which is MS's separate OS for 64-bit?

I believe you'll find it to be Windows <insert version here> 64-bit Edition.

A quick googling suggests that Windows 7 retail copies have both 32-bit and 64-bit editions, but I'm guessing you still have to pick the right edition when you go to install it. And if you don't have a retail disc, then you probably only got one of the two architectures.

Compare this with Mac OS X, where there is no "32-bit edition" or "64-bit edition", there is just "Mac OS X". Everybody installs the same OS, and it transparently works for both 32-bit and 64-bit machines. The only time when you really have to care is if you're installing a 3rd-party kext (kernel extension), as 32-bit kexts won't work on a 64-bit kernel, but that's pretty rare and any kext that's still being maintained today will support both architectures.

kvb• 14 years ago

What are the consequences of your preferred approach for legacy code? While there are certainly disadvantages of duplicating APIs in terms of cruft, I think that many customers appreciate that old code continues to run (and compile) against newer versions of the OS.

wvenable3• 14 years ago

Windows unicode support predates the existence of UTF-8 -- so that's great API design for Windows if you possess a time machine.

The ANSI functions merely map to the unicode functions.

In addition, the Windows Kernel is probably similar in API size to the Linux kernel. Of course, that's not nearly enough API for a complete Windowing operating system in either case.

cjensen4• 14 years ago

The point is both Unix and Windows faced the exact same problem: needing to support larger characters. MS thought little and unleashed their army of coders to do something foolish. The Unix guys thought hard and did something elegant and sensible.

ww5205• 14 years ago

Confusing the Linux kernel service API and the OS API is pretty misleading.

dfox3• 14 years ago

Even when you look at syscalls themselves there is difference: Linux kernel deals with mostly opague strings of bytes (that are today by user-space side convention mostly utf-8) while NT kernel deals mostly with UCS-2 unicode codepoint strings (that are sometimes UTF-16 and this way madness ensues).

cjensen4• 14 years ago

Nope. Windows does not distinguish between a kernel APIs versus other APIs. They are all "The Win{32,64} API"

correctifier• 14 years ago

There is a great deal of both misunderstanding and ignorant Microsoft bashing in this comment.

First of all, you are mixing up two completely different concepts.

For character encoding on Windows: For many functions in the Windows API there two versions of a function, one with an A (for ANSI) at the end and one with a W (for wide). This was added to make it easier to support Win32 on both Windows 95, which used 8-bit characters and codepages and Windows NT which was natively utf-16 unicode. At the time utf-16 was considered the best and most standard choice for supporting unicode. In most cases it is implemented as W function with an A function that is little more than a wrapper.

This has nothing to do with what Raymond is describing.

For the 64-32 bit stuff they ensured that all code would compile and work correctly with both 32/64 bit stuff and built two versions, one for ia32 and one for amd64. The kernel would have to be modified to support the amd64 architecture. This is exactly what Linux, OSX and other operating systems that support multiple architectures do. On top of this, because amd64 supports backwards compatibility, they also included an ia32 environment with it as well, but this is optional, so anything that ships with the OS cannot depend on it. I assume this is what OSX does too, the only difference is that with Windows the two versions ship as different SKAs, and MacOSX ships with both versions and installs the one that the computer originally shipped with.

Second, the number of system calls has nothing do with any of this at all.

shmageggy3• 14 years ago

The best part of this article is in the comments. An original programmer on the game explains the reason that the bug was occurring and also why the code was unreadable (hint: they did it in assembly)

Ah, the quantum tunneling pinball!

We ran into this while writing the original code at Cinematronics in 1994. Since the ball motion, physics, and coordinates were all in floating point, and the ball is constantly being pushed "down" the sloped table by the gravity vector in every frame, we found that floating point error would gradually accumulate until the ball's position was suddenly on the other side of the barrier!

(To simplify collision detection, the ball was reduced to a single point/vector and all barriers were inflated by the ball radius. So, if the mathematical point got too "close" to the mathematical line barrier, a tiny amount of floating point rounding or truncation error could push the point to the other side of the line)

To mitigate that, we added a tiny amount of extra bounce to push the ball away from the barrier when it was nearly at rest, to keep the floating point error accumulation at bay. This became known as the Brownian Motion solution.

Since much of the original code was written in x86 asm to hand tailor Pentium U/V pipelines and interleave FPU instructions, but wiki says Microsoft ported the code to C for non-Intel platforms, I'm sure the code had passed through many hands by the time it got to you. The Brownian Motion solution may have been refactored into oblivion.

http://blogs.msdn.com/b/oldnewthing/archive/2012/12/18/10378...

Evgeny• 14 years ago

I'm so happy you posted that - otherwise I would not read down more than a couple first comments and would miss this!

shmageggy3• 14 years ago

My procrastination from studying for finals says "you're welcome"

bcoates• 14 years ago

Maybe the reason the Brownian motion stopped working was a shift from 80-bit x87 intermediaries to 64-bit SSE in x64, and the removal of long double support from MSVC.

yuhong6• 14 years ago

And I think ia64 has yet another different 82-bit floating point architecture that is supposed to be compatible with x87.

rm999• 14 years ago

I was surprised to see that microsoft paid very little to license the game, and even originally tried charging companies to include games.

sageikosa• 14 years ago

So all it needs it a really good cup of tea.

hakaaak• 14 years ago

...to power the Infinite Improbability Drive.

ajuc• 14 years ago

I've had similiar problem in one of my first games (scrolling shooter with asteroid physic, hobby project in TP7 and mode 13h), and I solved it in similiar way (when objects bounced off the obstacle I added constant to response vector length, so that ship always bounced with velocity so big, that even with gravity added, and when player rotated towards the obstacle and engaged engine, it would still move out of the obstacle in next frame).

It looked a little funny, cause when you left the ship to itself, it bounced in a place to half its height and back forever.

To mitigate this I've added 2 kinds of obstacles - most of the terrain was filled with obstacles with spikes, that did damage on each collision, so players won't test my collision response too much :) There were some obstacles without spikes, and you could forever bounce on them, but they were rare, and I marked them as "landing places". I think that added to gameplay.

Then I've added buttons that trigger doors to open/close, and in a few levels I've just placed some ship with no ai attached over the button. Effect - ship bounced forever, so the doors connected to the button opened and closed repeatedly ;) Player could also influence that by pushing the triggering ship away :)

It's funny how constraints of game engine can guide you into gameplay elements that you wouldn't consider without them.

EDIT: the game if anyone is interested: http://ajuc.ninja.umcs.pl/programy/gry/hw/download/hw.tar.gz it's in Polish, sorry, and coding style is outrageus

narag• 14 years ago

As a matter of fact, there is still a quantum tunnel bug. If you push and release the flippers too fast, the ball goes through them. Not a big deal unless you want to control the ball the same fine-tuned way as with real machines.

BTW, it works OK with Windows 7 (64), just copying it from an old installation. I like the game... 170M :-)

zwieback• 14 years ago

I have a virtual machine running XP for testing installers of internal tools (many engineers at HP are still running XP).

Just played a round of pinball. Despite having used Windows since 2.0, I didn't even know Pinball existed before.

forgotAgain• 14 years ago

So now we know how insecure XP was (is).

barbs2• 14 years ago

Apparently, you can just copy the folder across to an installation of the later versions of windows and it's "fully functional"

http://mspinball.weebly.com/

I can't try this right now, since I don't currently have access to a Windows machine, but can anyone confirm/deny this? Do you get the floating-point gravity bug?

shrikant• 14 years ago

I'm on 32-bit Windows 7, and it works fine. The plunger is a little sluggish to respond, but otherwise no sign of the gravity bug!

StavrosK2• 14 years ago

64-bit Ubuntu works fine, too. The ball disappears in some frames, but it's no thing.

Wingman4l7• 14 years ago

Another good comment that's buried near the bottom, written by one of the authors of the game, regarding the ownership of the code: http://blogs.msdn.com/b/oldnewthing/archive/2012/12/18/10378...

robomartin5• 14 years ago

> nobody at Microsoft ever understood how the code worked (much less still understood it), and that most of the code was completely uncommented, we simply couldn't figure out why the collision detector was not working. Heck, we couldn't even find the collision detector!

This continues to be one of my pet peeves, particularly with code samples and a lot of what is posted on Github, even major libraries. Almost no comments, background or guidance on the intent and structure or the code.

No, I am not suggesting that something like this is necessary:

    // Iterate through all elements 
    for(int i=0; i < count; i++
    {
        // Check that velocity isn't above threshold
        if(velocity[i] > THRESHOLD)
        {
         // Limit velocity
         velocity[i] = THRESHOLD;
         ...

That's ridiculous. However, something like this is useful:

    // Bounds-check velocities
    for(int i=0; i < count; i++
    {
        if(velocity[i] > THRESHOLD)
        {
         velocity[i] = THRESHOLD;
         ...

Anyhow, dumb example I pulled out of thin air.

I've heard some say "I just write self-documenting code". That's a myth but for the simplest of structures. Any non-trivial piece of work is far from being self-documenting. Code is self-documenting for the guy who wrote it. I guarantee you that anyone else reading it has to reconstruct a stack in their head to understand what the hell is going on. That's not self-documentation. I shouldn't have to think to understand what a chunk-o-code is doing. The same for functions and/or methods.

The myth of self-documenting code is easy to demonstrate if I show you a piece of code in a language you don't know. I am going to assume that most programmers these days don't know assembler, Forth or Lisp.

    (defun GetPolylineEndEntities ( plename / plends cvcenter cvsize oldcmdecho pt1 pt2 endss outlist)
        (setq plends (GetPolylineEnds plename))
        (setq cvcenter (getvar "viewctr")
            cvsize   (getvar "viewsize")
            oldcmdecho (getvar "CMDECHO")
        )    
        (setvar "CMDECHO" 0)

        (foreach point plends
         (progn
            (setq pt1 (add2d point '(-0.0125 -0.0125)))
            (setq pt2 (add2d pt1 '(0.025 0.025)))
            (command "zoom" "c" point 2)
            (setq endss (ssdel plename (ssget "C" pt2 pt1)))
            (setq outlist (append outlist (list (ssname endss 0))))
         )
        )
        (command "zoom" "c" cvcenter cvsize)
        (setvar "CMDECHO" oldcmdecho)
        outlist
    )

I wrote this twenty years ago. Even if you understand Lisp you'd have to think it through. However, this is not how I wrote it. This is what I actually wrote:

    ;=====================================================================================================
    ; GetPolylineEndEntities
    ;
    ; Argument: Polyline entity name
    ; Return: Two element list containing the first (if any) entity found at the end of the polyline.
    ;         The polyline itself is excluded.
    ;         If nothing is found at a particular end, that element in the list is set to nil.
    ;
    (defun GetPolylineEndEntities ( plename / plends cvcenter cvsize oldcmdecho pt1 pt2 endss outlist)
        (setq plends (GetPolylineEnds plename))    ;Get the endpoints

        (setq cvcenter (getvar "viewctr")
            cvsize   (getvar "viewsize")
            oldcmdecho (getvar "CMDECHO")
        )    
        (setvar "CMDECHO" 0)

        (foreach point plends
         (progn
            ;Examine what connects at each end
            (setq pt1 (add2d point '(-0.0125 -0.0125)))
            (setq pt2 (add2d pt1 '(0.025 0.025)))

            ;Zoom to the end being analyzed to have better selection accuracy
            ; **** Have to figure out a way to do this without zooming ****
            (command "zoom" "c" point 2)
        
            ;Eliminate the original cable from the resulting selection set
            (setq endss (ssdel plename (ssget "C" pt2 pt1)))

            ;Add the first entity found to the output list
            (setq outlist (append outlist (list (ssname endss 0))))
         )
        )
        (command "zoom" "c" cvcenter cvsize)
        (setvar "CMDECHO" oldcmdecho)
        outlist
    )

Even if you don't know Lisp you now have an idea of what this code is doing. My style has changed over the years. This isn't my best example, but it is here to drive a point home.

The use of an unfamiliar language serves to illustrate the point that the idea of self-documenting code is, again, a myth. I wrote that code myself and without the comments I'd have to mentally reconstruct every step to even begin to understand what's going on and what the intent was. I haven't touched Lisp in quite some time.

I've looked through so much code in Github without a single comment that it makes me wonder if this is what is being taught in schools these days. Accurate in-code documentation is, as far as I am concerned, part and parcel of becoming a professional programmer. It recognizes that the work represents a huge investment in time, money and intellectual effort and it ensures that this effort and expense doesn't have to be duplicated in order to maintain, evolve or migrate the product as the Microsoft example clearly demonstrates.

robomartin5• 14 years ago

Assembler makes the point even more apparent:

    MSG_LOOP_PostMessage:
        mov     a, MSG_Head    
        cjne    a, #MSG_BUFFER_END - 2, mlpm0
        mov     a, #MSG_BUFFER
        sjmp    mlpm1
    mlpm0:
        inc     a
        inc     a
    mlpm1:
        cjne    a, MSG_Tail, mlpm2
        clr     a
        ret
    mlpm2:
        mov     r0, MSG_Head
        mov     @r0, MSG_Code
        inc     r0
        mov     @r0, MSG_Parameter
        mov     MSG_Head, a
        mov     a, #1
        ret

I wrote that about fifteen years ago. Of course, the routine's label tells you something: "MSG_LOOP_PostMessage". It must post a message to a message buffer. The rest is giberish. What's the intent behind each and every block of code? Well, of course, that's not how I wrote it. This is what I wrote:

    ; POST MESSAGE --------------------------------------------------------------------------
    ; This routine posts a new message to the message loop buffer.
    ;
    ; The message code and parameter are written to the buffer only if buffer space is
    ; available.  This is determined by first looking at the difference between the
    ; head and tail pointers.  By design, we sacrifice one set of locations (two 
    ; bytes) in the buffer in order to create a gap between an advancing head pointer and
    ; a lagging tail pointer.  If a lot of messages are issued and not processed immediately
    ; the head pointer will quickly wrap around and threaten to collide with the tail
    ; pointer.  By sacrificing a set of locations we avoid having to keep a counter of
    ; unprocessed messages.  This, because there would be ambiguity when both head and
    ; tail pointers point to the same location: it could mean that there are no messages
    ; to process or that there's a buffer full of messages to process.  The two byte
    ; gap we are imposing between head and tail removes this ambiguity and makes it easy
    ; to determine the buffer empty and full conditions.
    ;
    ; If there's space for a new message it is stored and the head pointer advanced to
    ; the next available location.  However, if no space remains, the message is discarded
    ; and the head pointer will remain one message (two bytes) away from the tail pointer.
    ;
    ; Arguments
    ; ----------------------------
    ; MSG_Head                Message buffer head pointer
    ; MSG_Tail                Message buffer tail pointer
    ; MSG_Code                Message code
    ; MSG_Parameter        Message parameter
    ;
    ; Return
    ; ----------------------------
    ; ACC =  0 -> Message did not post
    ; ACC <> 0 -> Message posted
    ;
    ; Modified
    ; ----------------------------
    ; MSG_Head
    ; ACC, R0
    ;
    ; Preserved
    ; ----------------------------
    ; MSG_Tail
    ; MSG_Code
    ; MSG_Parameter
    ;
    MSG_LOOP_PostMessage:
        mov      a, MSG_Head                    ;Increment the head pointer by one message
        cjne     a, #MSG_BUFFER_END - 2, mlpm0  ;and parameter.
        mov      a, #MSG_BUFFER                 ;Need to wrap around.
        sjmp     mlpm1                          ;
    mlpm0:                                      ;
        inc      a                              ;No need to wrap around, just increment.
        inc      a                              ;
    mlpm1:
        cjne     a, MSG_Tail, mlpm2             ;Check for a buffer full condition.
        clr      a                              ;Flag that we did not post the message.
        ret                                     ;Exit if it is.
    mlpm2:
        ;The buffer isn't full, we can store the new message
        mov      r0, MSG_Head                   ;Store message
        mov      @r0, MSG_Code
        inc      r0
        mov      @r0, MSG_Parameter             ;Store parameter
        
        ;Now set the head pointer to the next available message location.
        mov      MSG_Head, a                    ;The accumulator already has the next "head" location
                                                ;there's no need to execute the same logic again.
        mov      a, #1                          ;Flag that the message was posted
        ret                                     ;and exit

Now you don't have to know assembler to understand this code. A couple of years later I had to re-write this in C. It was incredibly easy to do because of the exhaustive in-code documentation. This is what came out:

    // POST MESSAGE --------------------------------------------------------------------------
    // This routine posts a new message to the message loop buffer.
    //
    // The message code and parameter are written to the buffer only if buffer space is
    // available.  This is determined by first looking at the difference between the
    // head and tail pointers.  By design, we sacrifice one set of locations (two 
    // bytes) in the buffer in order to create a gap between an advancing head pointer and
    // a lagging tail pointer.  If a lot of messages are issued and not processed immediately
    // the head pointer will quickly wrap around and threaten to collide with the tail
    // pointer.  By sacrificing a set of locations we avoid having to keep a counter of
    // unprocessed messages.  This, because there would be ambiguity when both head and
    // tail pointers point to the same location: it could mean that there are no messages
    // to process or that there's a buffer full of messages to process.  The two byte
    // gap we are imposing between head and tail removes this ambiguity and makes it easy
    // to determine the buffer empty and full conditions.
    //
    // If there's space for a new message it is stored and the head pointer advanced to
    // the next available location.  However, if no space remains, the message is discarded
    // and the head pointer will remain one message (two bytes) away from the tail pointer.
    //
    //
    // Return
    // ----------------------------
    // 0 = Message did not post
    // 1 = Message posted
    //
    // 
    U8 msg_loop_post_message(U8 message, U16 parameter)
    {
        if(msg_loop.count == MESSAGE_LOOP_SIZE)
        {
            return(0);    // Can't post because buffer is full
        }
        else
        {
            msg_loop.item[msg_loop.head].message = message;      // Post message
            msg_loop.item[msg_loop.head].parameter = parameter;  //
            msg_loop.count++;                                    // Update message count

            if( msg_loop.head == (MESSAGE_LOOP_SIZE - 1))        // Wrap around?
            {
                msg_loop.head = 0;                               // Yes.
            }
            else
            {
                msg_loop.head++;                                 // No
            }
            return(1);
        }
    }

Dylan16807• 14 years ago

This code is definitely readable, but I feel like the port from assember to C might have been too direct. Originally head was a pointer and it made sense to have conditional jumps, but in the C code head is an offset starting at 0. Why keep the entire if structure when you can simply have

  msg_loop.head = (msg_loop.head + 1) % MESSAGE_LOOP_SIZE  // Advance head and wrap

yxhuvud2• 14 years ago

>That's ridiculous. However, something like this is useful:

> // Bounds-check velocities

No, that is an example of a comment of a region that should have been a separate method/function.

robomartin5• 14 years ago

Not really.

If you throw methods and functions at everything all you are doing is adding the processing overhead of the entry and exit from the method or function. These are not magical entities. There's a time, a place and cost to using them.

Having come up from assembly and, in general, low level coding, one becomes very aware of what is being created behind the scenes. Unless something like this contrived bounds-check test will be used multiple times across a module or modules there's no reason whatsoever to add the overhead of entering and exiting a function for a simple couple of if/else-if/else statements.

I see this all the time. Everything has to be an object and everything has to be a class with a pile of properties and methods. No it doesn't. Massive projects --critical projects-- have been done over the years without any of that. Be careful not to engage in creating a monument to a coding paradigm rather than a tight, fast, practical and sensible solution to a problem.

shmerl• 14 years ago

They should include Xbill by default:

http://xbill.org

zaroth• 14 years ago

Apparently, someone has actually FIXED it and put it online. Although hard to know if the linked EXE isn't just a trojan. Anyone have a clean room they can test it in?

http://mspinball.weebly.com/index.html

See: http://blogs.msdn.com/b/oldnewthing/archive/2012/12/18/10378...

AndreyKarpov• 14 years ago

Perhaps it would help to quickly find bugs - http://www.viva64.com/en/viva64-tool/ :)

jfreak53• 14 years ago

Ahh gotta love Wine! Runs everything :) http://i.imgur.com/ekhiY.jpg

What ever you do DO NOT press F4 for fullscreen, it botches dual-monitors on Gnome. Took me 20 min. to get back up and running again.

BUT, Pinball works :)

Why was Pinball removed from Windows Vista?

Related Stories