DeSmuME SVN r4065 is released. DeSmuME is an open source Nintendo DS(NDS) emulator for Linux, Mac OS and Windows. DeSmuME supports save states, the ability to increase the size of the screen and it supports filters to improve image quality. DeSmuME also supports microphone use on Windows and Linux ports, as well as direct video and audio recording. The emulator also features a built-in movie recorder.

DeSmuME SVN Changelog:
win32: some minor clarifications to console behaviour. console behaviour is now verified to be pretty dang good in cygwin/msys bash as well as cmd.exe so long as you launch with "cmd /c desmume.exe".
win32: newer console title format, somewhat more useful. now %EXENAME% %ARGS% to show you how you launched it. let me know what you think. also let me know if it crashes while trying to parse something!
cheatSystem: headerId should be const
Fix memory block alignment in RomBanner for 4-byte wchar_t, #3354040

From rogerman:

The RomBanner struct requires UTF-16 strings for the six different ROM titles.
Currently, we use wchar_t buffers to define the memory blocks where the title
strings are supposed to go. Using wchar_t is fine for compilers that assume a
2-byte wchar_t. But compilers that use a 4-byte wchar_t will misalign
the memory blocks.

I've submitted a new patch that changes all the wchar_t in RomBanner titles
to u16 for all ports. It took me a while to research the dependencies on
titles, and to make sure I didn't accidentally break something in the
Windows port.

As for the wcscpy() deal in the RomBanner constructor, it's an arbitrary
default init value that we don't actually use in practice, so I removed it.
If a particular port wants to know what to display for the titles when a
ROM isn't loaded, there are plenty of ways to figure this out. Or they can
just check the titles for an empty string, which the constructor inits the
titles to before the wcscpy() call.

For CHEATS::save(), I removed the dependency on using titles. The ROM name
we write to file is also an arbitrary value which we don't actually
reference in practice. I changed it to use gameInfo.ROMname, since we're
already using gameInfo.ROMserial.