Win32

Both malicious code examples are not just totally impractical (Especially the VB junk), but are about as efficent as using a pair of scissors to mow the lawn. The first example is just putting VB's head back under the desk, further proving how worthless the language really is (Along with the morons who use it). And the second just gives C++ a bad name. Using the 'new' operator.... WHAT THE FUCK ARE YOU THINKING? Regards, Matt J.

Erondial, As in scheduling a task with the "Task Scheduler"? If so; Yes it is needlessly complex, a grounding in COM is certainly required. If you require help, you have only to ask. Regards, Matt J.

So you're nothing more than a random troll? How pathetic. Transparent Entity, Don't talk until I want your input, kid. Secondly, I wasn't even talking to you, moron. Get your facts straight before going into a random whine over how '******s' intimidate you to the point of self-hurt. You've yet again just shown how much your little life really does revolve around internet-chat. Regards, Your Superior.

Forged, It amazes me you're even able to post, you took time away from your busy life of endless gaming just to cry to me, how cute Thanks fan :D Regards, Your Superior.

Greeneyes, Lsd, Just give up, ugly chinks. Get back to your life of gaming like the geek you are. Regards Your Superior.

Greeneyes, Because I have cornrows, I'm a negro? Moron. And secondly, all TransparentEntity did was prove how insecure he really is. Poor geeks, so small and scared. Regards, Your Superior.

TransparentEntity, Oh, all that was for me ? Awww thanks fan! :D Regards, Your Superior.

Let's get things straight; I'm no Negro. Greeneyes, Lsd; Don't bother posting, you're making fools of yourself.

Intimidated by those with power ? Please, crawl back into your hole and die. Dropped out of school in the sixth grade? Typical outcast. Don't talk for people other than yourself, and fellow morons, kid. Regards. Matt J.

Wow, you just continuously prove to be dumber by the post. Please, quit humiliating yourself, it's getting beyond the joke. Regards, Your Superior.

I certainly agree, programming languages are mediums of expression, and the overall quality of your program depends on how well you can communicate through a certain medium. Although it probably does seem like I am "stuck" on Assembly/C++, it's quite the oppisite. I use a varied range of languages, all depending on the circumstances. As you've previously touched down on, being a good programmer requires that you write your applications through a medium, but not _with_ it. A prominent trait of all good programmers is the ability to implement a language that is best suited to the task at hand, and not just use one they believe will render a better result, regardless of how inpractical it may be. Regards, Matt J.

I believe it will be the total oppisite, I would only be gaining performance. Overall, I agree with you. I never intended to imply that writing applications in Assembly is 'the only way. Moreso, I was trying to overlay the possible benifits of implementing Assembly _and_ the language the program is written in primarily, such as C++, which would be my choice. And I also know very well that writing a whole application in a language like Assembly would easily become cumbersome and unmanagable, due to the amount of code required to perform even the smallest operation, in which another language, such as C++, the same operation could be performed in one line. All-in-all Assembly is not a practical choice for writing applications, atleast not complex ones. Although, I believe a mixture can certainly be benificial to the applications overall performance. Personally, I write commonly used and CPU-bound routines (String length calculation, Encryption, Conversion, ect...) all in Assembly, and for the most part have these in a seperate DLL. Regards, Matt J.

VB is full of lies and irrelevent abstract concepts and terms, it never has been, and never will be suited to commercial application development, nor any application that requires a higher level of complexity than how to minimize a window. C has been used for the development of the majority of operating systems on the market today, including both Windows and Unix. It is the next step up from Assembly, and provides both an extensive range of built-in optimizing keywords along with the ability to produce code that is 80% identical to that of Assembly, unlike VB of which you couldn't even scale against Assembly. Regards, Matt J.

I figured as much, it makes sense if the application is not very large. I was just pointing it out as a future reminder. Well I'll clear things up for you, here's a quick example on how to use "CreateProcess": #include <windows.h> #define CALCULATOR_FILE_NAME "C:\\WINDOWS\\System32\\Calc" INT main() { STARTUPINFO CalcStartupInfo; // Buffer for the new Calc.exe startup information. PROCESS_INFORMATION CalcProcInfo; // Buffer for the new Calc.exe process information. // // Nullify both process informational structures to ensure no conflicts. // ZeroMemory(&CalcStartupInfo, sizeof(STARTUPINFO)); ZeroMemory(&CalcProcInfo, sizeof(PROCESS_INFORMATION)); // // Initialize the startup information construct. // We just have to specify the structure size, in bytes in it's 'cb' member. // CalcStartupInfo.cb = sizeof(STARTUPINFO); // // Create a "Calc.exe"'s process. // We'll be using the 'lpCommandLine' to specify the file-name, this will // allow the call to work on both 16 and 32-bit systems. // if(CreateProcess(NULL, CALCULATOR_FILE_NAME, NULL, NULL, NULL, NULL, NULL, NULL, &CalcStartupInfo, &CalcProcInfo)) { // // Wait for the child process (Calc.exe) to complete. // WaitForSingleObject(CalcProcInfo.hProcess, INFINITE); // // Close our handle to the child process. // if(CloseHandle(CalcProcInfo.hProcess)) { // // Close our handle to the child process's primary thread. // if(CloseHandle(CalcProcInfo.hThread)) { // // Return TRUE, indicating an operation success. // return TRUE; } else { // // ERROR: // Failed to close thread handle. // MessageBox(NULL, "Failed to close handle to Calc.exe's primary thread.", "ERROR", MB_OK); } } else { // // ERROR: // Failed to close process handle. // MessageBox(NULL, "Failed to close handle to Calc.exe's process.", "ERROR", MB_OK); } } else { // // ERROR: // Failed to create a new process instance from Calc.exe // MessageBox(NULL, "Failed to create a new instance of Calc.exe", "ERROR", MB_OK); } // // Return FALSE, indicating an operation failure. // return FALSE; } As you can see, all you really need to do is pass the file-name to the 'lpCommandLine' parameter and ensure the 'lpStartupInfo' and 'lpProcessInformation' pointers are valid. Aswell just ensure you initialize the informational constructs as I have showed, and you'll be fine. Regards, Matt J.

How could you even consider slandering performance? Even if it's not noticeble to the user, it's still a benificial trait to have. My standpoint comes from the fact all projects I have been involved in have had performance and efficency as the highest priority, making it not something that you can just 'care or not care'. And that is certainly does. But having a grounding 'efficent' language is a must, otherwise all your own personal contributions are quite meaningless when the language itself hinders your ability to write high-performance code. Regards, Matt J.