You'll find a large chunk of the Framework calls Windows-only code (ie the Win32 API), not just System.Windows.Forms.dll. However, it really doesn't matter.
The CLR simply abstracts a lot of platform specific code. It's a big wrapper for the most part.
Let's take the example of popping up a message box. In C#, you might write:
Code:
System.Windows.Forms.MessageBox.Show(this, "Hello world!");
Behind the scenes, the .NET Framework might call the Win32 API method:
Code:
MessageBox(NULL, "Hello, World!", "Default Caption", MB_OK);
And behind the scenes, Mono might make a call to something like:
Code:
// Note - I really don't care how Linux does it
xWindows.msgBox("Hello world!");
Now this would all be well and good. The Mono developers could have written the whole Windows.Forms library as a wrapper around the C code that does the same for XWindows.
The problem is, Linux and other window managers don't work the same as the ones on Windows. It doesn't matter that the code beneath them is different - the point is they are designed differently. You can do different things with GTK+ than with Windows Forms. So rewriting System.Windows.Forms would not have worked. That's why they use GTK+ (or is it GTK#? I don't remember, nor do I really care).
Reading files from the hard disk is the same no matter what OS you're using. That's why Mono and .NET probably both use System.IO. The Windows version of System.IO probably wasn't written with standard POSIX code, it no doubt calls Win32 API FILE * methods. The Mono version of System.IO might use POSIX compliant code so it runs on any OS. However, they both expose the same classes and objects.
So what I'm saying is it doesn't matter that the .NET Framework uses Windows only code - it's that System.Windows.Forms uses a Windows only design. A huge chunk of the framework probably uses Windows only code, but Mono is able to simulate the same functionality without it.