Strange encoding in Slackware

The on-topic part: yes, you can run a virtual machine under Ubuntu.

CUDA requires direct access to the hardware. That means you'll have to run Windows either directly on the hardware or on a virtualization engine that allows a virtual machine to access hardware devices directly. That pretty much means hypervisor-based virtualization. VirtualBox is definitely out. Google suggests that Xen will do.

Running a single Windows installation in different hardware configurations (such as the bare metal and a virtual machine) is notoriously difficult. If you really don't want to install Windows, you might prefer to run Ubuntu in a VM under Windows.

It's not clear from your question whether you also want to run CUDA programs in Ubuntu. If you do, you can boot your existing installation on pretty much any hardware, there's little if any setup required. This does require a virtualization system that can bind a disk partition inside a VM, which I think VMWare can do but not VirtualBox. (It's also possible with VirtualBox by making a custom initrd with the vboxsfs module, but that's no longer no-setup-required. An alternative method is to clone the system partition to a virtual machine disk.) ADDED: You might want to investigate AndLinux, which is a port of Ubuntu to CoLinux, a Linux port running on top of Windows; I don't know whether CoLinux can support CUDA.

Given your workflow, I think your best bet is Xen. If this turns out not to work so that you need to dual boot, note that both OSes support hibernation, so with the right setup you can switch relatively quickly between the two (without needing to log in, restart all programs, etc.).

Short answer: restrictions imposed in Unix/Linux/BSD kernel, namei() function. Encoding takes place in user level programs like xterm, firefox or ls.

I think you're starting from incorrect premises. A file name in Unix is a string of bytes with arbitrary values. A few values, 0x0 (ASCII Nul) and 0x2f (ASCII '/') are just not allowed, not as part of a multi-byte character encoding, not as anything. A "byte" can contain a number representing a character (in ASCII and some other encodings) but a "character" can require more than 1 byte (for example, code points above 0x7f in UTF-8 representation of Unicode).

These restrictions arise from file name printing conventions and the ASCII character set. The original Unixes used ASCII '/' (numerically 0x2f) valued bytes to separate pieces of a partially- or fully-qualified path (like '/usr/bin/cat' has pieces "usr", "bin" and "cat"). The original Unixes used ASCII Nul to terminate strings. Other than those two values, bytes in file names may assume any other value. You can see an echo of this in the UTF-8 encoding for Unicode. Printable ASCII characters, including '/', take only one byte in UTF-8. UTF-8 for code points above does not include any Zero-valued bytes, except for the Nul control character. UTF-8 was invented for Plan-9, The Pretender to the Throne of Unix.

Older Unixes (and it looks like Linux) had a namei() function that just looks at paths a byte at a time, and breaks the paths into pieces at 0x2F valued bytes, stopping at a zero-valued byte. namei() is part of the Unix/Linux/BSD kernel, so that's where the exceptional byte values get enforced.

Notice that so far, I've talked about byte values, not characters. namei() does not enforce any character semantics on the bytes. That's up to the user-level programs, like ls, which might sort file names based on byte values, or character values. xterm decides what pixels to light up for file names based on the character encoding. If you don't tell xterm you've got UTF-8 encoded filenames, you'll see a lot of gibberish when you invoke it. If vim isn't compiled to detect UTF-8 (or whatever, UTF-16, UTF-32) encodings, you'll see a lot of gibberish when you open a "text file" containing UTF-8 encoded characters.