Re: Confusing stack effects



På Thu, 09 Feb 2006 15:16:00 +0100, skrev Herbert Kleebauer <klee@xxxxxxxxx>:


We are not speaking about applications, but about learning
assembly programming. And DOS (or the DOS interface in XP)
is the best way to start assembly programming.

Thats like saying driving a scooter is best way to learn to drive a car.
Nobody really needs to "learn" programming. They need to start writing at something, and have the ability to locate missing information for turning that into a program. What they need to complete one project is diffrent from what they need to complete another. I have written ~2 megabyte of asm code. But I have no knowledge of how to write a PE by hand, or an assembler, because I never did it. I have absolutly no idea of how to make an OS, or how to make an accounting program, or how to create a fast 3D game. As long as one have a still half working brain, and the information are available, for instance, math to do physics, one can simply ignore learning all that stuff until the day its needed. Same way that I can ignore learning the 90% of asm instructions that I never use.

I never got to complete learning about imaginary numbers in school. But seeing how I could learn about how floats work, or how to do integral math, I am fairly convinced I could learn it in a few days if ever needed. Knowledge that is not practiced, is dead knowledge. In my grown age, I found just about everything easier to learn, than when in school. To learn todo 16-bit dos programming, for programming in windows later is the worst kind of advice. First, NOTHING in windows behaves as dos 16-bit programming. Dos is (usually) single task, or polling like. That means, theres xx things you do not ever have to consider. Windows is an environment where everything can happen at any time. You cannot know what the user will do next, and he can easily do something to break your application, from another application, or from changing variables in the OS, or just about anything. And those task may be fully unrelated to the the things your app is really doing.

Learning to program for a Click&Go GUI is a tedious incredible complex job, compared to doing a dos app, where all you need to do is set up a loop, to take input that in all cases _you_ made the rules for. In Dos, you have full control, but in windows, you must cooperate with other apps. For instance, some windows OS HLL stuff, breaks applications, because some of those OS task takes all of the computercycles, without any reasons for doing so, and make you app suffer from it. Any app may run in your system, and it may even allocate memory in your app, or send your app messages. It can scan you memory area, each time its started, or anytime else. Maybe assuming you have windows controls in you app, or whatever. Many apps assume a lot of things when running in windows. Some assume the explorer is allways running, like ZoneAlarm, and therefore some important features of ZoneAlarm becomes useless, when the explorer is not running. When ZoneAlarm is running, battlefield2 will deadlock in my PC, for instance. Because the guys at ZoneAlarm did not think about the fact that the Windows shell is replaceable, so you cannot use the appbar to remove the firewall, prior to running the game. And the Windows guys did not think that another app could run as a shell, that is not a system app, and that does not have a taskbar, or a appbar or etc. Or simply, because the guys that create the antivirus app you are using are not Gods and cannot see everything. For instance, RosAsm apps without source, gives a false positive on some windows virus, for some viruskillers. And some viruskillers breaks my apps by misaligning my apps usermemory before my apps gets to have cycles.

Windows programming is much more complicated then you think. I would consider it a worst case practice to prepare a student for windows by teaching him dos. As a programmer, I do programming in a blank, default environment. But I no longer belives this to be good. I should really install all the *** ever found anywhere so I could see how my apps really look like in a true window environment. Theres surly many reasons it could still break, when running with just about any other app.



.