Ryan,
1&2:
Typically what happens is the programmer can enumerate the supported
exclusive (full screen and dedicated to a graphics context) resolution
modes. The available resolution modes is dependent on their monitor, video
driver, and operating system. Each mode defines a width and height in
pixels, the color depth, and refresh rate. When the programmer creates a
window they need some way to find, or enumerate, these modes, and they also
need a way to switch the window and context to fit one of these modes.
These are all things that should be supported by the underlying graphics
toolkit. That is, the toolkit should allow the programmer to find out what
modes exists on the end users computer, and pick one of those modes
possibly before creating the window and context.
3:
The OpenGL API functions such as glGenBuffers, or glUseProgram are provided
by either an open source community, or from the operating system, or from
the hardware manufacturer driver. You cannot statically link these
functions to a so (shared object) or dll (dynamic link library) at compile
time, because based on the users configuration they reside in several
possible locations. For example on Linux when an OpenGL ES 2 context is
needed the OpenGL functions must come from libGLESv2.so located in in a
vendor specific lib folder created by nVidia. For a core context the
libGL.so is a different name and located in a different folder. It is the
job of the toolkit to determine based on the request context type which
OpenGL library should be loaded. That library should then be passed back to
the programmer so that he can link to the correct OpenGL API for the
context he requested.
Each platform Windows, Linux, and Mac have their own APIs to make it easier
to find the correct OpenGL library. Windows has wgl, Linux has egl, and mac
has something else. Your toolkit should at least cover the differences in
wgl, egl, and the Mac API so that programmers don't need to add their own
wgl or egl code.
The Free Pascal LoadLibrary and FetProcAddress should be sufficient enough
to load the appropriate OpenGL function if you can tell then either the
path to the OpenGL library, or more realistically the handle to the already
OpenGL library already loaded by you.
Regarding extensions, each platform and library has their own
implementation of how to get the address of an OpenGL extension. On Windows
you can use wglGetProcAddress, while on Linux you would use
wglGetProcAdress. Your toolkit should provide an abstraction so that it's
doesn't matter which platform you are on and the extension loading is
handled the same.
4:
In your source code for Windows you are using GetTickCount to return the
time. See this stack overflow answer to see why that's a bad thing.
https://stackoverflow.com/questions/24009263/why-queryperformancecounter-and-gettickcount-does-not-keep-in-pace
The code I provided you should give high resolution timing on all
platforms. Use it if you want, but please don't rely on GetTickCount for
time on Windows.