Angular package.json versions

^2.4.5 = 2.x.x
~2.4.5 = 2.4.x

C64: VIC-2 modes

http://sta.c64.org/cbm64disp.html
https://www.c64-wiki.com/wiki/Graphics_Modes
https://www.c64-wiki.com/wiki/Extended_color_mode
The Ultimate c64 talk
https://www.pagetable.com/c64ref/c64disasm/
https://github.com/mist64/c64ref

Amiga memory map: http://oscomp.hu/depot/amiga_memory_map.html

Ascii charmap effect: https://nurpax.github.io/posts/2018-06-07-c64-filled-sinewave.html 

FASM: using printf easily in x86-64

format pe64 console
entry start
include 'win64a.inc'

section '.text' code readable executable
start:
  push	rbp  ; with this action, the rsp is 16 byte aligned. Needed for fastcall requirement.
  cinvoke printf, message, 42
  cinvoke getch
  pop   rbp
  ret

section '.idata' import data readable writeable
  library kernel32, 'kernel32.dll', \
          msvcrt, 'msvcrt.dll'
  import  msvcrt, \
          printf, 'printf', \
          getch, '_getch'
  include 'api\kernel32.inc'

section '.data' data readable writeable
message	db 'Hello World! %i',0

FASM: when to use invoke or cinvoke

• call is a native CPU instruction in x86 Intel syntax
• invoke is a macro that uses pascal calling convention and does an indirect call (i.e. it uses "call [...]")
• stdcall is a macro that uses pascal calling convention and does a direct call (i.e. it uses "call ...")
• cinvoke is a macro that uses C-call convention and and does an indirect call (i.e. it uses "call [...]")
• ccall is a macro that uses C-call convention and and does a direct call (i.e. it uses "call ...")
  
  
• Use call if you need just the native CPU instruction
  
• Use invoke to call all Windows APIs (except wsprintf) and all DLL functions that use pascal convention
• Use stdcall to call functions you have defined with the proc macro
• Use cinvoke to call the Windows wsprintf API and all DLL functions that use C-call convention (e.g. MSVCRT)
• Use ccall to call functions you have statically linked that use the C-call convention and functions you have defined with "proc <func> c ..."
  

How to you recognize in which calling convention a function is created?
If the symbol begins with a _ but has no @, then it's __cdecl. If it begins with _ and has a @ it's __stdcall. If it begins with @ and has another @, it's __fastcall.

64 bits:
On 64 bits, all calls are fastcall, so cinvoke is the same as invoke.

Using SDL2 in DLL causes crash and werfault.exe at Process exit

SDL2 has a serious issue with closing the load-time dynamic loaded SDL2.DLL on win32.

So, I have a DLL called ground.dll which uses SDL2 by using load-time DLL loading. This load-time linking is not fully dynamic, but still dynamic. This ground.dll is created with Visual Studio C++. In my main FASM generated assembly program, I load-time load this ground.dll. The is no problem loading the DLL, but ProcessExit gets an crash error. It causes an werfault.exe (Windows Error Reporting).
All this happens without calling a single SDL2 function yet.
So, I tested if fully dynamic loading of the ground.dll fixes the issue, using LoadLibrary and FreeLibrary. This did not solve the issue.

I was very suprised to find this bug, because SDL2 is a much used library.

What might be the problem? Is the FASM assembled main program not correctly closing the SDL2? Perhaps... I created a C program which load-time loads the ground.dll and that program does not crash. However, the fact that even fully dynamic loading and freeing the library also causes the exit-crash, without calling a SDL2 function whatsoever, makes me think I cannot put the blame on FASM. 

At this moment, I worked around the problem. I created a Visual Studio C++ program which loads the SDL2.dll. That program does not crash.

Update password with NuGet

dotnet nuget update source <repository name> -u <username without domain> -p <password> 

The nuget config is located in: c:\Users\<username>\AppData\Roaming\NuGet\NuGet.Config"

Some common Visual Studio C++ errors and solutions in the settings

Unresolved external symbol _RTC_InitBase
Unresolved external symbol _RTC_Shutdown
-> Settings/C/C++/Code Generation/Basic Runtime Checks => Default

Unresolved external symbol __chkstk
-> Settings/C/C++/Command Line/Additional Options: /Gs0x100000
-> Settings/Linker/System/Stack Reserve Size => 0x100000
-> Settings/Linker/System/Stack Commit Size => 0x100000

Unresolved external symbol __imp___acrt_iob_func
Unresolved external symbol __imp___stdio_common_vfprintf
-> #define _NO_CRT_STDIO_INLINE
-> #include <stdio.h>

Unresolved external symbol _fltused
-> insert in the top of the code:   extern "C" int _fltused = 0;

Unresolved external symbol __security_check_cookie
-> Settings/C/C++/Code Generation/Security Check => Disable Security Check (/GS-) 

Visual Studio quirk:
Your own libraries should be on front of the Library Directories: So, $(SolutionDir)extern;$(SolutionDir)extern\sdl2\lib; $(VC_LibraryPath_x64);$(WindowsSDK_LibraryPath_x64)

Do this with all your directories, libraries. Put them in front of the rest.

If you "ignore all default libraries" in the link input. You must then change the main function in:

int mainCRTStartup(void)   --> console subsystem
int WINAPI WinMainCRTStartup(HINSTANCE hInstance, HINSTANCE prevInstance, LPWSTR cmd, int nCmdShow)  --> windows subsystem

If you want to copy your compiled .exe file, create a custom post-build event and fill in the following commandline: copy /y "$(OutDir)Ground.exe" "$(ProjectDir)..\..\GroundOutput\Ground.exe"

Ofcourse, you can also set the outdir in de General properties of the project.

unresolved external symbol "void * __cdecl operator new

When you do not use the default libraries with Visual Studio C++ you can come far with just linking to MSVCRT. However, you run into trouble when using C++ and classes. These use the new and delete operators.

According to the Internet it can be solved by just overloading the new and delete operators.

void* operator new(size_t size) { return malloc(size); }
void* operator new[](size_t size) { return malloc(size); }
void operator delete(void* what) { free(what); }
void operator delete[](void* what) { free(what); }

However, this did not work. I still got a error on the delete operator. So, what I did was transform the code:

GuiThread* guiThread = new GuiThread();
Became:
GuiThread* guiThread = (GuiThread*)calloc(1, sizeof(GuiThread));

guiThread->threadHandle = CreateThread(NULL, 0, GuiThread::StaticThreadStart, (void*)guiThread, 0, &guiThread->threadID);

delete guiThread;
Became:
free(guiThread);

Which process is using a port in Windows?

Start the  "Resource Monitor" on Windows 10/11 and go to the Network Tab. After that expand the Listening Ports Panel to see the processes and the ports they are using.

You can also use TCPView from the sysinternals suite. With the TCPView you can also terminate the process that is using the port. However, usually it is a service, so you might need extra effort to discover which service allocates the port.

In 32-bit Totalcommander, you see 32-bit DLL's in System32

The windows\system32 folder contains some frequently used DLL's.
However, remember that when you use a 32-bit Totalcommander, the system32 folder contains 32-bit DLL's.