Adobe Flash Player Update

Once again, there is a security hole in Adobe Flash and everyone should update to version 10.0.22.87 (open Flash Player Version Display in case you want to know the version of your Flash Player).

Home users can easily go to the Get Flash page from Adobe and update their player. No big deal.

However, in a company with more than 500 computers, users are normally not allowed to install any software and any ActiveX/XPI download is blocked. Means: All these users can't update their flash player; it must be installed by the IT.

Normally this isn't a big problem at all since the Flash player for Internet Explorer is just an OCX file that you can easily replace. Starting with version 10, Adobe patches the security ACL for this file and denies the user EVERYONE the access to write the attributes for the OCX. Before they do this, they set the attributes of the file to READ-ONLY.

Boink, you can't copy the new OCX file because it's marked READ-ONLY. ATTRIB –R does also not help, because the ACL on the file prevent you from doing this. To make a long story short: In order to update Adobe Flash manually you need to perform the following steps.

• Get a new Flash OCX from Adobe. Easiest way possible is to use one machine that is directly connected to the internet and update Flash from the Get Flash Page page.
  
• Copy the Flash OCX from C:\WINDOWS\system32\Macromed\Flash\Flash10b.ocx to a network share where all machines have access to.
• Use the following batch file which will first delete the old Flash OCX, then patch the ACLs on the file, which will allow us to change the attributes using ATTRIB (remove READ-ONLY) which ultimately allows us to copy the OCX file.
  

SET FOLDER=%SYSTEMROOT%\system32\Macromed\Flash

SET OLDFILE1=%FOLDER%\Flash10a.ocx

SET NEWFILE=%~dp0flash10b.ocx
SET NEWFILE_DEST=%FOLDER%\Flash10b.ocx


IF NOT EXIST %FOLDER%. GOTO ENDE


IF EXIST %OLDFILE% DEL %OLDFILE1%

CACLS %NEWFILE_DEST% /E /R Everyone
CACLS %NEWFILE_DEST% /E /R Jeder
echo j|CACLS %NEWFILE_DEST% /E /G Users:F
echo y|CACLS %NEWFILE_DEST% /E /G Users:F
echo j|CACLS %NEWFILE_DEST% /E /G Benutzer:F
echo y|CACLS %NEWFILE_DEST% /E /G Benutzer:F

ATTRIB -R %NEWFILE_DEST%

COPY %NEWFILE% %NEWFILE_DEST% /Y /V

regsvr32.exe %NEWFILE_DEST% /S

:ende


Please note: This script will not install Flash, it will just update it. And it only updates Flash for Internet Explorer, not for Firefox or any other Browser. That every call to CACLS is duplicated is simply due to the fact that we also have German machines which expect "J" for JA instead of "Y" for YES.

.Net DateTime vs. TickCount compare operations

Yesterday, a friend of mine called me. He is writing a small program for a client and this program should execute simple operations at a given time. These operations don't take very long, but there will be a lot of checks in a second to make sure that the operation starts (nearly) exactly at the given time.

My friend has concerns that a simple "TriggerDate>DateTime.UtcNow" would take to long so he started to use Environment.Ticks. The Ticks operation is for sure faster, because this is only a simple addition and comparsion. However, the ticks will go from Int.MinValue to Int.MaxValue in about 49 days, when the counter will flip back to Int.MinValue. This caused him a lot of headache.

I first tried to improve his code, when I realized I first need to determine how much slower is a DateTime comparison. So I wrote the following small test code:

private void CheckDateTime()
{
DateTime dtStart = dtNow new TimeSpan(0, 0, 5);
long iCount = 0;

DateTime dtNow = DateTime.UtcNow;

for (; DateTime.UtcNow < dtStart; iCount )
{
}
PrintResult(dtNow, iCount);

}

private void CheckTicks()
{
int iTick = Environment.TickCount & int.MaxValue;
int iTickStart = iTick (5 * 1000);

long iCount = 0;

DateTime dtNow = DateTime.UtcNow;

for (; (Environment.TickCount & int.MaxValue) < iTickStart; iCount )
{
}
PrintResult(dtNow, iCount);

}

private void PrintResult(DateTime starttime, long Operations)
{
DateTime dtNewNow = DateTime.UtcNow;

TimeSpan elapsed = starttime - dtNewNow;

textBox1.Text = "Time: " elapsed.TotalSeconds.ToString() "\r\n";
textBox1.Text = "Operations: " Operations.ToString() "\r\n";

}


The result: On a standard 1.8 GHz Intel Core 2 machine (E2160), I had 192 million DateTime comparisons in about 5 seconds and 593 million TickCount comparisons. This means: My computer is able to do a whopping 39 millions DateTime comparisons/second and 120 million TickCount comparisons/second.

Conclusion: Yes, DateTime is slower than checking Ticks, but given these figures you really don't need to care about this difference.

Calculating when an integer identity column will be exhausted

Last week, we had an interesting discussion with a client which data type an identity column on a table should have. We are working with this client on a redesign of an in-house LOB.

In particular, we were discussing one table that we expecting to have one to two new rows per second each day. The customer wanted to define the identity as bigint, while we said that integer (int) is enough and faster for sure. What would you think how long it takes until an integer column as identity will "explode" on this table? Two Month? Three Years?


Well, if we calculate with three changes per second it would actually take 23 years!


In case you find this Excel file useful, you can download it here.