1306 – extern (Windows) should work like extern (C) for variables

In some cases, extern (Windows) causes '@0' to get added to the end of symbols that represent variables. This causes linking errors. I wasn't able to create a simple test case, but the problem should be clear.
Scenario:
I have a few hundred function pointers in a C library. To link with those, I have to use extern (C). But to actually call the functions, I need the function pointers to have type extern (Windows). Since extern (Windows) changes the mangling of the pointers, I can't link both link with the C library, and call the functions successfully. So I'm stuck, and probably need some ugly workaround.
I compiled 'int __stdcall x;' with msvc 6, which it accepted with a warning. Looking at the object file, the symbol was not affected by __stdcall. So DMD's behavior is probably wrong.

Please include a set of reproduction steps, including source code.

I nailed, it's another problem with the export keyword.
stdcall.d:
---
export extern (Windows) void (*funcptr)(int);
void main()
{
 funcptr(5);
}
---
Just to show how funcptr gets mangled:
c:\prog\test\D>dmd stdcall
c:\prog\dmd\bin\..\..\dm\bin\link.exe stdcall,,,user32+kernel32/noi;
OPTLINK (R) for Win32 Release 7.50B1
Copyright (C) Digital Mars 1989 - 2001 All Rights Reserved
c:\prog\dmd\bin\..\lib\phobos.lib(dmain2)
 Error 42: Symbol Undefined _funcptr@0
--- errorlevel 1
funcptr is mangled as _funcptr@0, which I believe is a stdcall function of zero arguments. This is clearly wrong, and won't link with the corresponding C definition of the function pointer.

Fixed DMD 1.019 and 2.003