Author Topic: In the gui path...  (Read 337 times)

jj2007

  • Member
  • *****
  • Posts: 7633
  • Assembler is fun ;-)
    • MasmBasic
Re: In the gui path...
« Reply #15 on: November 05, 2017, 08:42:57 PM »
my programs will become obsolete in a year and I will not write any more as I would write a year ago. And there will be commands that will no longer support new processors that were two or five years ago

Carissimo Mikl,

A quick file search for the *.asc ending finds over 5,000 files in my \Masm32 folder, the oldest being about 10 years old. If one of them doesn't build by hitting F6, alarm bells ring in my head, and I start investigating what may have changed. Same for GfaBasic files with the *.gfw extension, they build fine even if they date back 40 years.

You may call that paranoid, but it distinguishes a serious coder from a trial-and-error script kiddie. You are not in the latter category, you have proven that you can produce great stuff here, especially with the Iczelion tutorials that you ported to 64-bit land. Google mikl Iczelion to see what I mean. People value your work.

The ability to build code that is more than a year old is also something that distinguishes the Masm32 SDK from "professional" packages like Visual Studio. The main reason why I don't take Micros**t seriously is indeed that everytime I find a little hello world proggie on the web that is older than, say: 2 years, and I try to load it into Visual Crap, the M$ flagship complains whiningly that it is unable to open such old stuff. Or it simply hangs. That is truely "professional", but guess what, we can do better, and we are proud of that :icon_mrgreen:

In short: Read carefully what Hutch writes above. He is 100% right ;-)

P.S.: "there will be commands that will no longer support new processors" - very unlikely. M$ is scared of breaking legacy code, and Intel/AMD sell CPUs for the M$ world. Even dinosaurs like lodsb and jecxz work just fine in 64-bit code (but aaa aad aam don't, see x64 Instructions). Of course, one has to draw a line somewhere - nobody here wants to support Windows 95. My rule with MasmBasic is to use SSE2 and below in library routines, which means it is fast enough and will run on 99.x% of all machines. Similar for API calls: XP must support it; if a user decides that a Vista API call is needed, so be it - he is free to do that in "pure" assembly, but a library should give a high weight to compatibility (one reason btw why Linux never got a foot in the door).

felipe

  • Member
  • ***
  • Posts: 341
  • assemble the unassembled.
Re: In the gui path...
« Reply #16 on: November 06, 2017, 01:28:15 PM »
nobody here wants to support Windows 95.

 :lol:

=======================================================================
I'm agreed with all of you, basically because you all know the difference between building windows's "standard applications" and something particular. The later can be of different kinds. Of course the later type also should be based in reasonable knowledge and experience. By just trying things and see what happen later it will be probably a loose of time (at least for someone). But i do support to professionals (and with that i just mean someone who understand what he/she is doing) with some special works. They may not run in more than a few machines, but that's precisely one of the main advantages of assembly programming: the specific thing. Of course most will say is a disadvantage.
You all also know how OS specific it is, so yeah if someone want's to try more special things and is an assembly programmer  :P, if he/she knows what he/she is doing, so ok. If you don't know, don't loose your time in that way. First learn how things really work, then explore but based in what you already know of course.
Well at least that's how i work...

 :icon14: :icon14:
Felipe.