Showing posts with label Microsoft. Show all posts
Showing posts with label Microsoft. Show all posts

Thursday, 17 February 2011

How to defragment the System Volume Information folder

How to defragment the System Volume Information folder?
We may use Mark Russinovich's Contig, one of the utilities in the Windows Sysinternals suite.
We have to start a Command Prompt as Local System, in example as described here, and then run:

contig -v -s "c:\System Volume Information"

P.S: I just discovered Mark wrote a book, Zero Day, now that is a promising reading :)

Tuesday, 15 February 2011

Where is Orca?

You have got the Windows SDK (in my case Windows 7 and .NET Framework 3.5 SP1), and you are looking for Orca, where is that?

Mount the ISO (in my case the x64 version, GRMSDKX_EN_DVD.iso), or explore that with some tool (in my case 7zip x64 9.20, which you will have to use in every chance), drill to Setup\WinSDKTools_amd64\cab1.cab, you will see a WinSDK_Orca_Msi_5E20C107_DAA3_4D49_AFAE_7FB2594F0CDC_amd64 file, extract that, rename it to orca.msi, and that's it.

Tuesday, 27 October 2009

Simbolo Microsoft Windowsiano

Dal breviario degli evangelisti (Microsoft):

Credo in un solo Sistema Operativo,
Supervisore onnipotente,
creatore dell'allocazione e del processo,
di tutte le cose eseguibili ed ineseguibili.

Credo in un solo Sistema Operativo, Windows,
unigenito Figlio di Microsoft,
nato da Microsoft prima di tutti i secoli:
Sistema Operativo da Sistema Operativo,
Desktop da Desktop,
Sistema Operativo vero da Sistema Operativo vero,
acquistato, non copiato,
allo stesso stessa prezzo imposto da Microsoft; (*)
per mezzo di lui tutti i processi sono stati eseguiti.

Per noi utenti
e per la nostra salvezza
è stato messo in vendita
e per opera degli OEM
si è integrato nel seno del controllo qualità,
e si è fatto codice eseguibile.

Fu infettato per noi sotto Arbusto Figlio, (**)
crasciò
e fu formattato

Il terzo giorno si è autoreinstallato,
secondo le Istruzioni,

e si è autoallocato,
ed esegue alla destra di Microsoft.

E di nuovo verrà eseguito, nella gloria,
per giudicare i processi in esecuzione e zombie,
e la sua esecuzione non avrà fine.

Credo negli OEM,
che sono Microsoft e danno la vita,
e procedono da Microsoft e da Windows,
e con Microsoft e Windows sono adorati e glorificati,
e parlano per mezzo dei pubblicitari.

(*) Punto moltro controverso, gli omousiani ritengono che il prezzo
sia imposto uguale per tutti, per omoiusiani che sia indicativo, poi
ci sono altri eretici che propongono le tesi più strampalate.
(**) Proconsole di America durante la generazione di Windows, anche se
alcuni ritengono fosse in realtà Pillo Clinto, mentre altri parlano di
Lusai Baraccopama.

Tuesday, 15 September 2009

Canvassing to get Microsoft to provide the option to stop on the first error

For all sort of good reasons, it would be great to have the option to stop a build in C++ or a compilation in C# at the first error; there are a lot of scenarios where we would save a lot of time (and therefore money).

It seems Microsoft hasn't been keen on solving those issues for years, and while it is possible to find work around on certain circumstances using macros (calling DTE.ExecuteCommand("Build.Cancel")), it would be a good idea advising Microsoft to revert his opinion about the severity of those issue.

If you have a Microsoft Connect account, when available please invest a minute on voting those issues:
From my own point of view they both deserve 5 stars.

Thank you,

Thursday, 6 August 2009

How to fix fatal error A1000 while compiling Crypto++ 5.5.2 on VS 2005

The possible cause

A white space on the path to the asm file.

The possible solution

If so, the solution is really simple (well, once you know it or you read it here or in such a place): open the solution in VS 2005, in the solution explorer locate x64masm.asm (should be between the Source Files of the crypdll project), right click on the file name (or do whatever you need to do to get the context menu), select the property menu item, go to Configuration Properties/Custom Build Step/General, and change the Command Line property from:
ml64.exe /c /nologo /Fo"$(IntDir)\x64masm.obj" /Zi $(InputPath)
to:
ml64.exe /c /nologo /Fo"$(IntDir)\x64masm.obj" /Zi "$(InputPath)"
Remember to do it for each configuration (Release, Debug, ..)

The story behind that possible solution

A long time ago, while trying to compile Crypto++ in Microsoft Visual Studio 2005, I got a "MASM : fatal error A1000: cannot open file : C:\Projects\Blabla\My" compile error.
The file name actually gave me straight away the lead on what was going wrong, as the asm file was located in something like "C:\Projects\Blabla\My Project\myasm.asm", and it was self evident the issue was with the space on the path.
After spending an inordinate amount of time to find out to fix it, I did fix it only for the Release x64 configuration, so the issue came back to haunt me later on, that's it this morning, when I was wishing to compile again Crypto++ (5.5.2, I don't know if they fixed it on 5.6.0), this time in the Debug x64 configuration.
After spending another inordinate amount of time on the issue and finding again the way to fix it, I decided to put in on my blog, so next time I may have the chance to google my own solution.

Wednesday, 4 February 2009

The "one too many installed .Net framework" time bomb

Today, after installing "Microsoft .NET Framework 3.5 Service Pack 1 and .NET Framework 3.5 Family Update (KB951847) x86", the Microsoft Internet Explorer 7 in my machine was broken.

I wasn't able to start various web applications anymore.

Also, when trying to check the about screen, I was getting an "Not enough storage is available to complete this operation" error.

Thanks to this, I found out why, and I was able to work that around.

It seems that for each installed .Net framework an empty registry value is added on the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform.
Now, it seems that some Microsoft function is getting all the names of those values, it is concatenating them on a big string, adding 2 characters per name, and if the length of this string exceed 209, IE will stop to work properly.

The work around was as suggested to remove as much names as to shorten that string to a length lesser than 209 characters (counting the 2 already spent for each name!).

In my case, I was having the following names:

.NET CLR 1.1.4322
InfoPath.1
.NET CLR 2.0.50727
FDM
.NET CLR 3.0.04506.30
.NET CLR 3.0.04506.648
.NET CLR 3.5.21022
.NET CLR 3.0.4506.2152
.NET CLR 3.5.30729
MS-RTC LM 8
OfficeLiveConnector.1.3
OfficeLivePatch.0.0

They would result on 226 characters (202 + 2*12), which is 17 characters too much. I removed the last value, and everything started to work again I could have removed also just every character after the first 2 ("Of"), and everything would have worked as well, but if we add anything more, IE breaks.

In general, if we find in that key a single value with a name of 207 characters, as such (obviously unbroken):

12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
12345678901234567890123456789012345678901234567890
123456

With this IE7 will work, add a single character more, and IE7 will break.

Now, until Microsoft doesn't properly fix it, the issue at stake here is if this happen, which names(s) should we remove?
On my workstation, for now I removed OfficeLivePatch.0.0, but it may be needed by some other application, so I think we should exercise good sense, and trying to figure out case by case which version of .Net is less probable to be used on a given workstation/server.