using fte's sys_win.c, you could create a download thread with this:
struct dlthreadargs someglobal;
//called when you need a new file
void downloadbegin(char *url)
return; //already busy
someglobal.url = strdup(url);
someglobal.done = 0;
someglobal.threadhandle = Sys_CreateThread(downloadthread, &someglobal, 0);
//make it look like an error if it failed
someglobal.done = 2;
while (someglobal.threadhandle && !someglobal.done)
//called once per frame
return; /nothing happened yet
if (someglobal.done == 1)
memset(&someglobal, 0, sizeof(someglobal));
obviously you'll probably want to structure that a bit better, maybe.
poll on the done field once per frame, or whatever
fix up the indents or whatever
the download thread:
int downloadthread(void *arg)
struct dlthreadargs *a = arg;
a->done = 1; //success
a->done = 2; //error
see, easy... *cough*.
The actual glue inside fte's sys_win.c is for abstraction between win32 and posix, rather than any proper magic.
its up to you how you integrate it.
I just personally find threads easier than figuring out some way to pass arguments as something other than a basic pointer.
obviously, you have to avoid calling Con_Printf inside your download thread, you can use mutexes for that if you need it. alternatively you can write some error message field and have the main thread print it when it sees the child stopped. or create a ring buffer of pending prints. or something. if you were using an entirely separate process, you would have to perform some sort of Inter-Process Communication to get the message back into the main thread, system API functions to see if the child is complete, etc.
Threads are easier, if only because you have direct memory access. But you do have to make sure you don't call functions that are not thread safe (sticking only to functions termed as 'reenterant', which is generally considered good coding practice in the first place).