You are correct. The command shell has backward compatibility with the ".bat" extension. Just for separation, I personally use ".bat" for strictly older command.com stuff and ".cmd" for command shell scripts. However, I also don't change the association, so yes, most of the application ".bat" scripts startup using the command shell.
In my mind shell scripting sits at the highest level of process control. You are basically working above all other methods to control your machine with a thin and light interface. In shell scripts, you typically start and stop processes, check for active processes, log information about processes, control the flow of or filter process data. You also work directly with files on the file system by checking for them, moving them, renaming them, deleting them, appending to them, etc. In short, shell scripting is exactly what it says it is...scripting what you would otherwise do by hand at the shell prompt.
Shell scripting usually trumps all other programatic languages in that the engine is so small. That allows it to start up and shutdown really quick, not like the bloated Perls, Pythons, Java's, VBs, etc. A typical shell script engine might use about a Meg or less. Shell scripting is not programming in the strict sense of the word. You are not working in a well structured and cohesive language to be used for a variety of application development. No, shell scripting was made primarily for process and file system management. Making shell scripting work much beyond those means is an art, and not something that should ordinarily be done because other better languages should be used to fulfill broader purposes.
In our Windows environment we use CMD.EXE, or the command shell engine for just about all of our network control scripting. It comes with Windows, and is the only standardized default shell console. The command shell of NT/2k/XP is NOT your fathers BATCH language. Microsoft made some extensive professional changes to the command shell engine starting way back with Windows NT 3.51. The command shell is now very functional and has many Bourne shell syntax features.
Microsoft hasn't promoted the use of the command shell until very recently. This is because early on, they wanted to push system programmers and admins into using their GUI tools and VB scripting languages so that you would have to buy other products. Microsoft really pushed people away from using command shell scripting for the purpose of their own gain. Recently, with the gowing popularity of Linux and Unix again, they are now pushing to get people to use the command shell. They've finally documented most of the many changes they've made to the shell over the years, those changes that were kept in secret to all but the most diehard shell users.
The most popular changes come with the following commands...
CALL, GOTO, EXIT, FOR, and SET.
These commands have been expanded for the development of subroutines, string manipulation, math functions, tokenizing, file system recursion and enumeration. The command processor is fairly powerful in its own right because you don't have to exit very much for externals like FINDSTR, or SED/AWK type executables.
Under NT/2k/XP if you are using the ".BAT" extension for your scripts, or the "COMMAND.COM" processor, then don't. These are now outdated. If you fire up command.com, the the 2k kernel must startup the 16 bit virtual dos machine (VDM). This is S-L-O-W, and the BATCH language is indeed very poor. You should now use the ".CMD" extension for your command shell scripting.
See the following for more command shell (cmd.exe) documentation...
Console games are for the equivalent of Britney Spears loving female adolescents and for those who like to eat a McDonalds as their primary food source. Any serious gamers will stay with PCs because that is where the true elements of a game machine/environment all come together. Just like any serious gambler will end up in Vegas eventually. Since consoles were made for the masses, what you end up getting is a dumbed down game environment. All serious musicians eventually move away from $129 dollar guitars and 4 track recorders. Serious gamers don't like to work within the confines of a can'ned environment. I will never own a console for those reasons and others. I've been FPS gaming for over 10 years and find consoles cute and POP but lame.
Of course these are just my opinions. But you also may want to also ask those who attend Quake Con every year.
I have several questions. With music downloads becoming the predominant method of getting music these days, why invest so much money in 24 Bit 96 KHz music production? Or even 16 Bit 44.1 KHz for that matter?
The problem is compression. We are now sacrificing music quality for quantity. Can I download the real 16 Bit PCM tracks from ITunes? No? Then why does Pat Metheny need to think about recording the next album with pro gear? Who cares about all those quiet subtleties and nuances if the compression just throws them out?
What I'm saying is that yea, I'm paying less for music these days with ITunes and the like, but I'm also getting less quality that before. Many people don't take that into account. So while we enjoy the grand number of titles available to us, the corporates are quietly creating a class system to the music we enjoy.
It started with 45s vs. LPs. Then cassettes vs. CDs. Now it's 1 dollar downloads for singles, $12.99 for real CD's, or $20 for 24 Bit SACDs.
My point is that the quality of the music is less, but the price we pay for the real thing hasn't changed like we originally wanted it to. So we've quietly made a subconsious sacrifice that we are somehow getting what we wanted all along. I say no, this is wrong. What I wanted in reality was a cheaper CD or SACD, not some cheap knock-off that stands in their place.
The music industry is more than happy to sell you cheap quality music so that you'll eventually go out an buy the real thing...FOR THE SAME OLD PRICES! How have we ended up doing better?
Let me download the real 16 Bit PCM tracks from ITunes and I might change my tune. Until then, stop all this glorifying the download services. They all suck.
Patents are bad only if you live in some idealistic utopian world where no one makes money selling things to survive. Patents are bad if no one owns anything and everything is essentially free because resources are unlimited. Patents are bad because no one steals, lies, cheats one another. Yea, patents are surely bad.
The problem is not the patents. The problem is that the companies who have the patents don't sell at fair market prices for the goods derived from those patents. The problem is that the greater good is rarely considered. That's my opinion anyway.
You've just stated a slew of technologies here. But I think you are wrong about many items in the list.
* How many of these technologies require licensing to use?
* Of the ones that are listed why do you say they are "standards"? What makes a standard?
* DirectX is certainly a "standard". It is documented and standardized under Microsoft.
* Almost all the technologies listed are not "standards" as they are all proprietary in some way.
You are incorrect that these are recognized standards, they are not. The only true standards are those that have been recognized by working groups that are independent of the companies that developed them. True standards are recognized by non-profit organizations that have representatives from many vendors.
In the long run, people will always choose the lower cost option as long as it does what they want most of the time.
Microsoft won the browser war not for being the best browser, but because it came free with the OS.
If Linux does what most people want and does it well, then I really don't see how Microsoft has a chance. The only thing they can do at this point to compete would be to release the Win2k/XP/Longhorn kernel for free, not neccessarily open-source.
People currently pay for Microsoft software even with the bugs and reboots. If you give them something for free that does pretty much the same thing with the bugs and reboots included then free is really a no brainer.
What can Microsoft do to counter Linux?
1. Lower the cost of the Windows OS. The've got plenty of ability to move here since it is priced so high to begin with (compared to free).
2. Get rid of the client access licenses.
3. Offer a slicked down base OS for free, then make sure they stay in the applications development arena. Remmember, it's really the apps that do all the work.
4. Complain about Linux until it runs right over them, they lose there shareholders, and Bill ends up tossing a snow globe while uttering rosebud.
I just ask a perfectly reasonable question. Just looking for the answer. I did find the original post funny, I just wanted to know. I wasn't in the least trying to be an ass.
What is going on here. Everybody have a bad day or something? Did somebody hit me with a Troll gun?
The standard out-of-the-box Microsoft XP commands are now TaskKill and TaskList. Get to know them. You should get to know all commands that are a part of your OS first, then add-in third party apps later.
NTFS has nothing to do with DOS FAT. They are two completely different beasts.
With NTFS you can in fact replace a file that is in use by performing the same operation you have to use in *nix. You just rename the old file to something else, then copy the new file. The existing processes will continue to use the renamed file, while new processes will use the new file. You can stop and restart many applications by hand, or just reboot. Many application creators just required reboots because they didn't wan't to have to deal with other applications already running. You are guaranteed sure to get a "clean" machine upon reboot. Because of Microsoft Windows Installer Service, many applications no longer require the bloody reboots.
Some applications try to put locks on the file. You can use the following "InUse" command to fix even this...
Long live the Windows Command Shell Processor CMD.EXE...
1. CMD.EXE replaced COMMAND.COM as the scripting shell to use under NT as early as v3.51.
2. If you are still using the.BAT extension under NT/Win2k/XP then you are not following the correct use. The "*.bat" is for COMMAND.COM scripts. The ".cmd" is for CMD.EXE scripts.
3. If you are running COMMAND.COM under NT/2K/XP then DON'T. When you run COMMAND.COM, the kernel automatically fires up the vdm (virtual DOS machine). This is a 16 bit emulator.
4. The advantages to CMD.EXE scripts are numerous...
a. The engine is 32 bit and small. It typically occupies 1 Meg or less of memory.
b. It has backward compatibility for.BAT scripts.
c. The functionality of most of the internal command set has been greatly expanded.
d. It uses standard Borne shell syntax with pipes and redirection.
e. Has string functions.
f. Has numeric functions.
g. Has buit-in token-izing, no need for AWK/SED type scripts.
h. Has extensive compatibility with the Windows paradigm of Drives/UNC paths. This is why using Cygwin with UNIX type shells is a worse idea as they don't know anything about Windows. (much like using a screwdrive for a hammer).
i. Allows subroutines and functions.
j. Operates directly on environment variable table without the need for variable shuffling.
k. Process execution with little need for escaped arguments.
l. Directory/Tree recursion-enumeration built-in.
m. The 'FOR' capabilities have been greatly expanded, as well as 'SET', 'CALL'. Look into them.
5. Process management without the overhead of exiting the shell for externals like "find", and "ls".
6. When externals are needed, there is an extensive command set provided for just about anything from regular expressions to process control.
In short, the flexability of the Command Processor under 2K/XP is drastically increased to match just about anything you would use sh,csh,tcsh for. If you are a network administrator I would look into using the command shell. It is included standard. There's nothing to add. You can use it for everything from cron scripts to logon script, and even logon authentication. It is so much simpler than using VB scripting, without the overhead of a huge runtime engine. The scripts run, then end very quickly. I use it for just about everything. Our entire network infrastructure is based on this "glue" scripting that sits at the highest level of proecess management. In many ways using command shell scripting is the "right way" to do things because it frees you from sticky vendor lock-in technologies like systems management server, or Zenworks. You are in control.
See...
http://www.microsoft.com/technet/prodtechnol/win do wsserver2003/proddocs/server/ntcmds_o.asp
I could provide so many more compelling reasons to use the command shell that echo Raymonds sentiments, but I'll just stop here.
Will Longhorn have a Linux sub-system that will allow it to run all XP apps as well as all Linux apps with a built-in X server? That will make it just like the Mac? Hmmm... Anybody else think Longhorn delay is just a bit too much? Wouldn't that violate the GPL?
Our brains are great at detecting patterns in noise. The problem is, our brains are equally great at believing there are patterns in noise where there are none. Faces are the thing we "see" the best because "imprinting" is a biological function. We need to imprint because we need to know who will protect us, or help us, and who is dangerous to us. Facial recognition is near 100 percent with the brain so it's not difficult to see why we try to make out facial patterns in noise.
Though not strictly true, you mean the Samba team has refactored the SMB protocol. Microsoft on the other hand has made it a point to not touch the existing historical routines until something is found to be wrong with them. When you refactor, the chance of effecting millions of different clients that depend on the initial very strict protocol timing is critical. Though Samba is faster, is it more reliable? Even more so, since they've not only refactored, but they've reverse engineered also? There is nothing wrong with what they've done as long as the finite state analysis reduces correctly.
I for one applaud this kind of thing because I hate the fact that very few software programs get optimized over time. As a systems programmer, I resent moving on to other projects until I'm sure I've got the absolute fastest code. But alas, time, money, and resources ultimately give way to the need for change. It really just sucks. Way to go Samba team!
I remember when I used to play Doom, then Quake with the keyboard. Everyone around me was saying try the mouse, but I didn't think I would like it so I kept on playing with the keyboard as I knew it like the back of my hand. Then, after months and months of just getting blasted by my foes on the game I decided to try it. Man, what a change! Instant 360 degree rotation! I was fragg'n with the best of them. I'll never go back. Sometimes you just gotta' try new things.
Hear hear! Yes, you are right. I also will never buy a console for the following reasons...
1. Graphics are inferior. 2. No mouse control. 3. Inability to mod games. 4. Investment in console is not an investment in PC hardware upgrade or other PC games. 5. Consoles depreciate faster than PCs. 6. Inability to store several games at once? 7. Internet gameplay almost impossible without service, even if free, is monitored. 8. Inability to easily run servers. 9. Requires development license for developers. 10. Poor games. Except for Halo, Most games are arcade style with very little emphasis on visualization/realism technologies that made PC games so exciting...ex, Half-Life2. 11. Developers are "trapped" by the console's limited OS infrastructure. 12. Consoles are "toaster" technology that doesn't impart any requirement for the user to "learn" anything new. A "cattle for slaughter" mentality from the huge Microsoft and Sony corps.
I absolutely loved the T.V. series. I saw it first on public television. It was filled with intense sarcasm and satire delivered in that traditional british comedy style where everyone is completely serious. Who can forget in reference to Marvin...
"Your plastic pal who's fun to be with!!!"
and, in the last episode talking about what number 1 had done...
"I have declared war on another continent. Declared war? But there's no one even living there! Yes, but there will be one day, so we've left a sort of open ended ultimatum, and blown up a few military installations. Military installations number 1? All right, trees...and, we interrogated a gazelle."
I just can't see how you're going to get this kind of humor out of an American produced movie on the big screen precisely because that was the kind of thing the T.V. series was making fun of in the first place!
I bought the T.V. series as soon as it became available on DVD. I'm going to assume here that the "real" reason this movie is being done is becuase someone's monetary "clicker" clicked over the right number when the number of T.V. DVD purchases hit a certain value. The've basically decided that they can put out a short cheap film adaptation of the Radio/T.V. series and draw enough "geeks" to make it worthwhile. Nothing is done these days for the love of it.
I use C every day. I love it. It's part of my weapons cache for solving daily problems. I also use VB and have some working Java knowledge. I also spend a good bit of time using process level shell scripting. I'm a systems programmer/admin/architect, and I manage a diverse collection of greater than 500 fully managed and secured user PC's.
I've been programming in C for years. Pointer problems aside, the main problem I've always seen with this little language is that there is no fundamental "string" data type. C++ solves this by creating the big fat bloated "string" object class. But in my opinion, there should have always been an extremely small and efficient fundamental "string" type, as in...
string my_buffer;
&my_buffer = a pointer to the memory the string occupies. So what's in that memory?
Address 0-3 contains a 32 bit unsigned value representing the length of the string (for 32 bit compilers), or 64 bit unsigned for 64 bit compilers. Address 4 and up contains the actual string data.
The compiler should "know" how to deal with this data type as in...
strcpy( string1, string2 ); strlen( string );
None of this null terminated ASCIIZ string stuff.
(or, maybe we have several fundamental string types for different max size strings...as in string1, an 8 bit size value, or string2, a 16 bit size value, or string4, a 32 bit size value, etc.)
The reason the C programmers didn't want to do this I assume is that they didn't want this...
string *my_string;
So, what does the my_string pointer...point to? Do you always assume the size of the string will be at my_string - 4? I'm going out on a limb here to suggest that this would just confuse the already baffled C programmer. But even if we didn't use this suggested method to store the string size, certainly some other method could have been used. My point remains that the C compiler should have been able to deal with a fundamental string data type.
The brain is faster, so far...by far, than most any personal computer. And, many people still can't shoot accurately at moving targets. The military have spent years of research working on mid-air weapons destruction systems.
The problem you are not seeing is that of "inertia". If "delta-change" was sent to the server, you'd also have to take into account your inertial "weight" at "slewing" the gun. By the time you've sent your calculated "slew", you've very likely over/under-shot your target. The same thing happens in electronics with square waves. Any instantaneous change will cause ring'ing around the squared-edges, causing the signal to "ring". The programmers would simply have to set the server's inertial "slew" high enough so that you can't "slew" fast enough.
It would be like trying to aim in Quake through a thick viscus fluid. Great, so your computer is really fast, the point is your aim won't be, even for a computer, it will just keep trying to follow the target around, but in the end, it will be too late.
Slashdot Mirror
You are correct. The command shell has backward compatibility with the ".bat" extension. Just for separation, I personally use ".bat" for strictly older command.com stuff and ".cmd" for command shell scripts. However, I also don't change the association, so yes, most of the application ".bat" scripts startup using the command shell.
In my mind shell scripting sits at the highest level of process control. You are basically working above all other methods to control your machine with a thin and light interface. In shell scripts, you typically start and stop processes, check for active processes, log information about processes, control the flow of or filter process data. You also work directly with files on the file system by checking for them, moving them, renaming them, deleting them, appending to them, etc. In short, shell scripting is exactly what it says it is...scripting what you would otherwise do by hand at the shell prompt.
Shell scripting usually trumps all other programatic languages in that the engine is so small. That allows it to start up and shutdown really quick, not like the bloated Perls, Pythons, Java's, VBs, etc. A typical shell script engine might use about a Meg or less. Shell scripting is not programming in the strict sense of the word. You are not working in a well structured and cohesive language to be used for a variety of application development. No, shell scripting was made primarily for process and file system management. Making shell scripting work much beyond those means is an art, and not something that should ordinarily be done because other better languages should be used to fulfill broader purposes.
In our Windows environment we use CMD.EXE, or the command shell engine for just about all of our network control scripting. It comes with Windows, and is the only standardized default shell console. The command shell of NT/2k/XP is NOT your fathers BATCH language. Microsoft made some extensive professional changes to the command shell engine starting way back with Windows NT 3.51. The command shell is now very functional and has many Bourne shell syntax features.
Microsoft hasn't promoted the use of the command shell until very recently. This is because early on, they wanted to push system programmers and admins into using their GUI tools and VB scripting languages so that you would have to buy other products. Microsoft really pushed people away from using command shell scripting for the purpose of their own gain. Recently, with the gowing popularity of Linux and Unix again, they are now pushing to get people to use the command shell. They've finally documented most of the many changes they've made to the shell over the years, those changes that were kept in secret to all but the most diehard shell users.
The most popular changes come with the following commands...
CALL, GOTO, EXIT, FOR, and SET.
These commands have been expanded for the development of subroutines, string manipulation, math functions, tokenizing, file system recursion and enumeration. The command processor is fairly powerful in its own right because you don't have to exit very much for externals like FINDSTR, or SED/AWK type executables.
Under NT/2k/XP if you are using the ".BAT" extension for your scripts, or the "COMMAND.COM" processor, then don't. These are now outdated. If you fire up command.com, the the 2k kernel must startup the 16 bit virtual dos machine (VDM). This is S-L-O-W, and the BATCH language is indeed very poor. You should now use the ".CMD" extension for your command shell scripting.
See the following for more command shell (cmd.exe) documentation...
Command Shell Docs
Console games are for the equivalent of Britney Spears loving female adolescents and for those who like to eat a McDonalds as their primary food source. Any serious gamers will stay with PCs because that is where the true elements of a game machine/environment all come together. Just like any serious gambler will end up in Vegas eventually. Since consoles were made for the masses, what you end up getting is a dumbed down game environment. All serious musicians eventually move away from $129 dollar guitars and 4 track recorders. Serious gamers don't like to work within the confines of a can'ned environment. I will never own a console for those reasons and others. I've been FPS gaming for over 10 years and find consoles cute and POP but lame.
Of course these are just my opinions. But you also may want to also ask those who attend Quake Con every year.
+2
I have several questions. With music downloads becoming the predominant method of getting music these days, why invest so much money in 24 Bit 96 KHz music production? Or even 16 Bit 44.1 KHz for that matter?
The problem is compression. We are now sacrificing music quality for quantity. Can I download the real 16 Bit PCM tracks from ITunes? No? Then why does Pat Metheny need to think about recording the next album with pro gear? Who cares about all those quiet subtleties and nuances if the compression just throws them out?
What I'm saying is that yea, I'm paying less for music these days with ITunes and the like, but I'm also getting less quality that before. Many people don't take that into account. So while we enjoy the grand number of titles available to us, the corporates are quietly creating a class system to the music we enjoy.
It started with 45s vs. LPs. Then cassettes vs. CDs. Now it's 1 dollar downloads for singles, $12.99 for real CD's, or $20 for 24 Bit SACDs.
My point is that the quality of the music is less, but the price we pay for the real thing hasn't changed like we originally wanted it to. So we've quietly made a subconsious sacrifice that we are somehow getting what we wanted all along. I say no, this is wrong. What I wanted in reality was a cheaper CD or SACD, not some cheap knock-off that stands in their place.
The music industry is more than happy to sell you cheap quality music so that you'll eventually go out an buy the real thing...FOR THE SAME OLD PRICES! How have we ended up doing better?
Let me download the real 16 Bit PCM tracks from ITunes and I might change my tune. Until then, stop all this glorifying the download services. They all suck.
Just my opinion.
+1
Hrmm...lying or incompetent, lying or incompetent,........unless their LYING and INCOMPETENT! Shut up Caboose!
Yea, patents are bad (sarcasm).
Patents are bad only if you live in some idealistic utopian world where no one makes money selling things to survive. Patents are bad if no one owns anything and everything is essentially free because resources are unlimited. Patents are bad because no one steals, lies, cheats one another. Yea, patents are surely bad.
The problem is not the patents. The problem is that the companies who have the patents don't sell at fair market prices for the goods derived from those patents. The problem is that the greater good is rarely considered. That's my opinion anyway.
+1
"So if the old two year schedule were kept Moore's law comes to an end in 2011."
2011? Isn't that the end of the Mayan calendar? Is that when SkyNet is first activated?
+1
You've just stated a slew of technologies here. But I think you are wrong about many items in the list.
* How many of these technologies require licensing to use?
* Of the ones that are listed why do you say they are "standards"? What makes a standard?
* DirectX is certainly a "standard". It is documented and standardized under Microsoft.
* Almost all the technologies listed are not "standards" as they are all proprietary in some way.
You are incorrect that these are recognized standards, they are not. The only true standards are those that have been recognized by working groups that are independent of the companies that developed them. True standards are recognized by non-profit organizations that have representatives from many vendors.
What is a "standard"???????
+1
So when do we start the Open Hardware spec, and when do manufacturers start producing machines that are open?
Can Open Source software thrive on closed (DRM'ed) hardware?
+1
The WinNT/2k/XP Kernel keeps system time in 64 bits, but the beginning date is 1601!
FILETIME
The FILETIME structure is a 64-bit value representing the number of 100-nanosecond intervals since January 1, 1601 (UTC).
Why-o-why waste so many of those 100ns intervals?
+1
In the long run, people will always choose the lower cost option as long as it does what they want most of the time.
Microsoft won the browser war not for being the best browser, but because it came free with the OS.
If Linux does what most people want and does it well, then I really don't see how Microsoft has a chance. The only thing they can do at this point to compete would be to release the Win2k/XP/Longhorn kernel for free, not neccessarily open-source.
People currently pay for Microsoft software even with the bugs and reboots. If you give them something for free that does pretty much the same thing with the bugs and reboots included then free is really a no brainer.
What can Microsoft do to counter Linux?
1. Lower the cost of the Windows OS. The've got plenty of ability to move here since it is priced so high to begin with (compared to free).
2. Get rid of the client access licenses.
3. Offer a slicked down base OS for free, then make sure they stay in the applications development arena. Remmember, it's really the apps that do all the work.
4. Complain about Linux until it runs right over them, they lose there shareholders, and Bill ends up tossing a snow globe while uttering rosebud.
+1
Isn't this how Microsoft wins?
First they ignore you...as the Unix establishment did from 1985-1995.
Then they laugh at you...as the Unix establishment did from 1995 to 2000.
Then they fight you...as the Unix/Linux establishment is doing from 2000 on.
Then Microsoft wins...aka Longhorn.
The war has been going on for some time already. Maybe you just havent been around long enough to see it clearly. Will this be cyclic with Linux?
+2
I just ask a perfectly reasonable question. Just looking for the answer. I did find the original post funny, I just wanted to know. I wasn't in the least trying to be an ass.
What is going on here. Everybody have a bad day or something? Did somebody hit me with a Troll gun?
Grow up and learn to communicate.
+500
Ummm, what exactly is this number you've presented here? Is it supposed to be 2^32-1, or 4294967295?
Even so, given that most C Lib functions are in signed format then the highest post possible would be 2^31-1, or 2147483647.
+1
The standard out-of-the-box Microsoft XP commands are now TaskKill and TaskList. Get to know them. You should get to know all commands that are a part of your OS first, then add-in third party apps later.
+5
NTFS has nothing to do with DOS FAT. They are two completely different beasts.
With NTFS you can in fact replace a file that is in use by performing the same operation you have to use in *nix. You just rename the old file to something else, then copy the new file. The existing processes will continue to use the renamed file, while new processes will use the new file. You can stop and restart many applications by hand, or just reboot. Many application creators just required reboots because they didn't wan't to have to deal with other applications already running. You are guaranteed sure to get a "clean" machine upon reboot. Because of Microsoft Windows Installer Service, many applications no longer require the bloody reboots.
Some applications try to put locks on the file. You can use the following "InUse" command to fix even this...
InUse
In the case of processes that can't be restarted, like the kernel itself, you must use the Windows API called MoveFileEx().
Most Win32 coders do something similar to this...
MoveFileEx(SourceFile, DestinationFile, MOVEFILE_REPLACE_EXISTING + MOVEFILE_DELAY_UNTIL_REBOOT)
See...
MoveFileEX()
Mod the parent down please?
+2
Long live the Windows Command Shell Processor CMD.EXE...
.BAT extension under NT/Win2k/XP then you are not following the correct use. The "*.bat" is for COMMAND.COM scripts. The ".cmd" is for CMD.EXE scripts.
.BAT scripts.
n do wsserver2003/proddocs/server/ntcmds_o.asp
1. CMD.EXE replaced COMMAND.COM as the scripting shell to use under NT as early as v3.51.
2. If you are still using the
3. If you are running COMMAND.COM under NT/2K/XP then DON'T. When you run COMMAND.COM, the kernel automatically fires up the vdm (virtual DOS machine). This is a 16 bit emulator.
4. The advantages to CMD.EXE scripts are numerous...
a. The engine is 32 bit and small. It typically occupies 1 Meg or less of memory.
b. It has backward compatibility for
c. The functionality of most of the internal command set has been greatly expanded.
d. It uses standard Borne shell syntax with pipes and redirection.
e. Has string functions.
f. Has numeric functions.
g. Has buit-in token-izing, no need for AWK/SED type scripts.
h. Has extensive compatibility with the Windows paradigm of Drives/UNC paths. This is why using Cygwin with UNIX type shells is a worse idea as they don't know anything about Windows. (much like using a screwdrive for a hammer).
i. Allows subroutines and functions.
j. Operates directly on environment variable table without the need for variable shuffling.
k. Process execution with little need for escaped arguments.
l. Directory/Tree recursion-enumeration built-in.
m. The 'FOR' capabilities have been greatly expanded, as well as 'SET', 'CALL'. Look into them.
5. Process management without the overhead of exiting the shell for externals like "find", and "ls".
6. When externals are needed, there is an extensive command set provided for just about anything from regular expressions to process control.
In short, the flexability of the Command Processor under 2K/XP is drastically increased to match just about anything you would use sh,csh,tcsh for. If you are a network administrator I would look into using the command shell. It is included standard. There's nothing to add. You can use it for everything from cron scripts to logon script, and even logon authentication. It is so much simpler than using VB scripting, without the overhead of a huge runtime engine. The scripts run, then end very quickly. I use it for just about everything. Our entire network infrastructure is based on this "glue" scripting that sits at the highest level of proecess management. In many ways using command shell scripting is the "right way" to do things because it frees you from sticky vendor lock-in technologies like systems management server, or Zenworks. You are in control.
See...
http://www.microsoft.com/technet/prodtechnol/wi
I could provide so many more compelling reasons to use the command shell that echo Raymonds sentiments, but I'll just stop here.
+5
Will Longhorn have a Linux sub-system that will allow it to run all XP apps as well as all Linux apps with a built-in X server? That will make it just like the Mac? Hmmm... Anybody else think Longhorn delay is just a bit too much? Wouldn't that violate the GPL?
+2
Our brains are great at detecting patterns in noise. The problem is, our brains are equally great at believing there are patterns in noise where there are none. Faces are the thing we "see" the best because "imprinting" is a biological function. We need to imprint because we need to know who will protect us, or help us, and who is dangerous to us. Facial recognition is near 100 percent with the brain so it's not difficult to see why we try to make out facial patterns in noise.
+1
Though not strictly true, you mean the Samba team has refactored the SMB protocol. Microsoft on the other hand has made it a point to not touch the existing historical routines until something is found to be wrong with them. When you refactor, the chance of effecting millions of different clients that depend on the initial very strict protocol timing is critical. Though Samba is faster, is it more reliable? Even more so, since they've not only refactored, but they've reverse engineered also? There is nothing wrong with what they've done as long as the finite state analysis reduces correctly.
I for one applaud this kind of thing because I hate the fact that very few software programs get optimized over time. As a systems programmer, I resent moving on to other projects until I'm sure I've got the absolute fastest code. But alas, time, money, and resources ultimately give way to the need for change. It really just sucks. Way to go Samba team!
-1
Mod this man up!
I remember when I used to play Doom, then Quake with the keyboard. Everyone around me was saying try the mouse, but I didn't think I would like it so I kept on playing with the keyboard as I knew it like the back of my hand. Then, after months and months of just getting blasted by my foes on the game I decided to try it. Man, what a change! Instant 360 degree rotation! I was fragg'n with the best of them. I'll never go back. Sometimes you just gotta' try new things.
+1
Hear hear! Yes, you are right. I also will never buy a console for the following reasons...
1. Graphics are inferior.
2. No mouse control.
3. Inability to mod games.
4. Investment in console is not an investment in PC hardware upgrade or other PC games.
5. Consoles depreciate faster than PCs.
6. Inability to store several games at once?
7. Internet gameplay almost impossible without service, even if free, is monitored.
8. Inability to easily run servers.
9. Requires development license for developers.
10. Poor games. Except for Halo, Most games are arcade style with very little emphasis on visualization/realism technologies that made PC games so exciting...ex, Half-Life2.
11. Developers are "trapped" by the console's limited OS infrastructure.
12. Consoles are "toaster" technology that doesn't impart any requirement for the user to "learn" anything new. A "cattle for slaughter" mentality from the huge Microsoft and Sony corps.
Probably plenty more that I have forgotten!
Just say "No" to consoles!
+2
I absolutely loved the T.V. series. I saw it first on public television. It was filled with intense sarcasm and satire delivered in that traditional british comedy style where everyone is completely serious. Who can forget in reference to Marvin...
"Your plastic pal who's fun to be with!!!"
and, in the last episode talking about what number 1 had done...
"I have declared war on another continent. Declared war? But there's no one even living there! Yes, but there will be one day, so we've left a sort of open ended ultimatum, and blown up a few military installations. Military installations number 1? All right, trees...and, we interrogated a gazelle."
I just can't see how you're going to get this kind of humor out of an American produced movie on the big screen precisely because that was the kind of thing the T.V. series was making fun of in the first place!
I bought the T.V. series as soon as it became available on DVD. I'm going to assume here that the "real" reason this movie is being done is becuase someone's monetary "clicker" clicked over the right number when the number of T.V. DVD purchases hit a certain value. The've basically decided that they can put out a short cheap film adaptation of the Radio/T.V. series and draw enough "geeks" to make it worthwhile. Nothing is done these days for the love of it.
+2c
I use C every day. I love it. It's part of my weapons cache for solving daily problems. I also use VB and have some working Java knowledge. I also spend a good bit of time using process level shell scripting. I'm a systems programmer/admin/architect, and I manage a diverse collection of greater than 500 fully managed and secured user PC's.
I've been programming in C for years. Pointer problems aside, the main problem I've always seen with this little language is that there is no fundamental "string" data type. C++ solves this by creating the big fat bloated "string" object class. But in my opinion, there should have always been an extremely small and efficient fundamental "string" type, as in...
string my_buffer;
&my_buffer = a pointer to the memory the string occupies. So what's in that memory?
Address 0-3 contains a 32 bit unsigned value representing the length of the string (for 32 bit compilers), or 64 bit unsigned for 64 bit compilers. Address 4 and up contains the actual string data.
The compiler should "know" how to deal with this data type as in...
strcpy( string1, string2 );
strlen( string );
None of this null terminated ASCIIZ string stuff.
(or, maybe we have several fundamental string types for different max size strings...as in string1, an 8 bit size value, or string2, a 16 bit size value, or string4, a 32 bit size value, etc.)
The reason the C programmers didn't want to do this I assume is that they didn't want this...
string *my_string;
So, what does the my_string pointer...point to? Do you always assume the size of the string will be at my_string - 4? I'm going out on a limb here to suggest that this would just confuse the already baffled C programmer. But even if we didn't use this suggested method to store the string size, certainly some other method could have been used. My point remains that the C compiler should have been able to deal with a fundamental string data type.
+1.4
The brain is faster, so far...by far, than most any personal computer. And, many people still can't shoot accurately at moving targets. The military have spent years of research working on mid-air weapons destruction systems.
The problem you are not seeing is that of "inertia". If "delta-change" was sent to the server, you'd also have to take into account your inertial "weight" at "slewing" the gun. By the time you've sent your calculated "slew", you've very likely over/under-shot your target. The same thing happens in electronics with square waves. Any instantaneous change will cause ring'ing around the squared-edges, causing the signal to "ring". The programmers would simply have to set the server's inertial "slew" high enough so that you can't "slew" fast enough.
It would be like trying to aim in Quake through a thick viscus fluid. Great, so your computer is really fast, the point is your aim won't be, even for a computer, it will just keep trying to follow the target around, but in the end, it will be too late.
-2