bsnes v0.034 released

[mudlord]

Odd, all the info I can find on it says it lacks SSSE3 and VMX. Sites talking about it must be confusing it with a Pentium 4 if it really is a Core 2.

Yep, the E2xxx series are actually Core 2 Duo based with reduced cache. They are also quite the overclockers....

[odditude]

if it's got a letter and a four-digit number, it's a core 2 derivative.

if it's got a three-digit number, it's a pentium 4 derivative.

the ONLY exception to this is the celeron 4xx-series, which is a single-core core 2 derivative.

[I.S.T.]

ToP translation fix, which won't break FEoEZ (which has a header in the HiROM region, despite being > 32mbits.)

Code: Select all

  if(cart.rom_size >= 0x401000) {
    if(rom[0x7fc0 + MAPPER] == 0x32) score_lo++; //star ocean
    else if(rom[0x40ffc0 + RESH] >= 0x80) score_ex += 16; //tales, dkjm2
    else; //feoez
  }

Isn't that a Pentium 4 family CPU?

It's labeled as one, but it's really a Core 2 Duo series with some defective cache that was disabled. But the cache doesn't help bsnes out that much. My E2160 @ 1.8GHz gets 60-90fps, and it can easily overclock to ~2.4GHz, so it should be more than enough.

The reason to like them is price: I paid $49 for mine, though it seems to fetch ~$59 on average. Still, much cheaper than the E8400 @ $159.

The E8400 is based off of the Penryn core, making it burn less power and clock much higher.

>.>

That said, as an E2160 owner who's overclocked it to 2.4 ghz, I love it.

[byuu]

New WIP.

First, the internal ROM header detected was enhanced. Nach was right, so I went ahead and did it the right way ... it'll score all three regions individually now, and then use some heuristics for those annoying games that duplicate the header entirely in multiple places. The hardest games to detect, that I recall, are Double Dragon and Street Fighter Alpha 2, which seem okay. In fact, all ~50 of the games I have seem to be working fine.
Please let me know if any games fail to start as of this WIP.

Second, finished updating all of src/memory to convert uint -> unsigned. Yeah, I like the former more, but the latter is a built-in type. Did the same to hiro, and converted Event to event_t, looks nicer in code. Part of namespace libhiro, so no worries about other things named event_t.

Third, added the frameskip cycling code. It just randomly chooses which of the set of frames to display (random() % (frameskip + 1)). Seems to work as expected, you can see Link blink when hit even with FS=1, but obviously it stutters a bit more.

Fourth, I finally added RedDwarf and Nach's latest ALSA code. ALSA will now with at 75% speed and with speed uncapped. It has the same overhead as OpenAL. So, unfortunately, due to OpenAL's issues with completely destroying echo / reverb for some reason, I'm going to have to recommend Linux users set system.audio to "alsa" from now on :/
FreeBSD users should rely on "libao".

I'd like to release an update this weekend to address the ToP issue, as well as a missing string in the translate[] hooks and to distribute the new ALSA updates. I'm worried about the header detection changes breaking some other games, though. So if you guys wouldn't mind throwing a bunch of random games at it, I'd appreciate it.

It should be fine, though. In theory, the LoROM / HiROM detection is identical to the last release still, but I did restructure it, so you never know ...

Oh, and I updated the website with new locales from Hatsuyuki, Itol, khiav and wushu. Thanks, guys!

[tetsuo55]

I would LOVE to take you up on that offer, but i would need a completely new system to replace my current crappy one

What's your current system like? (I'm also trying to remember where you live; I seem to recall you have a PAL SNES but that's as far as I got )

I actually have 2 systems that are able to run bsnes at more than 1fps.

Gaming/work mostly done on this laptop:
Celeron M 2.5ghz
1GB ram
40gb 4200rpm hdd
intel 9xx onboard videocard.

The pc is actually a HTPC and is almost always in use
AthlonXP 2600
1256MB ram
Several 7200rpm hdd's (for a total of 1TB)
Ati HD2400pro (How else would it be able to HTPC)
Sony 40" fullHD tv (emulator tearing almost makes you go blind on such a large screen)

As you can see neither of these are able to get 60fps with Bsnes nor are they upgradable in any way(every part will have to be replaced except for the tv and the pc hdd's)

it's pretty painfull to see the Atom CPU getting better fps with h264 720p decoding than my HTCP(when hardware acceleration is disabled)

So the problem with ZAMN is not an emulation bug but a problem with the frameskip option?

It sounds to me you've never seen frameskip look awful. In the FF SNES series of games, the cursor tends to flash when highlighting multiple targets with spells.. and when frameskip is used, you will occasionally see "fixed" cursor that either it totally missing or totally solid, which completely doesn't match what the original game does. Personally speaking, that is what you will be living with when frameskip is in use. That's more of a non-issue IMO than anything else.

Actually the behaviour is very unstable, Byuu already proved that ther problem extends way back but i hardly noticed any problems. I don't understand why though. Regarding the FF series i'm actually used to the problems in those games because they hardly work on a real copier too, especially FF6/3 has loads of problems(has to do with real bugs and bad dumps i guess)

By the way, I tried Zombies and it should be rather obvious why frameskipping makes it look "broken" tetsuo. The way it bounces up and down is equivalent to something blinking. If you're shifting an object from up to down, and all of the up frames are being cut out, it will appear as though it is stationary. Just like if a game is showing a sprite every other frame to achieve a blinking effect, and every other frame gets cut out by frameskip 1, it will either appear invisible or solid depending on the frame the effect was initiated.

I knew it had something to do with the frameskipping. Now that i think of it i had seen it before way back but thought nothing of it. The last few weeks i have been playing ZAMN constantly and the bouncing always showed, it wasn't until i tried 34.wip1 that the bouncing stopped(and then it still works half of the time as long you don't reset)

[Nach]

Third, added the frameskip cycling code. It just randomly chooses which of the set of frames to display (random() % (frameskip + 1)). Seems to work as expected, you can see Link blink when hit even with FS=1, but obviously it stutters a bit more.

I'm not so sure random is the best way to go about things here. If random() happens to return a multiple of (frameskip + 1), that'll be 0, which depending on your code might not display anything. If you're checking every couple of frames with random, it could happen to return a bad sequence which makes things not show for a while. I'm not entirely sure what requirements the standards committee has on rand(), but probably just that it has to have valid PSR cycle math, and hits every value from 0 to RAND_MAX. Which depending on the algorithm in play may not be anything close to what you want. It could also do the reverse and be displaying too many frames.

Overall, any rand() implementation over a thousand runs or so should give practically 50% of each bit in that run being on, giving equal share to each number in your range. But you could end up where the distribution isn't good for say only 50 runs making your game display too much or too little for a couple of seconds. I'd hate to be fighting a tough boss, and then not see anything for 3 seconds.

You might be better off if you came up with a sequence that can be cycled for when to display frames. If you need some rand involved, you might be better off using a rand when a sequence is completed to choose between multiple sequences.

Although I'd probably be better off looking at your code as a whole before saying anything, since you probably prevented all this by using random in a more intelligent matter than I'm extrapolating from the small snippet posted, and I'm just displaying my worries over a moot point.

So, unfortunately, due to OpenAL's issues with completely destroying echo / reverb for some reason

Please give me some very noticeable examples, so I can look more into this, and perhaps fix it.
What about OSS and AO, do either of them break echo/reverb?

It should be fine, though. In theory, the LoROM / HiROM detection is identical to the last release still, but I did restructure it, so you never know ...

If the code is good from a logical standpoint for handling the issues in a clean and sane manner, you only have to worry about the really messed up dumps.

While IIRC Super Double Dragon, and Super Street Fighter 2 E had multiples, they weren't crazy.

IIRC, Ys III J has 31 different headers in the ROM, and the Batman Revenge of the Joker Beta has one header which looks perfectly good but it's fake, and you have another which is the right one, but looks bad. That's what I'd look at.
Also, there is a hacked BRotJ Beta floating around where they swapped the bad header with the good one, so everything handles it right, testing that one doesn't tell you anything. So double check with NSRT that the one you have is listed, and not a hack.

[I.S.T.]

So, unfortunately, due to OpenAL's issues with completely destroying echo / reverb for some reason

Please give me some very noticeable examples, so I can look more into this, and perhaps fix it.
What about OSS and AO, do either of them break echo/reverb?

it's one of the SPC7110 games. I think Super Power League 4. It was listed in one of the recent topics, but I can't remember which one. Might even be this one on the first page.

[byuu]

Well, hold off on the testing, I guess. Seems ToP scores equally for HiROM and ExHiROM, so I'll have to change the scoring from LoROM >= HiROM >= ExHiROM to ExHiROM >= LoROM >= HiROM.

EDIT: Ys 3 (J) was easy, Batman: RotJ is insane.

Code: Select all

00007FC0 0000 0000 0000 0000 0000 0000 0000 0000 ................
00007FD0 0000 0000 0000 0000 0000 0000 0000 0000 ................
00007FE0 0000 0000 9D92 9D92 9D92 7C92 9D92 9E92 ..........|.....
00007FF0 0001 AACC 9D92 9D92 9D92 0080 0080 9E92 ................
...
0000FFC0 4241 544D 414E 2D2D 5245 5645 4E47 4520 BATMAN--REVENGE 
0000FFD0 4A4F 4B45 5231 000A 0001 BB00 4302 BCFD JOKER1......C...
0000FFE0 4C70 E8AD 2A03 2900 8009 0100 2254 C381 Lp..*.)....."T..
0000FFF0 AD2A 03F0 0AAD 0003 2900 02D0 1180 08AD .*......).......

Try and guess the valid header.

you probably prevented all this by using random in a more intelligent matter than I'm extrapolating from the small snippet posted

Yes, what I do is have two counters: one that loops through frames+1 that increments linearly, and and another that is set to rand() % (frames+1) once the first counter wraps to zero. The PPU is enabled only when the first counter matches the second's random value. blargg tested it, it works as expected.

Of course, it does have the usual distribution problems of rand(), you could have really bad luck with FS=1 and see nothing but frame 0 (of 0, 1) every single time. A lot like flipping a coin, obviously.

A ping-pong method probably would've worked as well, but eh. Didn't want to spend a lot of time on it, and I like the random distribution anyway.

Please give me some very noticeable examples, so I can look more into this, and perhaps fix it.

Listen to the female announcer when you start "Pennant" mode in SPL4. She should should like she's speaking through a megaphone, and not two feet away from you.

What about OSS and AO, do either of them break echo/reverb?

I'll let you know shortly.

So double check with NSRT that the one you have is listed, and not a hack.

Wow, some strange stuff out there ... if you have an exact list of games, I'll test all of them to be safe.

[I.S.T.]

I'm gonna go test all the games in stages. Up to B or C for the first. I'm using the No-Intro set.

Edit: Fuuuuuuuuuuuuuuuuuuuuuuuuuuuuck I forgot zip support is disabled in the WIP builds. this is going to take a bit longer than I thought. >.<

[byuu]

You'll want to hold off at any rate. Making some drastic changes to get Batman: RotJ working.

I'll post a new WIP later on with ZIP support for testing. Many thanks in advance.

[henke37]

Are we going to play with neural networks soon?

[I.S.T.]

You'll want to hold off at any rate. Making some drastic changes to get Batman: RotJ working.

I'll post a new WIP later on with ZIP support for testing. Many thanks in advance.

You say that after I test like 14 games, making sure each game can get to gameplay and actually work.

>.>

BTW, I noticed something odd. with the frame limiter off, the Japanese version of Actraiser runs 10-20 FPS faster than the other versions. o_O

Edit: BTW, don't worry about zip support for my sake. I forgot winrar can mass decompress.

Very, very stupid of me.

[Hunter]

I'm going to update my locale file ASAP. By the way, excellent release .
-----
Edit

Updated: Brazilian Portuguese.

[Nach]

EDIT: Ys 3 (J) was easy, Batman: RotJ is insane.

I found the former very easy too. I didn't even know there was an issue with it, till MK mentioned it was giving him some trouble in Snes9x. No idea why though, although the 31 headers in it is quite unique. Might be because he was trying to do interleave detection alongside it. Which I can tell you from lots of experience can be very tricky to detect properly, although Ys 3 J never gave me a problem when I was writing NSRT. Glad you can appreciate BRotJ, that drove EVERYONE nuts, it's the one wrench in all sane code.

Please give me some very noticeable examples, so I can look more into this, and perhaps fix it.

Listen to the female announcer when you start "Pennant" mode in SPL4. She should should like she's speaking through a megaphone, and not two feet away from you.

Okay thanks. I'm busy till tomorrow evening, I'll see what I can do then.

What about OSS and AO, do either of them break echo/reverb?

I'll let you know shortly.

Please do, I prefer to be forewarned about what I'm getting myself into.

So double check with NSRT that the one you have is listed, and not a hack.

Wow, some strange stuff out there ... if you have an exact list of games, I'll test all of them to be safe.

I don't have a list of insanity on hand. My basic test suite for NSRT though included a lot of crazy interleaves which doesn't interest you, and then a few oddball games and games which fell into certain criteria which I liked to double check.

Offhand:
BRotJ, SM, SMW, ToP, DKJM2, FEoEZ, SO, SMRPG, Tokemeki Memorial (or however you spell that), Super Bomberman.

Although my test suite is more complicated, since it has four different versions of ToP and DKJM2, with the two ROMs merged each possible way.

[tukuyomi]

http://kuro-hitsuji.net/~tukuyomi/stuff ... french.zip

French localization updated for v0.034. Congrats for this new release and the work done on the SPC7110 decompression .

[Fes]

First off, great release.

I've always found video/audio sync interesting, so I thought "hey, why not tinker around with it and see how badly I can break things?"I'm quite rusty at C++ (to put it mildly), but I thought I'd try anyway; might be fun, and at least make for a funny story. So I set off trying to get it to build. I used to use MinGW back in the day, but I noticed your makefile had a msvc target (thanks for including that btw), and I'm a huge fan of their IDE, so I decided to use vc++ express 2008. To cut to the chase, I eventually got it to build and run, but there were snags along the way, so I just thought I'd detail what happened in case anyone else tries it, or just to get feedback if I'm doing it wrong.

• First thing, CL bailed out when it hit the base64 encoded string in controller.h. Apparently it has a limit of 65535 bytes for string literals. A quick and dirty hack to get past this was just to cut it into 2 pieces and strcat them together in resources.cpp. Alternatively, I probably could have added it as a resource, but express doesn't have the resource editor so I went for the crude solution.
• Next, in dictionary.hpp, the first for loop uses 'i' as its counter, then declares 'i' again inside the loop body for additional work. CL complained about redeclaration. I wasn't sure what to make of this at first, if it was a clever self-modifying loop, or intended to shadow the loop counter. After reading it through several times I decided it was probably the latter and renamed it to 'j' which fixed it. Is it part of C++0x to be able to shadow like that, or is it a GCC extension?
• Cartridge::get_base_filename and Cartridge::apply_patch both claim to return a value, but don't seem to do so. Wasn't sure what to do here so I just had them return NULL/false.
• Express doesn't come with OpenGL headers, so I got the platform SDK. glext.h was still missing after this though, so I downloaded it from the opengl site, which did the trick.
• spc_dsp.h, nal/file.hpp, and ups.hpp all attempted to include stdint.h, which isn't part of vc++. I downloaded a 3rd party implementation which worked, but then nall/stdint.h failed with redefinition errors, so I commented out the platform check and had it include the standard stdint.h. Are those files perhaps meant to include nall/stdint.h instead of the standard one?
• pEditbox::get_text seems to declare a dynamically sized stack array, which CL balked at. I think that's part of the C99 standard, which GCC surely implements. I just replaced it with a dynamic buffer to get around it.

Anyway, it builds and seems to run fine now, so I'll keep tinkering. Maybe next I'll try to make a project file instead of relying on external make. Your code and makefile are very neat and tidy though, props for that; made it pretty easy to find my way around and get things working. I hope any of this was helpful, and keep up the good work.

[byuu]

New WIP, with major changes to internal header detection.

This should get everything working, if we're lucky. It does get Batman: RotJ working for the first time, as well as all the fan translations.

I'm releasing it publicly, as I need all the help I can get with this one. Windows binary with ZIP+JMA support included along with source for the penguins.

Code: Select all

byuu.org/temp/bsnes_v034_wip03.zip

Do note that I left the console enabled in the binary. It's not a release-grade version, anyway. But the main reason was to print the scoring information. If any games fail, I'd like that information posted. Might be good to note really close passes, as well, so we can keep an eye on them for future changes. Right now, I'm only aware of SFA2 that gets really really close.

Basically, it prints the address it tests for a header at, the score it ended up getting, and the reset vector's first opcode. If the values are equal, it defaults to LoROM, then HiROM, then ExHiROM. If the reset vector is invalid, or the ROM is too small to contain a header at a certain offset, you won't see any output for that line! That means a lot of times, you'll only see one line output, and sometimes you'll see two or three. No worries, just assume missing means total fail. It only prints output for "possible" header locations.

If you do test, you don't have to play in-game or anything. The second you see any visible output whatsoever, that's good enough.

Many thanks to everyone who tests in advance :D

----------

Hunter and tukuyomi, thank you for the kind words and localizations :)

I really hate that table on the download page, and I need to go through and get names out of all of the locales, but I'd like to get an "Author:" field in that table on the download page. Sorry it's not there just yet.

----------

Fes, thanks for the feedback.

Apparently it has a limit of 65535 bytes for string literals.

I don't have a workaround for that. For whatever reason, ISO didn't add an "incbin"-style command, and I need a platform-agnostic way of encoding binary data.

Not for v035, but maybe a while after that, I'll use a more advanced compressor to get the controller below 64kb of string data. Maybe I can rig my order-0 arithmetic coder onto the end of LZSS for a quick and dirty size cut. The reason I don't use 0xnn, 0xnn, is because that takes 5 bytes of source to encode one byte of input, whereas base-64 strings only take ~1.25 bytes. I didn't want those files to slow down compilation much.

# Next, in dictionary.hpp, the first for loop uses 'i' as its counter, then declares 'i' again inside the loop body for additional work.

Oops, sorry. Didn't get a warning on GCC, so I overlooked it. This is now fixed.

# Cartridge::get_base_filename and Cartridge::apply_patch both claim to return a value, but don't seem to do so.

First should return the filename, it's just a convenience thing to allow chaining commands. The second should return result of patching. I've fixed both now, thanks.

# spc_dsp.h, nal/file.hpp, and ups.hpp all attempted to include stdint.h, which isn't part of vc++. Are those files perhaps meant to include nall/stdint.h instead of the standard one?

Microsoft really pisses me off by intentionally ignoring stdint.h. nall/stdint.hpp was meant as a workaround, so that I didn't have to special case Visual C++. The idea was to not require you to get one of those third-party add-ons.

So yes, two of those were a mistake on my part, I used stdint.h on them before I created my own stdint wrapper. I've corrected both.

As for spc_dsp.h, that shouldn't be compiled. That is for blargg's reference, unmodified S-DSP emulator. The ones modified to work in bsnes do not require it. And in fact, only src/dsp/sdsp will compile at the moment due to memory map changes.

# pEditbox::get_text seems to declare a dynamically sized stack array, which CL balked at.

Hahah, yeah, that would be C99 syntax. Very nice, that.

Looks like I was allocating length*2 wchars, too. I don't know why I was doing that ... I don't think Microsoft's system even supports the extended Unicode symbols that need more than 16-bits, and even if so, they aren't likely to appear in the emulator.

Dropped that back to length+1, and made it use new[]/delete[], instead. That's one horribly inefficient routine by the way, but whatever, it works for now.

The rest I can't do much about, sorry. Hopefully it'll make it easier for you to compile in the future. Sorry for letting the port slip, I just don't have the patience to load VS2k5 again. Software takes like three hours to install >_< and creates slower code than GCC4 anyway. If they'd fix their damn PGO support, I'd be all over it again, though.

[I.S.T.]

I think I found a bug. Aryol's first screen(The one that shows who published it) has part of a letter in the upper left corner of the screen. It's the same font as either the word Presents or the first letter of the company's logo.

I forgot to mention I'm using the dump found on No-Intro's list and there's only one version of the game(unless it was renamed when released anywhere other than Japan.).

[byuu]

I'm pretty sure we noticed a lot of these during the initial test run a long time ago. They just happen to get cut off by TV overscan, so nobody noticed them. I know there's a game called Yuujin 2 something that does this a lot, for instance.

Not saying this isn't a bug, per se.

[I.S.T.]

Ah, sorry then.

Tested all games up until B. Aside from one being an SA-1 game, all worked.

[byuu]

Well, it may still be a bug, so thanks for mentioning it. We'll leave it to FitzRoy and tetsuo, as they tested all bsnes-observed bugs on hardware already, so they'd probably remember this one. Food for thought: what about games that looked right in bsnes, but really should display some form of corrupted graphics on hardware? :P

Tested all games up until B. Aside from one being an SA-1 game, all worked.

Very much appreciated, thank you! Please don't wear yourself out too much though :)

A-B is a pretty good sign that the detection should be good enough. The only way a game is going to get me is if it has a valid reset vector (1:2), that points to a very common opcode for a reset vector (eg 'sei') (1:24), and that has a completely invalid header where the real one should be -- yet a valid header where it should not be (only observed in Batman: RotJ so far, which I can detect because the reset vector for the bad header points to a junk opcode.)

We could probably just test all the beta / PD / known-troublesome games and call it a day at this point. Unless you wanted to test more, of course. I won't complain about that :)

[I.S.T.]

Well, it may still be a bug, so thanks for mentioning it. We'll leave it to FitzRoy and tetsuo, as they tested all bsnes-observed bugs on hardware already, so they'd probably remember this one. Food for thought: what about games that looked right in bsnes, but really should display some form of corrupted graphics on hardware?

Tested all games up until B. Aside from one being an SA-1 game, all worked.

Very much appreciated, thank you! Please don't wear yourself out too much though

A-B is a pretty good sign that the detection should be good enough. The only way a game is going to get me is if it has a valid reset vector (1:2), that points to a very common opcode for a reset vector (eg 'sei') (1:24), and that has a completely invalid header where the real one should be (only observed in Batman: RotJ so far, which I can detect because the reset vector for the bad header points to a junk opcode.)

We could probably just test all the beta / PD / known-troublesome games and call it a day at this point.

Haven't tested B yet. >.> I meant up to B. Sorry, I can't communicate worth a shit.

I'll do B and C later.

[Fes]

Thanks for the fixes; I'll keep my eye out for anything else. A few warnings I forgot to mention:

• Several assorted warnings about mixing bool with integral types in comparisons and applying unary '-' to them. Added warning suppression flags for 4804 and 4805.
• Not all code paths in dictionary::import return a value. Not sure if true or false is your success code, so just left it for now.
• CL warns about unknown option '-static' when compiling libco.

If they'd fix their damn PGO support, I'd be all over it again, though.

I've been out of the native code loop for a while now (get it? loop?) so I was unfamiliar with that. After looking it up it sounds pretty cool. If you give me a quick rundown of the problem I'd be willing to investigate a bit with 2k8 pro once I get it.

[byuu]

* Several assorted warnings about mixing bool with integral types in comparisons and applying unary '-' to them. Added warning suppression flags for 4804 and 4805.

Have example expressions that trigger the warning? I'll look into it more from there. I do rely on intrinsic boolean casts sometimes, eg:
uint16_t reg;
bool negative = reg & 0x8000; //0 = false, 1 = true

Whereas I know the "PC" way of doing it is bool negative = static_cast<bool>((reg >> 15) & 1) -- at least, judging from all the code I always get stuck looking at >_>;

# Not all code paths in dictionary::import return a value. Not sure if true or false is your success code, so just left it for now.

I need to find a GCC setting to warn on no return value. I'm sure it's there, just don't know it off the top of my head. Thanks, I'll get these as well.

# CL warns about unknown option '-static' when compiling libco.

Weird, that should only be added for GCC. It's technically only needed for the Mac libco, but it doesn't hurt the Windows / Linux one, so why specialize it further?

If you give me a quick rundown of the problem I'd be willing to investigate a bit with 2k8 pro once I get it.

Make a PGINSTRUMENT build, run a few games for ~5 minutes (1 minute a piece, probably won't even get in-game in that amount of time), now put the generated pgc/pgd or whatever files into the same folder as your objects, and run a PGOPTIMIZE build. It will error out with an internal compiler error, advising you to contact Microsoft. No, I'm not going to contact them about my little freeware software project.

It tells me to try simplifying code on sCPU/core.cpp, on the line it specifies, it contains only "status.in_opcode = false;" -- you tell me how to simplify that :P

In all seriousness, it's probably choking on the switch(opcode) loop above, with the 256 entries. I tried replacing the switch table with (this->*optable[opcode])(), but it gives the same error during compilation either way.

It's apparently a problem lots of people on the internet are having if you Google the error message, and nobody ever gets it fixed.

[Nach]

If you want me to look into it, I can see about getting you PGO builds on Windows (although not with MSVC), I used to do it all the time on Windows with GCC 3, and still do it on Linux with GCC 4.