The best part is the 4:3 ad runs set in the frame of a 16:9 monitor on that second link. Who cares what the ad was for, the awful presentation was humorous enough.
IHateEverybody
@IHateEverybody
Best posts made by IHateEverybody
Latest posts made by IHateEverybody
-
RE: Sharp OSA, the idea makes me cry.
-
RE: Wash hands after handling
It gets even better. The last time I bought a Toslink cable (optical audio), it too had the silly California lead sticker. Never mind that an optical cable is a clear plastic strand with an opaque plastic cover. No metal of any sort, so uhm, where's the lead? I want my damn lead! It says right here this product contains it...
-
RE: Redirection page has moved
Every few weeks, MSDN decides I've moved countries and learned a new language. I notice the "en-us" in the URL has changed to some other language-country when this happens. If I edit the URL I get the English page, but as I follow links I get the same wrong language versions more and more often. The solution is to delete all microsoft.com cookies. Every once in a while I get a page thats part English, part very much not so (far East character sets sometimes), and the URL is still correct. WTF
The search also sucks mightily. They added the ability to filter (yeah, no more Win32 for twenty dozen different desktop varieties when I want the one CE reference), but the damn filter list is in random order and cosists of a random set of choices that is sometimes incomplete (as in I know the API exists on CE but there's no choice for that. Prior to the filtering, I looked at the link and could tell what product it was for, but that was useful which is unacceptable so they changed the URL scheme to random junk. Of course that was months prior to the filtering option, so those were fun times searching for docs.
Around the time they added the filtering, they changed the search box to contain some italicized gray text as a label. I guess its really hard to put a label next to the field or something. Since this label exists in the field, it must be removed before its useful for search text, so there's a script to clear the field and revert its style to plain black text when focus enters. Of course, their script to do so works half the time at best. The other half, my search text is buried in the middle of their label and zero results come back.
-
RE: Regress to Developmestuction
I just read it with the missing 'n' restored, developmenstruction. Or, development-destruction, as in destruction of production by overwriting it with development.
-
RE: Security via JavaScript
If this thing is blocking by IP, then anyone behind NAT is safe because their IP should always be a non-routed address. Their external IP could very well be on the ban list, but their browser evaluating the javascript has no idea about that external IP. Alternatively, everyone behind NAT could get screwed simultaneously if the site added the non-routed addresses to their ban list.
-
RE: So, Vista not stable yet I guess?
@ShadowWolf said:
NTFS is a journaling file system, so this has always been supported. Atomic Transactions is a Kernel level improvement and not an NTFS improvement.
The only substantial changes to NTFS have been in the areas of bugfixes and feature changes; however, largely the last set of major changes were in the Windows XP release.
Vista is not and never will be "more fragile with crashes." The whole "crashing your computer corrupts your drive" thing has been gone for a while. You can lose chunks of data and such, but that's about it. You shouldn't see instances where the whole drive gets pooched. If you do, I'd pin it on the motherboard / drivers or something of that nature before I'd pin it on NTFS.
Plus, don't confuse the crappiness of Win32 with the FS.
When do you propose the magical point was crossed where a NT crash is unable to horribly corrupt an NTFS volume? This definitely happened in Win2000, as I detailed a few posts up. The chanegs to NTFS going from W2K to XP are probably less significant than the changes going from XP to Vista. Just because you don't notice them as a user, doesn't mean they didn't happen. NTFS transactions involve changes in the NTFS driver as the kernel, though not necessarily in NTFS on-disk structures. There are others as well if you read up on what has been done after the WinFS abortion. When a system is crashing, it can do any stupid thing it wants, including writing over a critical part of the file system. This is true of any OS and thre is no way to completely mitigate the possibility, only reduce it.
-
RE: So, Vista not stable yet I guess?
They did change NTFS in a number of ways a likely broke something. Of course, since it was already highly broken, they wouldn't even need to change it to achieve whole drive corruption. I've seen NTFS get corrupted in a number of ways, but I'll just share the best one.
A Windows 2000 SP3 machine with an installed time of a few years and an uptime of a few weeks suddenly crashed to the standard BSOD. When the reset button was pushed, it couldn't boot. I forget the exact error because its been years, but wahtever should come right after NTLDR failed (there was a FAT drive with NTLDR and boot.ini on it, W2K was installed on a separate NTFS partition). So, I get out the regular tools and go to work. Boot with ERD Commander, drive in question doesn't get mounted. Odd. Boot Remote Rescue and map the physical disk over the network to another W2K box, where I try to mount the volume. Failure. Try running various tools on it, but everything basically says 'This disk is not formatted NTFS'. Now, this could sound like fatal physical disk failure, but the disk was in perfect condition and there were no sector read errors at all. Eventually, I found a great little program called GetDataBackforNTFS, which saved the day. Basically, I pointed it at the disk, it read the whole MFT into memory, and then tried reconstructing around the errors in a variety of ways and presented alternate view into the file system. I pick the one which shows files and not just garabage directories full of garbage names, and it 'mounts' the volume using its in memory reconstruction of the MFT. I was then able to copy all the files off the disk, reformat the disk, reinstall W2K, and copy back all my rescued files. Nothing big in the end, but solid proof that NTFS can trash a whole partition in a single write to the point that almost everything that can deal with NTFS doesn't even think the disk is formatted.
-
RE: Visualize A Stable IDE
I actually thought about doing a VS2005 bug blog. I could post daily without even having to try to come up with material. I use it just for C++, no proprietary garbage languages. I have a VM in which it runs and nothing is installed but Windows, VS2005, the Windows Mobile SDKs, ActiveSync, and a few tools like Beyond Compare. So, not much chance for extra software to be causing trouble. All the same bullshit happens outside a VM on co-worker's machine so its not just my weird isolated development environment (some people have said the VM is the fault, but nothing else gets this screwed up by it).
With SP1, it always has linker warnings because some of the .lib files are are messed up.If you open configuration manager, you can change whats selected for the active config, but if you change the active solution configuration or platform, it'll go change what's selected for some other permutation of configuration and platform. You must go out, change the active configuration, then go back in to adjust the next.
Intillisense barely works. I can click on a function that's used 2 lines away from the definition, tell it to take me to the definition, and it says its not defined. Same thing can happen on the definition and declaration itself. It works about 10% of the time. Better yet, if I open a a project with 10K of source, it'll crank away for minutes to produce an 11MB .ncb file. Just what the hell is in that file!? It certainly doesn't seem to contain the locations of my functions. Even better, the .ncb is always written 2 bytes at a time. Even better, touching ANYTHING starts it into 'Updating Intellisense...', which could be the death. Opening a project, changing the active configuration, etc starts this. None are code changes, so that data should not need updating,. but updating it does. This seems to run on the same thread as the UI, because there's a brief window I can interrupt it by launching a build, but outside that window the whole UI it completely unresponsive to the point it becomes a blank white window if I drag something else over it. Sometimes this is a few seconds, other times it takes 10 minutes. So, I deleted the damn dll that runs Intellisense. Its not like I even edit in there, as I have a useful editor outside the VM and I just use VS2005 to kick off the compiler. It still craps out little .ncb files but at least it doesn't get stuck all the time.
Project/solution files randomly corrupt themselves. It was fine the day before, now VS crashes when opening. No error saving, diff shows nothing obvious, XML all reads sanely, etc. Delete the sln, open the vcproj on another computer (just try several until one opens it, always someone else's will but whose varies), hit save all and bring the files back and bam I can open them. Freakin' mystery.
Changing a single property in a project configuration has about a 20% chance of shuffling the file. Literally, the order of whole sections in the vcproj file change. No good reason, editing by hand and changing one line results inb a file of equal functional content. So, editing by hand is easier than using the UI as far as keeping it sane and human readable as far as history in the source control. Also, find and replace with a text editor is much faster than changing one setting a dozen times for all the permutations of configuration and platform.
When editing the properties, if you select multiple configurations and/or platforms, you can edit them together IF they are already the same. If the value differs, you can easily make them all be the same by just setting the new value. However, if they differ, the value shows blank. Is it empty, or are they different? Which one is different? Is that difference important or not? Who knows! Have to go through every permutation of configuration and platform one by one and look at the value. Someone that doesn't know this can easily blow away all the preprocessor definitions or library includes by just going to add one to all configuration at once.
Number of simultaneous compilation threads MUST BE set to 1. Setting more will cause build errors sooner or later. Either a header file can't be found, which was used in the prior source file just fine, or a library can't be found that was just generated by the prior build task. Run the build again and it works works. So, building becomes rebuild to get out the flack, since it can't figure out what's chanegd, then hit build until it completes without dumb errors, which could be several times. Really, no code changes, but files that existed and didn't come back. I think there's some serious issues with file locking and concurrent access, as in last buld step hasn't quite closed the file when the next build step tries to open it and fails with a sharing violation, which it declare as FILE_NOT_FOUND rather than retrying after a brief pause.
A similar problem with missing files can be created by the aforementioned shuffling of the vcproj file. I have one project where ANY change made in the properties editor on the project WILL move the first source file in the list (stdafx.cpp) to the bottom. If that file is not the first, it will claim stdafx.h does not exist for the first file compiled. stdafx.cpp MUST be first, yet changing anything makes it not the first, so I have to close the solution, repair vcproj by hand, reload solution, and compile again. Easier just to edit the vcproj outside VS2005 in the first place.
Creating a new platform from an existing one causes it to substitute in values for some macros in the new platform configuration. Thus, the macros don't exist anymore and its impossible to use that as the source of yet another platform without first fixing all the macros. All it has to do is copy them as-is, which it does for some, but not for others, such as $(PlatformName) in some instances (not all). So, more hand editing.
The resource editor has no indication of how anything you are laying out relates to the physical screen. No way to tell it to start out your window at the size of the screen on the device. All ifdefs in the .rc file will be removed when making a single change in the resource editor. Huge sections of the .rc file will be translated from bitwise ORs of defined values into computed dword values, making future hand editing harder. The size of certain things, like just about any text element, differs on the actual device vs what is show in the dialog editor. Its easier to lay out everything using a calculator and a text editor to directly fill in the .rc file than to fiddle around things in the resource editor, constant tweaking, rebuilding, and testing to see what else is off by a few pixels here or there. Never mind why I'm laying stuff out at all, except the GUI library on the platform is absolute trash that was barely useful in the 80s much less now.
In the end, VS2005 ends up being a very inefficient way of kicking off a compiler that uses really big and ugly makefiles that are composed in XML for no apparent reason. For bonus points, the XML schema is atrocious and requires duplicating huge amount of settings. Template files can be made and included to help reduce the duplication, except all the settings from those don't show up at all in VS2005 itself so others have no idea they are there and start running over the inherited values without realizing it as they add stuff. Also, you must reload the whole solution to when editing the templates because VS doesn't detect the change as it does when editing the vcproj files directly.
For extra fun, there's all the errors in the compiler that lies under VS2005. I have instances where it simply generates wrong code. Now and then its a matter or rebuilding to get something that resembles the source's intent. Other times, the source has to be changed to work around some bug. A few times now I've found a situation where I have to add a logging statement (generalized, a function call that takes a string literal as a parameter, so maybe fiddling the stack?) as the first in the else block (which I might have to add) of an if statement, other the whole function ends right where the if statement starts, the return value is garbage, and no exception is thrown. In all cases, it takes a day or more to trace down because everything is correct in the code, and somewhere along the way debugging the problem just goes away, but then all the logging or MessageBox()es or whatever else was added needs to be stripped away one by one until I find the one that must stayt. In all cases the code worked before but some other unrelated change elsewhere in the file, or just the exact way the file is handled during compilation due to a change in project settings like the addition of another platform, wrecks havoc on the previously tested and correct code.
To top it off, a bunch of the little tools to go with the compiler, including bcsmake.exe, cabwiz.exe, makecab.exe and signtool.exe, have severe problems when operating on files on networks drives. Some of the issues are resolved by removing all spaces from the path. Others by ensuring files are all on a network driver OR all on a local disk, but not mixed. Some can't handle relative paths and don't supports macros (cabwiz, I'm looking at you) which makes it more difficult to work around. The build process is littered with batch files that copy files around between various steps just so these things will work. All the extras in the compiler like incremental linking must be turned off. To use precopmiled headers, it must be set to create the precompiled header every tie, otherwise at random points it'll insist the precompiled header does not match the vs80.idb file or whatever, even if I just had it on create and did a rebuild and now switched to use precompiled headers and hit build.
I thought using Windows was bad. Turns out developing for it is even worse. I spend more time working around bug in the development tools or figuring out what the error in the documentation is than actually developing functional code. There are whole weeks that go by in which no new code is written. Whenever I come across a new one of these gems I just want to go stab someone at Microsoft in the face. Repeatedly. And their family too. Friends also.
-
RE: Building security wtf
Its even easier than that actually. Just grab the door and start pushing and pulling as hard as you can and as fast as you can. There's a little bit of movement possible in the magnetic field before it gets difficult. As you you oscillate the door, you'll notice the range of movement increases without it getting more difficult. Think of it like a swing on the playground, hard at the start, but once you are going its little effort to slowly increase the travel. You move a little until you hit resistance (gravity or magnetic), at which point it wants to return, and if you start going that direction you are working with that force and will go further the other way. Keep this up and soon enough you'll manage to get outside the range of the magnet and the door will pop right open. Of course, this is only necessary when there aren't motion detectors to let you in.
-
RE: Building security wtf
We have the same type of magnetic locking glass doors here with the motion sensors to open from the inside. The first thing that came to mind for entering the building was take a newspaper from the stand on the opposite side on the entrance foyer and fling it under the doors to trigger the detector. That would get you into the building, but you'd still have to get to the office. The elevators require an access card authorized for a particular floor to go anywhere but the lobby or parking garage after hours. Of course, the elevators have emergency panels in the roof and there's a ladder in the shaft. So, up we go to the floor we want and push the doors open. Now, how to get into an office when each floor has locked main doors and and then within the are of the floor there's individual offices with regular key locks on the doors. Well, look up at that drop-ceiling and push up a tile to find that every wall stop at the drop ceiling rather than going up to the floor above. So, just push up a tile, climb on up and drop down on the other side. There's motion detectors within the area on each floor, but none of the offices inside have detectors so its just a matter of traveling in the ceiling direct from the elevator area into an office without stopping in an interior hallway.
I bet if you look around your building, you'll find similar failures in the security every step of the way. Its really amazing nothing has been stolen, but we've probably lucked out so far because nobody else seems to notice these things until I point them out.