I want to write my own operating system (well, in fact I only want to find out more about the OS construction by means of diving into it, but that doesn't matter). The question that worries me a lot is how to write a bootloader that is aware of both old-fashioned BIOS firmware and brand new UEFI. As far as I can understand, at least the execution environment for the two cases will be different.

So, where should I start from if I want an OS to be oth BIOS- and UEFI-aware?

[Obviously, I'd like to use FASM only, no C/C++/C#/Java/AnyOther"Cool"ProgrammingLanguageUselessInOSDev]

Not possible, you must have different loaders for both, For BIOS your loader wI'll have to manually switch to Long Mode, while UEFI already sets up the processor for you. BIOS uses boot sector method while UEFI will load an entire Image from a FAT Formatted Volume. One way could be that your boot sector or EFI Image can pass a value in a register ex: EDX will be set to 0xFFFF if firmware is UEFI and 0x004F if firmware is BIOS, then your loader can check the value of EDX and accordingly execute code.
And BTW C is the language of OSDev, all the major operating systems are written in C (Windows, Linux, BSD), and C provides maximum portability and control (lesser than assembly though), C has been used for OSDev across platforms, it's considered unusual by most programmers if you're using assembly for OSdev, but C fanboys don't know the power of assembly they're lost in their own world, it's like writing a poem in Spanish using Google Translate to translate it to English and then wondering why no one likes it. (JohnFound's Signature iirc)

I see. I'll ask one more question. I'm currently not sure if my own notebook has UEFI support. What things should I be aware of to minimize the amount of code to rewrite when (if?) I finally switch to UEFI?

hi DimonSoft,
To check whether you notebook supports UEFI booting just go into the Firmware settings and you should
see a "Secure Boot" and an "Enable UEFI Boot Option", if your laptop is younger than 5 years it should support UEFI (although UEFI came in 2006, but many vendors didn't support it that time).
1. Never ever ever ever ever × π ÷ 0 use BIOS Interrupts in your kernel, you should rely on your boot loader to pass information in a standard way. All at the most you'll need the memory map and video mode information,
Boot Drive Information and absolutely nothing else. If you're new you MAY use SMM code like writing a driver for a PS/2 Keyboard. However you must get through this quick, write a USB interface, then work on a an HID implementation and grab data from the Keyboard without using PS/2 Emulation. A USB Stack isn't a trivial approach and if you're writing a USB Stack in assembly, it's a overkill.
Back on topic, do not rely on SMM code very much.
2. Never ever ever ever × π ÷ 0 switch back to Real Mode or use Death 8086 Mode, just forget about that.
If you want to switch video modes after boot, then I'd say it's a crap choice. What you could do is configure the maximum resolution that is supported by the monitor on boot (ask the user), and emulate a specific resolution inside the screen. Say the monitor is 1366×768 pixels wide, and a program requests for say 640×480 resolution, what you can do is fool the program by making it believe it's a 640×480 screen and then make the draw limits smaller, so the user will see a small 640×480 box inside the screen, that is a screen inside a screen!