New misspellings found, please review:

• NOCLIPBOARD
• NOCOMM
• NOHELP
• NOKERNEL
• NOMB
• NOMCX
• NOMSG
• NOSERVICE
• NOSOUND
• NOUSER

perl -e '
my @expect_files=qw('".github/actions/spell-check/expect/5757ec679b03a4240130c3c53766c91bbc5cd6a7.txt
.github/actions/spell-check/expect/655f007265b351e140d20b3976792523ad689241.txt
.github/actions/spell-check/expect/alphabet.txt
.github/actions/spell-check/expect/expect.txt
.github/actions/spell-check/expect/web.txt"');
@ARGV=@expect_files;
my @stale=qw('"AAAAA Bopomofo CParams CSV GENERATEPROJECTPRIFILE hhhh Horiz IHosted Inlines MAKEINTRESOURCEA mousemode renamer
 Reserialize rgus SGRXY tcon UDK UDKs Unfocus xe xlang "');
my $re=join "|", @stale;
my $suffix=".".time();
my $previous="";
sub maybe_unlink { unlink($_[0]) if $_[0]; }
while (<>) {
  if ($ARGV ne $old_argv) { maybe_unlink($previous); $previous="$ARGV$suffix"; rename($ARGV, $previous); open(ARGV_OUT, ">$ARGV"); select(ARGV_OUT); $old_argv = $ARGV; }
  next if /^($re)(?:$| .*)/; print;
}; maybe_unlink($previous);'
perl -e '
my $new_expect_file=".github/actions/spell-check/expect/d2fbcd227cce9851e7640f7734955952a23320dd.txt";
open FILE, q{<}, $new_expect_file; chomp(my @words = <FILE>); close FILE;
my @add=qw('"csv horiz inlines NOCLIPBOARD NOCOMM NOHELP NOKERNEL NOMB NOMCX NOMSG NOSERVICE NOSOUND NOUSER Renamer reserialize udk unfocus "');
my %items; @items{@words} = @words x (1); @items{@add} = @add x (1);
@words = sort {lc($a) cmp lc($b)} keys %items;
open FILE, q{>}, $new_expect_file; for my $word (@words) { print FILE "$word\n" if $word =~ /\w/; };
close FILE;'
git add .github/actions/spell-check/expect || echo '... you want to ensure .github/actions/spell-check/expect/d2fbcd227cce9851e7640f7734955952a23320dd.txt is added to your repository...'

⚠️ Reviewers

At present, the action that triggered this message will not show its ❌ in this PR unless the branch is within this repository.
Thus, you should make sure that this comment has been addressed before encouraging the merge bot to merge this PR.

Oh goodness. Let's list out what these actually do.

• NOCLIPBOARD
  • Blocks CF_* clipboard formats
  • Blocks Open/Close/Empty clipboard
• NOCOMM
  • Modem stuff
• NOHELP
  • WinHelp and friends (I think this is deprecated)
• NOKERNEL
  • GetProcAddress and a bunch of process/thread management stuff
• NOMB
  • MessageBox and friends
• NOMCX
  • Modem extensions
• NOMSG
  • Message queuing (Wndproc and such)
• NOSERVICE
  • Service Controller
• NOSOUND
  • Open/Close/Start/Stop sound
  • Notably not PlaySound
• NOUSER
  • Icon, Cursor... System Metrics, System Parameters Info...

Now let's list out if any Terminal/Console project has used them.

• NOCLIPBOARD
  • Console and Terminal use clipboard routines to access the clipboard.
• NOCOMM
  • Nothing touches the modem
• NOHELP
  • WinHelp is dead, nothing should touch it.
• NOKERNEL
  • Console and I believe Terminal need process/thread management and debug stuff from this.
• NOMB
  • Nothing should use MessageBox in production except maybe a last chance error, but sometimes people use this for debugging.
• NOMCX
  • Nothing touches the modem
• NOMSG
  • We use message queuing all the time.
• NOSERVICE
  • Console doesn't touch the service controller, but I believe Terminal does now to check about the input service.
• NOSOUND
  • Only PlaySound is used for a system beep. I don't believe we have any other sounds.
• NOUSER
  • System metrics and parameters are used all over the place.

Then my feeling on this:

1. I'd rather we remain relatively consistent with what's in all the namespaces in our projects unless there's a measurable and appreciable improvement in compilation time or debugging ease.
2. I'd rather not block out anything that we used or have the potential to use even on a semi-regular or debugging basis so there's not another roadblock to debugging a problem that is a bit more obtuse/obscure to understand.
3. I'm fine with blocking things that we really shouldn't have any reason to do.

So overall... I think I'd be fine with blocking out:

• NOCOMM
• NOMCX
• NOHELP
  and probably
• NOSOUND

But I think all the rest are going to get us into a future difficult-to-debug pitfall that's not worth it unless you can justify it with some sort of improvement metrics.

I actually have the same concern that it will “get us into a future difficult-to-debug pitfall ”. I’ll try to make this PR less aggressive.

Hey so I don't think I'm qualified to review this one. It looks fine to me, but I don't really have an opinion or enough background to know what the side effects would be. I'm gonna leave it to @miniksa and @DHowett, they're probably the best suited to reviewing this.

Hello @DHowett!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.