Useful commands after installing a brand new system

Firewall settings for ICMP (i.e. response to PING requests)

netsh advfirewall firewall add rule name="ICMPv4" protocol=icmpv4 dir=in action=allow
( REF: http://support.microsoft.com/kb/947709 )

netsh firewall set icmpsetting 8
netsh advfirewall firewall set icmpsetting 8
( REF: http://www.petri.co.il/enable-ping-windows-2008-server.htm )

Start > Administrative Tools > Windows Firewall with Advanced Security

Generic Local Area Networks v2019.10.0,


Ex-Employee tells about the Microsoft Windows internal testing process [Bookmarks, +TLDR, +FR]

"Why does Microsoft Windows 10 have so many bugs? Ex-Employee tells you why!"
-- by  Barnacules Nerdgasm

Link and preview to video "Why does Microsoft Windows 10 have so many bugs? Ex-Employee tells you why!" by Barnacules Nerdgasm

TL;DR (FR-version) :
  1. 1/ Ils ont licensié un département entier de testeurs quand ils ont fusionné leurs multiples systèmes d'exploitation : Desktop , Phone, etc.
  2. 2/ Ils ne testent plus du hardware réel; tout est virtualisé (i.e. les problèmes spécifiques au matériel ne sont pas révélés)
  3. 3/ Ils se reposent beaucoup sur le _Windows Insider Program_ et la télémétrie pour avoir des remontée de bugs avant de déployer les mises-à-jour "au plus grand nombre" (mais ce mécanisme a des limitations : les utilisateur du _Windows Insider Program_ ne remontent pas toujours les problèmes, les _mini-dumps_ ne sont pas toujours suffisants pour identifier la source d'un problème, les problèmes sont résolus à tâtons, et dans les pire cas, complètement ratés et les correctifs causent davantage de régressions).

TL;DR (EN-version):
  1. 1/ They did a massive lay-off and got rid of a whole testing departement when they merged their multiple Operating System teams : Desktop, Phone, etc.
  2. 2/ They don't test real hardware anymore; tests are run in virtual machines (ie. hardware-related corner cases are not tested)
  3. 3/ They rely a lot on the _Windows Insider Program_ and telemetry before rolling-out updates to "most people" (but this process has limitations : _Windows Insider Program_ users don't always report bugs, _mini-dumps_ aren't always enough for tracking down a bug, some problèmes are solved by groping and, in the worst cases, even missed entirely and attempts to fix a problème cause further regressions).


Missing a persistent SCITE_USERHOME environment variable ?

PROBLEM / SYMPTOM: The scintilla-based Text Editor does not save sessions, latest files, nor any configuration. At each start the environment is pristine.

CONTEXT: SciTE was installed using Chocolatey.

$ choco install -y autoit --version
$ choco install -y scite4autoit3 --version 19.102.1901.001 


SciTE utilities look for an env variable called SCITE_USERHOME and when that is missing will assume a portable installation of SciTE:

Fix, Part 1: Create missing directory

If you are not running as a standard user and have a different account for administration, you might notice that a directory "C:\Users\Administrator\AppData\Local\AutoIt v3\SciTE" was created but not "C:\Users\StandardUser\AppData\Local\AutoIt v3\SciTE"... So the first thing to do is to fix that directory:

cmd /c "mkdir "%UserProfile%\AppData\Local\AutoIt v3\SciTE" & pause"

Fix, Part 2: Create user's environment variable


cmd /c "setx SCITE_USERHOME "%UserProfile%\AppData\Local\AutoIt v3\SciTE" & pause"

This command is the correct one, and we could stop right here. But out of curiosity, let's see how we could make a dynamic variable.


In order to use REG_EXPAND_SZ type variables, we'd have to use the REG.EXE utility. It takes a little bit of escaping to pass the "percent" characters to the command, but this is how it would look:

cmd /c "REG ADD HKCU\Environment /v SCITE_USERHOME /t REG_EXPAND_SZ /d ^%UserProfile^% & pause"

Additional information

Missing a persistent environment variable ?

Registry hives and paths

  • User Variables: HKEY_CURRENT_USER\Environment
  • System Variables: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment


Introduction to .ignore files syntax and capabilities


You'll mostly have to look up the documentation of the .ignore files syntax if you want to master this tool and find the right tradeoff/middleground between being specific and being generic about what files you ignore in your project.


In general, you can either 1/ be specific or 2/ use wildcards or 3/ use negation patterns. For instance you could say ignore all "bin" directories, except a particular one:


Notice the exclamation mark at the begining of the second line: it's a negation. It means: DO NOT IGNORE.
=> Those two lines combined, will ignore all "bin" directories, wherever they are in the tree ( double asterix = means any subdirectory ) except that one particular one, named on the next line and prefixed with an exclamation mark.


But saying this I'm only scratching the surface of the power of the .ignore files, you need to look at the doc to know more. (eg. you can have a generic .ignore file at the root of the solution and, for specific cases, other .ignore file(s) in subdirector.y.ies somewhere too)


Last but not least, if you're confident with .ignore file, you can even invoke destructive commands such as "clean" and delete everything that is not under source control ( ie. that is ignored )... which is basically a prequel to REBUILD ALL.

# WARNING: cleans absolutely everything that is not under source control
    git clean -nfdx # << To preview what would be deleted... -n = NoAction = --dry-run
    git clean -fdx # << The actual cleanup.


"tfignore file - Google Search"

For Fox

"Visual Studio 2015 TFS .tfignore file - Stack Overflow"

For Seb

Excluding Files From Team Foundation Version Control Using .tfignore Files - Applied Information Sciences

For everybody

"GitHub - sirkirby/tfignore: A Collection of .tfignore Templates"

"GitHub - github/gitignore: A collection of useful .gitignore templates"


The trend for an "Opt-out"-style philosophy for source control

The old "Opt-in"-style for source control

I remember, when using Microsoft's Team Foundation System and Visual Studio, you'd have two ways to add a file to source control:

  • either Visual Studio would take care of that for you when your file was part of a Solution
  • or you would have to manually browse the "Source Control Explorer" and add you new files

Preview of the Visual Studio's Source Control Explorer Graphical User Interface

A preview of how to explicitely add files to source control in Visual Studio

Things have changed

As far as source control goes, everybody is moving to "opt-out"-style policies, instead of "opt-in"-style ones, ( get used to it :stuck_out_tongue_winking_eye:  , 'cause it's actually much safer and nicer in the long run... even if there is an "up-front" price to pay -- ie. setting up your ".ignore" file)

Now, everything is under source control by default, unless you specify otherwise. This is nice because you typically don't get things happening behind your back without you knowing or forgetting (files added, changed or deleted).

Configuring what is ignored

When using the Git version control system, the critical files for specifying what is not meant to be kept under source control are the famous ".gitignore" files.

Visual Studio and Team Foundation System have a very similar concept, except the file is called ".tfignore".


Talks about WASM and WASI [Bookmarks]

For those who are curious or who want to follow up about WASM and WASI, I recommend two recent videos to help understand it all. But first, some opinion about the topic.

Twitter message

This is an insightful Twitter message from Solomon Hykes is the Founder, Chief Technology Officer and Chief Architect of Docker and the creator of the Docker open source initiative.

Preview of the Twitter message from Solomon Hykes

Video 1/2

"Rust, WebAssembly, and the future of Serverless by Steve Klabnik"

Preview of the YouTube screen about Rust, WebAssembly, and the future of Serverless by Steve Klabnik

Video 2/2

"Bringing WebAssembly outside the web with WASI by Lin Clark"

Preview of the YouTube screen about Bringing WebAssembly outside the web with WASI by Lin Clark