Home | Reviews | GUIpedia | Forum | Fun500

BrandonHow it will work.
If you know how GOPOS works ignore this first part. GOPOS has temp files that programs save and then new apps load them so its almost perfect taskswitching. The 1 problem with GOPOS is those temp files are saved to a hard drive and hard drives aren't ment to be used that way, ram is. So today I though hard and came up with the fix. RAMDRIVEs a RAM Drive is chunk of RAM that DOS treats like a hard drive! Perfect, perfect, perfect, we can use the ram for temp files, AND its faster than using the hard drive anyways! So sign up to join us crazies on the team! 0-Brandon Cornell (me) "Project Leader" 1-Andrew Wang (Aguma) 2-Jason Woodland "Head of Game Development"		2008-08-136:32 PM
ksrRe:How it will work.
Does DOSBox support RAM drives? If not, it would restrict development to pure DOS. What exactly are these temp files used for? I just think it would be a lot 'neater' if we could use actual RAM. edit: Anyway, sign me up for scripting language development or something.		2008-08-146:03 AM
jasonwoodlandRe:How it will work.
The temp files are for like: The current values and strings would be saved to a file. When the file is loaded again the temp file can be loaded with it so you can have the previous stuff up. I think that what it is.;)		2008-08-147:08 AM
BrandonRe:How it will work.
Well each script will save a temp BSV of its window, to be used when drawing and save a temp file containing all the information it needs, that way when a window is clicked on, its EXE is ran, it load the previous data and draws all the windows. Making EXE task switching.		2008-08-148:10 AM
BrandonRe:How it will work.
Small problem, all the RAM DRIVE tools I can find are Device Drivers, installed to CONFIG.SYS. So we can't just click and run, the user will have to really install the GUI with a ram disk driver and all, or just choose to use their hard drive as swap. Really unless you use it everyday on a very old hard drive then it shouldn't matter.		2008-08-149:38 AM
ksrRe:How it will work.
Oh, I see. I didn't realise you were going along the route of having an EXE for each application.		2008-08-142:14 PM
BrandonRe:How it will work.
I was using Rush, and realized, that it was grade-A stuff, and I realized a scriper can't make that kind of quality (well hasn't).		2008-08-142:34 PM
agumaRe:How it will work.
But scripters are fun! :laugh: lol but I guess you're right...		2008-08-142:38 PM
ToddRe:How it will work.
Efficiency is key. We should do a scripter since it'd be unique and fun. If we want a scripter, we should draw up plans for the programming language. Like this: [code] DISP "TEST TEXT HERE" @A = 5+2*4/2-4*10 DISP (@A 100) ? "A is 100" : "A is not 100" @W1 = QW(0, 0, 350, 300, "Test Window") @BTN1 = QB(@W1, 25, 23, 64, 44, "Button1", false) [/code]		2008-08-142:55 PM
BrandonRe:How it will work.
Well I'm going to make my own Demo with co-operative multitasking.		2008-08-143:18 PM
agumaRe:How it will work.
Whatever happened to preemptive multitasking? :P		2008-08-143:31 PM
BrandonRe:How it will work.
I'm not a rocket scientist.		2008-08-143:38 PM

GUIs

2021 Brandon Cornell