Why Effective Permissions Sometimes Aren't Correct

You may have noticed that Windows's "Effective Permissions" utility (somewhere in the Security tab on files) doesn't always report what permissions you have correctly, especially if you have local admin and not domain admin. This is due to a subtlety of SIDs.

A Security IDentifier (SID), uniquely (ding ding ding! there's the key) identifies a security principal - a user, group, or special claims-based thing like TrustedInstaller. Users on a domain each have a SID and that is unique across all computers. The Administrators group (for which most files have an ACL entry), however, is not specific to a domain or computer. Its SID is always S-1-5-32-544, whether it's the Administrators group on the domain (not the Domain Admins group), the Administrators group on the file server, or an Administrators group on some random client computer.

Suppose you're a local admin on your machine and therefore a member of S-1-5-32-544 on your computer. When you hand your impersonation token over to a file server and say "hey, I'm an admin, gimme this file!", it says "alright, let me check that", consults its impression of S-1-5-32-544 (because it has a group with that SID, of course), says "hey, you're not on that list!", and denies you access.

Your computer, on the other hand, sees the ACL entry for S-1-5-32-544, says "oh cool, you're a part of that, you can have all the access." The Effective Permissions utility does not ask the remote host; it only checks the SIDs on the ACL.

There might be other ACLs you can't see, like the ones in the mini-ACL editor you get when running the Advanced Sharing wizard. Those aren't on the file system like normal ACLs; they're extra restrictions processed by the LanMan service. You might also be subjected to restrictions for situation-based principals like Network (S-1-5-2), the faux-group of people who are remotely accessing the file.

Robotics - Moving Around

As I'm pretty used to by now, very few people came to today's robotics meeting! We did at least have an engineer, who was tinkering with a generic frame and trying to make do with our lack of relevant parts. (We have no axle hubs, not enough motors, not the right kind of wheels, a broken Samantha module, the wrong type of battery connector, and a poorly-functioning wire stripper.) While he worked with that, I oversaw the continued assembly of the field.

We got the kickstands and ball holding chambers set up yesterday. Today, we riveted the small wooden parts involved in the mount of the high center ball tube. We would have attached the tube and the guard/wrapper/thing around it, but for some reason the instructions call for that to be done with a stapler and we couldn't find one.

More interestingly, I continued work on the other team's tele-op program. I ran a test with buttons and tones to determine whether anything involved in the joystick was being sent to the robot - it was. I tried controlling motors with buttons - it worked, but there was insufficient traction on the wheels to move with only one wheel at once. After they fixed that, I tried controlling the motors again with the thumbsticks - it produced the same strange going-in-circles effect.

After a little bit of research (looking around in the example programs), I discovered that I not only have to call getJoystickSettings(joystick), but I have to use the "joy1_y1" and company members of default "joystick" variable. I had tried both of those things individually, but apparently never together. For some reason, the joy1Btn function works even if I don't call getJoystickSettings. Anyway, I hooked the thumbsticks up to the motors again and they were able to drive.

People were very excited, so I gave everybody in attendance a few minutes to drive the robot around. One managed to accidentally trip the kickstand, releasing a flood of balls, which was pretty exciting. Once everybody had their turn, I started implementing a virtual gearing system for precise controls. Unfortunately, their NXT ran out of battery power, so testing that will have to wait until next time.

Fix for RobotC 3.x Not Allowing WiFi Connections

I discovered a curious bug in the RobotC development environment today, at least in version 3.62. Sometimes, especially when the user running the IDE is not an administrator, WiFi connections to the robot will not work at all. What happens is that the robot search dropdown loses the WiFi options and the box for robots found via WiFi says something to the effect of "Searching for robots via WiFi is disabled."

I found one forum post that recommended checking the "Enable Wireless Searching for NXT" under Preferences under View. I tried that, but it did not do anything to solve the problem, even after a restart. It took me quite a while to figure out a real solution.

What you need to do is find an account where RobotC does do WiFi right and export the RobotC registry tree. This is found at HKCU\Software\Robot Academy. Open the Registry Editor by opening the Run dialog and launching "regedit". Expand the "HKEY_CURRENT_USER" folder, then Software, then just select "Robot Academy". Under File, use Export to save the selected tree to disk. If you have no environment in which RobotC behaves as expected, download my version of the registry tree.

Once you have acquired a working registry configuration, log into the user account for which it is not working and merge (import) the exported .reg file into your user registry (just double-click and OK any warnings). Launch RobotC and everything should be good.

Robotics - A Riveting Tale

Once again, very few people actually came to the robotics meeting. We still don't have a robot or materials necessary to make one do interesting things, so we just continued building the field. At a meeting which I could not attend last week, they found a drill and removed the incorrect rivets from the center field assembly pipes.

We installed the correct pipes today and started attaching the other Plexiglas side of the center assembly. The first rivet we put in, it didn't actually go through into the side of the structure - only into the Plexiglas - so we had to drill it out of the Plexiglas while being careful to not shatter it. Once we got longer rivets, the attachment went well.

I did a little bit more work on the RobotC program for the other team (which at least has a robot), but it still exhibits the strange problem of not getting the joystick movements.

Crushers - Polish That

I have been pretty stressed lately, and playing my old arcade-style game Crushers has been a really awesome way to relax. I consider it my best production, but it is currently in a state of half-brokenness because I ran out of time a few months ago while I was doing lots of updating/refactoring. With crosscountry done and another unit of communication class almost over, I want to use a little of my free time for a few days to polish Crushers.

Currently, it has a bug in which blocks are sometimes spawned not aligned to the usual 16x16 grid, which causes weird glitches, teleporting, and disappearance when they collide with another block. I have a pretty good idea of how to fix it, but it will take a little bit of time to go through the block spawning code (which needs a good refactor anyway).

Additionally, since I and pretty much everybody else have widescreen monitors (16:9 aspect ratio), there are blank black bars to the left and right of the Crushers game area. Adjusting the view properties to use a widescreen size will be trivial.

Some adjustments need to be made to the suffocation mechanic, like having the air particles track the player when he is in a 1-wide hole. It could also benefit from a dynamic grid of oxygen sources , but that's a pretty advanced programming thing.

The antigrav dimension could use some work, like being rebalanced to not be a guaranteed death trap. It could also be incentivized, maybe with some score bonuses for being in it or diminishing returns in the normal dimension.

I have other grand ideas, but for now I want to get bugs fixed and get the full v2.5 out.

Forgotten Windows Feature: Document Scraps

Up to Windows XP, there was an obscure little feature of the shell called "scraps." It is a system which, essentially, allows you to take an OLE object that supports dragging-and-dropping (and serialization) and place it in the file system as a file. These files, scraps, are even given special treatment kind of like shortcuts - extensions never seem to be shown for them (though they do have extension SHS).

They are usually generated from Microsoft Office products, by dragging selected text or objects out of the Office window and onto the desktop. They can then be dragged in later to a different document, or double-clicked like normal files to launch the owning application and paste the contents into the new window.

You can read the Microsoft KB article for the official information.

Robotics - Design Day

Today's robotics meeting did not involve a lot of robotics. Instead, we were in the upper school computer lab to work on the engineering notebook and T-shirt designs. I made a little more progress on the notebook; it is going slowly, though. The other designers dug up last year's shirt design and adapted it to have our names on it. This is good - I liked the old design.

We really need to get back to robot building.

Windows 95 Network Fonts Folder Bug

While transferring files from a Windows 95 machine to a Windows 95 VM, I discovered a very curious bug. I needed to grab all the fonts from the machine and put them in the VM, so I used Explorer to access the machine's fonts folder via LanMan. The two computers appeared to have the exact same set of fonts when I looked at it on one screen (one window at the local folder and one on remote), but the real machine had far more when I looked at its fonts folder at the real workstation.

I accessed the VM's fonts folder over the network from the real machine, and it showed the same fonts on both computers - but with an entirely different and much larger set of fonts! Apparently, accessing any folder that is configured via desktop.ini to be the Fonts folder will produce the Fonts dialog without regard for which computer it is on.

The workaround was to copy all the font files over via a command prompt, which doesn't do any special shell-folders stuff.

What's up with the big air blocks in Minecraft oceans?

If you've played Minecraft for a while and gone adventuring on the high seas, you may have noticed an unusual phenomenon in large bodies of water. Large rectangular-prism pockets of air may sometimes generate a few blocks on or under the ocean surface.

These appear when abandoned mineshafts have generated or attempted to generate under the ocean floor. The air pockets would have been filled by an "entrance" to the mineshaft had there been the right type of blocks there.

All structure generation is canceled by the presence of liquid within a component's bounding box, but the critical/initial parts do execute some generation routines. For example, the End portal room of a stronghold will generate wherever it tries to, though it might be alone if other potential components intersect standing liquids. Evidently, the block-clearance code for mineshafts executes before the liquid check, resulting in the strange air bubbles.

Robotics - Wi-Fi Time

As in all Thursdays, today's robotics meeting was extended from its normal length of 90 minutes, this time to a full three hours! (Fortunately, there was pizza.) I finally started on the engineering notebook, taking advantage of my nice video-and-image camera to photograph the sketches on the whiteboards. 

I also took some time to read over the engineering notebook section of the rulebook, and also went through the official FTC Forum's question-and-answer section. When a question is asked there that requests a rule clarification, the response from the FTC officials is essentially added to the rulebook. Unfortunately, it's spread out all over a bunch of forum threads and not centralized very well, so basically rules are constantly being created and I don't have a convenient way to know about them.

The box-with-flap idea continued its development. The team captain attached a servo to the box and constructed a frame for the assembly, which will be combined with another design by a different builder.

Builders from the school's other team asked me to help them program their robot. They don't have a programmer, and I didn't have anything else to do, so I started hooking up their robot with some functionality. First, we needed wireless connectivity. The Samantha module that I couldn't get to power on previously worked on their robot (I guess the battery I was using is bad), but it refused to accept configuration from the USB drive - it would do the light cycle like it was updating, but would always go to a random unsecured network instead of the one I told it about.

It turns out there were two problems. One: the Samantha module was bad. Two: the flash drive I was using had too much capacity. The Samantha bootloader can only address 4GB of hard drive space and will be very confused if there is more. Fortunately, there was a 2GB drive laying around.

With everything connected, I moved on to writing some code. Since all they had connected to the robot was the driving motors, the code was extremely simple. However, it didn't work well at all - the joystick controls don't seem to have any effect. It works as expected when I hard-code motor power values, but passing in joystick values makes the robot go in circles slowly or do nothing at all, depending on whether I epsilon'ed the value.

I did discover that I have to call getJoystickSettings (or something like that) on the "joystick" object, but even that doesn't seem to help. I'll have to keep looking in the configuration - something has to be wrong with the controller setup.

Robotics - Scoop Design

Some people actually came to today's robotics meeting! (Well, two more than yesterday. It's something. At least one of them was a builder/engineer.) I wrote all the ways to score points on the board so we can start planning which goals to go after, but without a basic robot we can't really test anything to see what's possible.

The team captain (who is a builder) showed me a design sketch for the scooping mechanism for the balls. It has two servos: one to flap its lid (which is also a shovel-like thing) and another to flip the entire box-like assembly up for elevation. The assembly will probably be elevated with a linear slide for dumping into the rolling goals. He also had some ideas for a light little channel to attach to the box assembly to extend its reach.

We don't have a drill yet, so removing those misplaced rivets is not currently feasible. The coach said he would bring a drill on Thursday, we should be able to finish up field construction then. I continued my attempts to power on the Samantha module, but I believe the battery with which I am trying to power it is faulty despite it turning on the LED in the motor controller. In the meantime, I will take on the role of engineering notebook compiler.

Robotics - Oops

There were extremely few people from my team at the robotics meeting today (despite almost the entire other team being there), so we did not accomplish much. I did pull out the instruction manual for the center field assembly, then tried to continue the assembly with the help of the only other person on my team present.

We got to the part in the instructions where it says to place the ball holder, but we couldn't understand how to screw it in. When we found the holes for doing so, we noticed that the pipes that were holding the upper part stiff were in the way. Then, to our dismay, we discovered that the instructions mentioned an entirely different set of pipes when it told us to push them through the center slope's holes. We had been using the kickstand pipes, which were obviously far too long! To make it even worse, the other builders had drilled holes in those pipes to line up with the holes on the side - and then riveted the kickstand pipes to the inside wall! The short pipes that were intended for bracing already had holes.

We'll need to figure that out when we get a drill. In the meantime, I installed Git for Windows onto my school laptop and successfully authored a commit to GitHub using it. This source control thing works fairly well.

Robotics - GitHub Time

From this day forth, Thursday robotics meetings are 45 minutes longer than usual, for a total of more than two hours of robotic goodness. This enables me to run around like a crazy man searching for various tools for even longer.

One of the FLL (middle school robotics) coaches happened to drop by. She is a project manager somewhere and knows a lot about organizational efficiency. She talked to us for a while about what kinds of things would help us get our work done better. All our rooms are a huge mess, and we don't really have a plan currently. I was planning on reading the full rulebook and maybe creating a task list during today's meeting, but then other things happened.

Specifically, since the teams had been reshuffled, I needed to get the NXT renamed and the wireless router reconfigured. Those tasks were very easy to do, but then I got the urge to also configure the Samantha wireless module. I ran around the rooms to collect the appropriate cables and the motor controller, but soon ran into a problem: the wires were frayed and fused and generally in disrepair at the ends. I then ran around some more looking for scissors and wire strippers. I found scissors, but the only wire strippers around didn't actually strip wires. So, I made do with what I had:

I pulled a knife and cut the insulation from the wires. (Dramatization. I actually had to scrounge around for any sharp object and ended up settling with a replacement pocketknife blade slightly poking out of its packaging.) Then, I used the scissors to cut off the frayed bits (metal shavings everywhere!) and screwed the now-much-tidier ends into the motor controller, which was actually being used to convert between power cables instead of controlling motors.

For some reason, the Samantha module wouldn't power on even though the motor controller light did. I tried with a different Samantha module and a different Samantha cord, so the problem must be with the battery or motor controller. That will wait for another day.

Then, I helped to continue assembling the field. After acquiring a drill, it was very easy to remove the failed rivets and then rivet the Plexiglass to the correct brackets. (One person also managed to break the riveter itself, which was kind of exciting. Fortunately, the math teacher (and I have no idea why he was in the room) fixed it, but it acts a little different now.) We made a lot of progress, adding the Plexiglass, the upper crossbar, and the support pipes to the center assembly.

Finally, I talked with the other programmer on the team and we decided to use GitHub for managing the robot program source code. Since GitHub is offering lots of cool free stuff to people with .edu e-mail addresses, we will have a private repository there. I created that today, granted him access, and started looking around on GitHub. It seems like a pretty nice thing. I will soon install the Windows Git client on my school-issued laptop and get to writing some code.

Robotics - Team Reshuffle

Today, the coach of the robotics teams reported that he had talked with some of the other school administrators and decided to change the teams. They are now going to go with the original plan of having one super-team of experienced people and a team of the new people. This should maximize the productivity of the people who really know what they're doing while letting the new people discover what works and maybe find something the veterans wouldn't.

This arrangement does leave the newbies without a programmer (or somebody who can set up their WiFi router), so I imagine I'll be giving them some help in my downtime.

After the short team meeting where this was announced, I destroyed the my documentation about the old teams and created a new OneDrive share with a new team roster document. We fixed the rivet issues created last time employing the help of a drill. We also went to the hardware store and bought some longer rivets to avoid such problems in the future.

The construction of the field's center assembly is still not close to complete, but at least we removed all the failed rivets from the holes. Next time, we'll mount the clear plastic and hopefully the ball bucket.

Windows 10 Technical Preview: Live First Impressions

Yesterday, I spent a couple hours recording a live "first impressions" video of the Microsoft Windows 10 Technical Preview. Tonight, I got it all edited down to one hour and uploaded it to YouTube. (I had to verify my account via phone to publish such a huge video.)

Sit back, relax, and enjoy the adventure! Welcome to Windows 10.

Robotics - Building the Field

I actually did something useful and robotics-related at robotics today! The components for our field just arrived, so it's time to set it up. The teachers/coaches/mentors decided to purchase components for only half the field, which is passable (we don't need to host actual four-robot rounds in our testing field), but of course suboptimal. We'll deal with it, but it will be somewhat more difficult to test both robots at the same time; having both sides of the field available for that was really nice last year.

There are quite a few parts and lots of nuts and bolts. So far, we built the ramp and started the construction of the centerpiece. The ramp construction was made somewhat difficult by the lack of an appropriately-sized crate to place under the top piece to hold it up. We also don't seem to have the right size of 90-degree braces, nor can we understand what the documentation means when it says "flanger." (We even looked it up and there is nothing like that in any of the pieces!)

The build team has a barebones drive system together, which I imagine I'll be programming tomorrow.