How can you make use of 12+ gigs of ram with a 32bit OS? I had to use a 64bit OS just to take full advantage of my hardware.
*Technically* you can (look up Physical Address Extensions (PAE)) but consumer Windows doesn't really support it and we'll ignore it for now.
I wish my CPU were 128bit and I could expand my ram by the hundreds of gigs.
64 bits gets you 18,446,744,073,709,551,616 bytes bytes of memory: that's over 18 trillion gigabytes. I think you'll be set for now.
(Okay, this is a red herring; 64-bit CPUs don't actually typically support 64 bits of address space. The Core processors seem to support "only" 48 bits for addresses -- but this is still ~260 tibibytes.)
I might have this wrong, but I believe event-driven programs are, by their nature, multithreaded. This might not be obvious if you write a program by plugging event handlers into an event framework, such as MFC. But multithreading is still going on in the framework.
You're wrong. Let's look at the MFC example in more detail. I'll talk about what Windows does quite a bit, but the gist of how it works I think is common to virtually all GUI systems (including Java Swing and X, though don't count me as an authority).
Here's a sequence of steps to follow to illustrate:
Start Visual Studio (I used 2008 Professional)
Create a new "MFC Application" project with default settings (multiple documents, doc/view architecture, MFC standard, MFC in shared DLL, no compound doc support, no DB support)
Compile and run (I started with ctrl-F5 rather than debug)
Open Task Manager, ensure that the Threads column is active
Find your test program and note it has 1 thread
MFC is a relatively thin wrapper around the Windows API. The way that you program using the raw Windows API is as follows. The startup procedure (WinMain I believe) creates a new window and displays it to the user. As part of the creation of this window you pass a function pointer that is the address of the callback function that should respond to "messages" that Windows sends your program.
I don't recall the exact signature of the callback function, but it takes four parameters. The first is a pointer to the window that receives the message (so you can use the same procedure for multiple windows). The second is an enum that's the type of the message -- e.g. a button press, mouse click, resize, etc. -- and the third and fourth are message-specific information (e.g. what button was pressed or what the new size is).
Finally, what WinMain does is start the message loop. This is essentially an infinite loop which retrieves then dispatches the next message. (This is often hidden in a "run" function on similar by frameworks such as MFC or Qt.)
So let's consider the path of an event that occurs. Say the user presses 'e'. Windows determines which window is supposed to be notified of the key press, in this case whatever has focus. (There are parenting relationships too, but I won't get into that.) It translates that event into a message it will pass the program -- WM_KEYDOWN. (There's also a WM_KEYUP message.) Windows adds the WM_KEYDOWN message to the application's message queue.
At some point the message loop in WinMain will run (hopefully -- if not, I believe this is exactly what Windows means when it says a program isn't responding). It will retrieve the WM_KEYDOWN message then dispatch it. Retrieving it consists of removing it from the message queue, and dispatching it consists of calling the callback function. (Both of these are hidden from view behind API calls GetMessage and DispatchMessage.)
Windows figures out what callback function needs to be called, then calls it with that window handle, the WM_KEYDOWN message, and information about what key was pressed. The callback function does its thing, then returns. Returning transfers control back to Windows (inside DispatchMessage) which then transfers control back to the application in the message loop, and the program then retrieves and dispatches the next message, if available. (If not, it blocks until one is available.)
The point to notice in this process is that at no point is another thread created. When Windows originally notices an event, it simply places a message into the application's message queue. When the application retrieves and dispatches a message, that is done with simple control transfers within that thread.
While it's true that this sort of programming doesn't quite look like what you get from MFC,.Net, Java Swing, Qt, etc., you'll find a lot of people out there who will say that it's still event-driven programming. And more to the point, if you a
Additionally when closing a browser, I close it because I'm done with whatever's in it.
That's not always true. I close the browser because I need to reboot; I close the browser because I want to free up the memory; I close the browser because I want to shut off the computer; I 'close' the browser because it crashes; I close the browser because some plugin acts up (on Linux, I had "problems" with Flash after a few hours of use). In all of these cases, I am not done with whatever I had open, and will want to continue to use those tabs when I start it up again. What I almost never do is close the browser because I'm done with everything.
In addition, I basically have a browser basically persistently open, thus the startup time doesn't matter. (I suspect this could be a usage difference.)
I'm talking about a game where you're killed and that's it - you can never play that game again.
That's also not realistic. Realism would mean that you play once for 10 minutes, get shot, and some guys in army fatigues show up at your house and kill you. Being able to do other things except playing that game isn't realistic.
Less sarcastically, what I'm trying to say is that games, by definition, can't be entirely realistic, which means they all fall somewhere much closer to the "unrealistic" part of a spectrum than the "realistic" part. And at that point, you might as well call Rainbow Six and such "realistic" because to assert that they are not is basically a tautology.
You ignored what I said. Pure tags files suck because they don't pay attention to types, and I've never been able to get any of the fancier systems to work.
This is just another example of Wikipedia not knowing what it is talking about.
Because, after all, your school certainly did. And the Chicago Manual of Style (quoted in the references section of the Wikipedia article) also doesn't know what it's talking about. Right.
Well not entirely perfect, but I have yet to find a better editor for editing code.
I have yet to find a code editor I really like. For text other than code, Emacs is clearly it, but for code (1) I miss IDE-like code completion, code navigation ("go to definition"), etc. features in emacs, and (2) I miss emacs-like editing in IDEs. (The substitutes for the first seem to be a poor substitute (e.g. tags files) or work very poorly or not at all (e.g. the semantic mode in cedet).)
Better integration with GUI applications. I want to use Emacs for my editor boxes in Firefox, notably.
It's not prefect integration, but check out the FF extension It's All Text!. It'll add an "edit" button to the bottom right of textareas that will open your external editor of choice.
I don't know where you live, but in American English, the singular possessive of a noun ending in s can either have just ' or 's appended. See Wikipedia. (In particular, that article makes it sound like the Chicago Manual of Style recognizes both forms as valid.)
Arg. Again, *not the point*. The point is that Cygwin paths look like/cygwin/c/blah/foo, and if you pass that to a Win32 program, it'll say 'wtf is/cygwin?'
The point isn't that it's hard to do, or anything like that; but it is an extra step. If you're in a Cygwin shell, you can't tab-complete an absolute path and pass it as an argument to a Windows program. At best you do something like $(cygpath -w/blah/blah). By contrast, you can (at least usually) pass absolute Windows paths as arguments to Cygwin utilities.
As far as I'm concerned, the Windows shell provides most of the stuff I want from a shell... redirection, pipes, tab completion, etc. It even has loops, though I haven't bothered to learn the syntax yet and just drop into Bash when I want to do an interactive loop. The main thing I miss is Bash's reverse incremental search.
Copy and paste: getclip and putclip. But I usually abbreviate them to p and c with a couple of wrappers.
You're missing the point. I'm not saying Cygwin can't access the clipboard, I'm saying that you can't copy and paste paths (probably the most common things I'm pasting into a shell) because they're in a different format. Cygwin paths are adorned with the extra/cygdrive, and the different slash conventions will sometimes cause things to not work.
I can do one better... I don't really even use the Cygwin shells most of the time. I have Cygwin installed because it has a ton of other utilities... you get Grep, Sed, Flex and Bison, GCC, GNU Make, etc.
(For the curious, I don't really use the Cgywin shells because I find Cygwin doesn't integrate all that well with the rest of the system. You can't easily copy-and-paste paths back and forth (at least Cygwin->native apps), Cygwin's environment variable translations of paths is incomplete, etc. I therefor try to stick with native stuff as much as possible. I *do* use a different terminal emulator though; the default one with Windows is a piece of shit.)
Because it's a pain in the ass. Almost no package manager supports it, which means you have to do manual dependency resolution. (Package managers are, IMO, what makes the Linux way of not packaging almost all dependencies with your program, the way Windows programs typically do, remotely usable.)
I don't want to troll, either, but this really isn't the case; I tried to reinstall Windows on one of my machines for dual-boot (fresh setup on a new drive) using a generic, non-customized XP disk...
How old was this machine? Keep in mind that XP is over 8 years old now. Even SP3 is a year and a half. If your computer is more than 2 years old at the newest it's completely unreasonable to not expect some driver issues, and 2 years is even being quite generous (that's assuming that when they started pressing CDs with SP3 on it they also updated their drivers).
Trying to hide or change history of ANY kind is a bad thing.
And so would denying a job for a stupid-ass reason like the candidate used to be in Rocky Horror. But I could definitely see it happening. And unfortunately, two wrongs can sometimes make, well, a less-wrong.
Slashdot Mirror
Windows needs a thread for every top level window, but I wouldn't suggest Windows is the place to look for good design.
I don't know for certain, but I don't buy this without some support. Can you cite a source?
How can you make use of 12+ gigs of ram with a 32bit OS? I had to use a 64bit OS just to take full advantage of my hardware.
*Technically* you can (look up Physical Address Extensions (PAE)) but consumer Windows doesn't really support it and we'll ignore it for now.
I wish my CPU were 128bit and I could expand my ram by the hundreds of gigs.
64 bits gets you 18,446,744,073,709,551,616 bytes bytes of memory: that's over 18 trillion gigabytes. I think you'll be set for now.
(Okay, this is a red herring; 64-bit CPUs don't actually typically support 64 bits of address space. The Core processors seem to support "only" 48 bits for addresses -- but this is still ~260 tibibytes.)
You're wrong. Let's look at the MFC example in more detail. I'll talk about what Windows does quite a bit, but the gist of how it works I think is common to virtually all GUI systems (including Java Swing and X, though don't count me as an authority).
Here's a sequence of steps to follow to illustrate:
MFC is a relatively thin wrapper around the Windows API. The way that you program using the raw Windows API is as follows. The startup procedure (WinMain I believe) creates a new window and displays it to the user. As part of the creation of this window you pass a function pointer that is the address of the callback function that should respond to "messages" that Windows sends your program.
I don't recall the exact signature of the callback function, but it takes four parameters. The first is a pointer to the window that receives the message (so you can use the same procedure for multiple windows). The second is an enum that's the type of the message -- e.g. a button press, mouse click, resize, etc. -- and the third and fourth are message-specific information (e.g. what button was pressed or what the new size is).
Finally, what WinMain does is start the message loop. This is essentially an infinite loop which retrieves then dispatches the next message. (This is often hidden in a "run" function on similar by frameworks such as MFC or Qt.)
So let's consider the path of an event that occurs. Say the user presses 'e'. Windows determines which window is supposed to be notified of the key press, in this case whatever has focus. (There are parenting relationships too, but I won't get into that.) It translates that event into a message it will pass the program -- WM_KEYDOWN. (There's also a WM_KEYUP message.) Windows adds the WM_KEYDOWN message to the application's message queue.
At some point the message loop in WinMain will run (hopefully -- if not, I believe this is exactly what Windows means when it says a program isn't responding). It will retrieve the WM_KEYDOWN message then dispatch it. Retrieving it consists of removing it from the message queue, and dispatching it consists of calling the callback function. (Both of these are hidden from view behind API calls GetMessage and DispatchMessage.)
Windows figures out what callback function needs to be called, then calls it with that window handle, the WM_KEYDOWN message, and information about what key was pressed. The callback function does its thing, then returns. Returning transfers control back to Windows (inside DispatchMessage) which then transfers control back to the application in the message loop, and the program then retrieves and dispatches the next message, if available. (If not, it blocks until one is available.)
The point to notice in this process is that at no point is another thread created. When Windows originally notices an event, it simply places a message into the application's message queue. When the application retrieves and dispatches a message, that is done with simple control transfers within that thread.
While it's true that this sort of programming doesn't quite look like what you get from MFC, .Net, Java Swing, Qt, etc., you'll find a lot of people out there who will say that it's still event-driven programming. And more to the point, if you a
I'd be surprised if there were problems with earlier versions too.
Also no problems on a different computer with XP and Word 2000. So yeah, I say you're on crack or something.
two users can't log into the same computer at the same time and both run MS word without a third party controlling things.
What are you smoking? I just tried it (Win7/Word 2007) and it worked fine. I'd be surprised if there were problems with earlier versions too.
Additionally when closing a browser, I close it because I'm done with whatever's in it.
That's not always true. I close the browser because I need to reboot; I close the browser because I want to free up the memory; I close the browser because I want to shut off the computer; I 'close' the browser because it crashes; I close the browser because some plugin acts up (on Linux, I had "problems" with Flash after a few hours of use). In all of these cases, I am not done with whatever I had open, and will want to continue to use those tabs when I start it up again. What I almost never do is close the browser because I'm done with everything.
In addition, I basically have a browser basically persistently open, thus the startup time doesn't matter. (I suspect this could be a usage difference.)
I'm talking about a game where you're killed and that's it - you can never play that game again.
That's also not realistic. Realism would mean that you play once for 10 minutes, get shot, and some guys in army fatigues show up at your house and kill you. Being able to do other things except playing that game isn't realistic.
Less sarcastically, what I'm trying to say is that games, by definition, can't be entirely realistic, which means they all fall somewhere much closer to the "unrealistic" part of a spectrum than the "realistic" part. And at that point, you might as well call Rainbow Six and such "realistic" because to assert that they are not is basically a tautology.
You ignored what I said. Pure tags files suck because they don't pay attention to types, and I've never been able to get any of the fancier systems to work.
This is just another example of Wikipedia not knowing what it is talking about.
Because, after all, your school certainly did. And the Chicago Manual of Style (quoted in the references section of the Wikipedia article) also doesn't know what it's talking about. Right.
Well not entirely perfect, but I have yet to find a better editor for editing code.
I have yet to find a code editor I really like. For text other than code, Emacs is clearly it, but for code (1) I miss IDE-like code completion, code navigation ("go to definition"), etc. features in emacs, and (2) I miss emacs-like editing in IDEs. (The substitutes for the first seem to be a poor substitute (e.g. tags files) or work very poorly or not at all (e.g. the semantic mode in cedet).)
Better integration with GUI applications. I want to use Emacs for my editor boxes in Firefox, notably.
It's not prefect integration, but check out the FF extension It's All Text!. It'll add an "edit" button to the bottom right of textareas that will open your external editor of choice.
I don't know where you live, but in American English, the singular possessive of a noun ending in s can either have just ' or 's appended. See Wikipedia. (In particular, that article makes it sound like the Chicago Manual of Style recognizes both forms as valid.)
Is there a 'scary' mod? I don't see it in my list unfortunately.
Arg. Again, *not the point*. The point is that Cygwin paths look like /cygwin/c/blah/foo, and if you pass that to a Win32 program, it'll say 'wtf is /cygwin?'
That's an interesting idea... I'll have to keep it in mind. Maybe I'll give it a shot. I would kinda like to be able to use ZSH.
The point isn't that it's hard to do, or anything like that; but it is an extra step. If you're in a Cygwin shell, you can't tab-complete an absolute path and pass it as an argument to a Windows program. At best you do something like $(cygpath -w /blah/blah). By contrast, you can (at least usually) pass absolute Windows paths as arguments to Cygwin utilities.
As far as I'm concerned, the Windows shell provides most of the stuff I want from a shell... redirection, pipes, tab completion, etc. It even has loops, though I haven't bothered to learn the syntax yet and just drop into Bash when I want to do an interactive loop. The main thing I miss is Bash's reverse incremental search.
Copy and paste: getclip and putclip. But I usually abbreviate them to p and c with a couple of wrappers.
You're missing the point. I'm not saying Cygwin can't access the clipboard, I'm saying that you can't copy and paste paths (probably the most common things I'm pasting into a shell) because they're in a different format. Cygwin paths are adorned with the extra /cygdrive, and the different slash conventions will sometimes cause things to not work.
I can do one better... I don't really even use the Cygwin shells most of the time. I have Cygwin installed because it has a ton of other utilities... you get Grep, Sed, Flex and Bison, GCC, GNU Make, etc.
(For the curious, I don't really use the Cgywin shells because I find Cygwin doesn't integrate all that well with the rest of the system. You can't easily copy-and-paste paths back and forth (at least Cygwin->native apps), Cygwin's environment variable translations of paths is incomplete, etc. I therefor try to stick with native stuff as much as possible. I *do* use a different terminal emulator though; the default one with Windows is a piece of shit.)
Oh, I didn't realize there were two. I was talking about Tartakovsky's, and I haven't seen the 3D one.
Hell, I remember when Dell was ranked at the top of customer service ratings in PC magazines.
Actually, in comparison to the prequel trilogy (at least I & II), the Clone Wars cartoons are actually... surprisingly decent.
I want to see Microsoft demand things like this.
Because it's a pain in the ass. Almost no package manager supports it, which means you have to do manual dependency resolution. (Package managers are, IMO, what makes the Linux way of not packaging almost all dependencies with your program, the way Windows programs typically do, remotely usable.)
I don't want to troll, either, but this really isn't the case; I tried to reinstall Windows on one of my machines for dual-boot (fresh setup on a new drive) using a generic, non-customized XP disk...
How old was this machine? Keep in mind that XP is over 8 years old now. Even SP3 is a year and a half. If your computer is more than 2 years old at the newest it's completely unreasonable to not expect some driver issues, and 2 years is even being quite generous (that's assuming that when they started pressing CDs with SP3 on it they also updated their drivers).
Trying to hide or change history of ANY kind is a bad thing.
And so would denying a job for a stupid-ass reason like the candidate used to be in Rocky Horror. But I could definitely see it happening. And unfortunately, two wrongs can sometimes make, well, a less-wrong.
ChromeOS is a good, fairly simple example of how to do away with malware (ONCE AND FOR ALL!).
It's also a good, fairly simple example of how to do away with... well, functionality and usability.