Avira and VirtualBox Broken

tldr: Avira face punches VirtualBox. Need other virus scanner.

I was using Avira, because it is the best free virus scanner. And I am using VirtualBox for sandboxed Windows, local Linuxes, as docker container host, etc...

...but recently they stopped working together.

Over 2 weeks VirtualBox VMs were increasingly less likely to start. I needed some time and googling to find out that Avira prevents the VM from starting. Disable Avira: still nogo. Uninstall Avira: VirtualBox works. Reinstall Avira: VirtualBox broken again.

See: https://forums.virtualbox.org/viewtopic.php?f=6&t=68869

Time to move on to a different virus scanner.

_happy_googling()

Copying Large Files on Windows

Copying large (>50 GB) files seems to be a problem on Windows (XP). Windows Explorer fails after some time with "Insufficient system resources exist to complete the requested service. (error 1450)". I use GoodSync as a folder syncing program. It has the same problem. I even have a commercial license, because I use it for software deployment on WebDAV and other remote file systems. Suprisingly this commercial file copy program also fails after about 50 GB.

GoodSync support told me "i am not sure why you expect that windows can handle 85 gb file". Good joke. This is the 21st century, guys. Why should it not? Apparently, GoodSync uses the Windows function CopyFileEx. Probably the same as Windows Explorer. I don't know what's wrong with CopyFileEx. There is an old MSDN knowledge base article (kb259837), which admits a problem and continues, that it has been fixed in Windows 2000 SP2. Since Win XP is just an updated Win 2k (XP major version 5.1 compared to 5.0, Vista is 6.0), I suppose the problem is also fixed in XP.

I wrote a simple copy program using the POSIX API (fread/fwrite) which uses Win32 ReadFile under the hood instead of CopyFileEx. Just works. It does as many MB/sec as physically possible, and uses only 1.6 MB memory. So, what's the problem?

Considered my half page of code, CopyFileEx really sucks. The funny part is, that while copying large files in Windows Explorer makes the PC unresponsive and is no fun, my small program copies peacefully in the background. I am so good. Or is CopyFileEx just so bad? Probably the latter. There is nothing special with my code. No fancy tricks, just the basic 1st year CS bachelor stuff.

Lets call it "scopy" for simple copy because all things I do are not stupid, but simple:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[])
{
 if (argc != 3) { printf("Usage: %s src dst\n", argv[0]); return 1; }

 char const *szSrc = argv[1];
 char const *szDst = argv[2];

 FILE* fSrc = fopen(szSrc, "rb");
 if (fSrc == 0) { printf("Error opening %s\n", szSrc); return 1; }

 FILE* fDst = fopen(szDst, "wb");
 if (fDst == 0) { printf("Error opening %s\n", szDst); return 1; }

 size_t nSize = 1024*1024;
 unsigned char* pBuf = new unsigned char[nSize];
 if (pBuf == 0) { printf("Error allocating %d bytes\n", nSize); return 1; }

 int nCnt = 0;
 __int64 nTotal = 0;

 bool bDone = false;
 while (!bDone) {
   size_t nRead = fread(pBuf, 1, nSize, fSrc);
   if (ferror(fSrc)) {
     perror("Read error"); return 1;
   } else {
     size_t nWritten = fwrite(pBuf, 1, nRead, fDst);
     if (ferror(fDst)) {
       perror("Write error"); return 1;
     }

     nCnt++;
     nTotal += nWritten;

     if (feof(fSrc)) {
       bDone = true;
       printf("\n%I64d\n", nTotal);
     } else {
       printf("%d ", nCnt);
     }
   }
 }

 delete[] pBuf;
 pBuf = 0;

 fclose(fSrc);
 fclose(fDst);

 //char c = getchar();

 return 0;
}

_happy_copying()

Applikationen sind auf Windows instabiler, als auf Linux

Warum? Weil Windows besser ist. Nochmal: Windows ist besser, deshalb sind Applikationen in der Praxis instabiler.

Windows bietet unendlich viele Systemkomponenten. Viele Dienste, die man im taeglichen Programmierleben braucht, bietet Windows als API. Das faengt an beim XML Parser, ueber HTTP mit Caching, URL-Behandlung, Embedded Browser, Verschluesselung, bis zu Sicherheitsdiensten und vielen anderen mehr. Als Programmierer bin ich froh, das alles nutzen zu koennen. Warum selbst implementieren, wenn das Betriebssystem das alles bietet? Auf Linux gibt es das alles nicht. Zumindest nicht als System-APIs. Natuerlich gibt es XML-Parser, Verschluesselung, HTTP-Libraries und Browser zum Einbetten. Aber man muss sie sich meistens im Netz beschaffen, selbst nochmals wrappen, moeglicherweise selbst kompilieren und dann dazulinken. Sehr muehsam, wenn man viel braucht, weil diese Komponenten auf Linux (oder Open Source) im allgemeinen eben aus verschiedenen Haenden kommen. Alle mit eigenen Coding Conventions und Interface Conventions.

Bei meinen Windows Anwendungen linke ich gegen LIBs, und benutzt werden dann vom Betriebssystem bereitgestellte DLLs. Bei Linux linke ich die libXX.a oder lege die Shared Libraries dazu. Meine-Windows Anwendungen haben damit Laufzeitabhaengigkeiten vom System. Meine Linux-Anwendungen sind selbst-konsistent. Jetzt kommt eine neue Betriebssystem Version oder (schlimmer) eine Bugfix Release (auch Service Pack genannt). Dann fliegen mir die Installationen der Kunden um die Ohren, und zwar fast nur die Windows Installationen.

Das kommt so: angenommen es gibt bei jedem Systemdienst, den ich verwende eine 0,1 % Wahrscheinlichkeit, dass sich die Semantik einer Schnittstelle, oder das Verhalten oder Abhaengigkeiten geaendert haben. Ich verwende 20 solcher Systemdienste. Ich habe 20 Kunden. Das ganze ueber 5 Jahre bei 8 Systemupdates pro Jahr plus 8 "signifikanten" Konfigurationsaenderungen des Kunden intern. Macht zusammen 30 Notsituationen in denen betriebskritische Dienste beim Kunden nicht laufen. Diese addieren sich zu den ueblichen Bugs, die es eh schon gibt und die erst bei "ungewoehnlicher" Bedienung auftreten. Bei jedem Kunden also zusaetzlich 1-2 mal. Fuer mich bedeutet das alle 2 Monate Emergency-Debugging am Livesystem waehrend der Betrieb eines Kunden steht.

Manchmal wuensche ich mir, Windows waere nicht so gut und ich wuerde alle Dienste wie auf Linux selbst einbinden muessen. Auf jeden Fall sollte man auch bei Windows statisch binden.

_happy_coding_

Das ist die perfekte Quelle, der perfekte Tag

Gestern war noch alles finster: Ein Videoserver, der im ::free so gnadenlos abraucht, dass sogar der Debugger (MSVC) beendet und kein Land in Sicht. Der Videoserver benutzt ffmpeg, das leider nicht im MSVC kompiliert. Deshalb mit cygwin kompilieren, dann LIB generieren aus einem zusammengeschusterten DEF file und .so in DLL umbenennen. Geht, ist aber nicht toll. Vor allem benutzt die DLL dann offensichtlich das cygwin Memory Management, dass unabhaenging ist vom VC++ Memory Management. 1. es braucht die cygwin1.dll und 2. das Memory Management kollidiert in manchen ffmpeg Funktionen. Das geht besser:

Wenn man ffmpeg fuer ein Windows MSVC Projekt will, dann kompiliert man ffmpeg mit MinGW. configure --enable-shared erzeugt anstandslos LIB und DLL fuer avformat und avcodec. Der grosse Vorteil: die DLLs brauchen keine cygwin Runtime, sondern verwenden die MSVC runtime, toll.

Wie installiert man MinGW: Bei mir ist schon Cygwin drauf. Das wird empfohlen, denn dann hat man alle Entwicklungstools einschliesslich make. Dann MinGW-3.1.0-1.exe, danach MSYS-1.0.10.exe. Der heutige ffmpeg CVS-snapshot kompiliert uebrigens nicht mit MinGW. Ich verwende deshalb ffmpeg-0.4.9-pre1.

Und deshalb habe ich heute die perfekte Quelle: MSVC mit ffmpeg.

Nachtrag (01.12.2005): ffmpeg-0.4.9-pre1 hat in Spezialfällen Thread-Synchronisationsprobleme. Die Probleme bei der CVS Version wurden inzwischen behoben. Deshalb verwenden wir jetzt wieder die CVS Version.

_happy_coding_