Prev: TMA Assembler?
Next: pshufb
From: Laurent D.A.M. MENTEN on 6 Nov 2006 12:23 Herbert Kleebauer wrote: > KiLVaiDeN wrote: > >> way of doing it; Using a 3rd party library is different than using the >> base windowing system, as it's possible under Win32. When we'll be able >> to use Xlib from Assembly, we'd have made a great advance in Assembly >> programming under Linux for GUI applications; Not yet. So Rene was >> right, once again, about his assumption. > > Xlib also is nothing but a "3rd party library". But you can directly > connect to the Xserver without using Xlib. A few weeks ago Linux > assembly code was posted here to open a Window. Now you can be the pioneer > and find out the rest (output text and graphics, get mouse and keyboard events). As a matter of fact X protocol is nothing more than a data exchange between a client and a server over a network, system call such as socket, read or write are easy to use. There is a project of a pure java implementation of the X protocol and it seems to be working (http://sourceforge.net/projects/escher/) so I am pretty sure one can archieve rather quickly a pure assembly implementation as well. I believe that the protocol details are published somewhere, anyway I know of a book called "X window system, C library and protocol reference" by Scheifler, Gettys and Newman (published in 1988 by Digital Press) and yet it may be a bit outdated it should help a lot.
From: Betov on 6 Nov 2006 12:36 "KiLVaiDeN" <kilvaiden(a)gmail.com> ?crivait news:1162830653.078430.26850 @m73g2000cwd.googlegroups.com: > So, even if you coded your first app in 1999, you being such involved > in assembly and in windows, don't you think the assumption of Rene > saying that Assembly under windows wasn't really possible in the 90s ?? The trap is well known: * He does NOT _lie_ stricto-sensus. * He is used to begin making noise about anything _long_ before doing anything real. * You will never find out _one_ single guy who was active on the Win32Asm front line, at that time, saying you that he had heard of it. * He still has, nowadays, nothing to show but a port of Iczelion jobs. His sweat dream is just about having all people forgetting the significative point of this history, for the same reasons as usual: Selling himself as an expert, by re-using other's works... up to the extreeme actual case of denying their existence. Too bad that all of the Win32-Asmers never took any lesson from Master Pdf: How stupid they have been, when searching how to do what he was perfectly aware of !!!... :)) Betov. < http://rosasm.org >
From: Betov on 6 Nov 2006 12:44 Herbert Kleebauer <klee(a)unibwm.de> ?crivait news:454F6D79.3B2DF851 @unibwm.de: > Assembler is only good for learning and understanding but > not for programming applications You mean: "What i call an Assembler is ..." * First, you write an Assembler that cannot be used for seriously developing Asm Apps. * Then, you say that doing so is using the wrong tool. :( In some counter way, you are right: Using your Assembler for "programming applications" would be absurd, as long as it has no other purpose but "for learning and understanding". re- :( Betov. < http://rosasm.org >
From: randyhyde@earthlink.net on 6 Nov 2006 14:48 KiLVaiDeN wrote: > > rhyde(a)cs.ucr.edu wrote: > > > > Actually, there were books in the early 1990s, before Rene's "pioneers" > > came along, that were demonstrating how to do this. Check out Tom > > Swan's stuff, for example. > > 1 Chapter dedicated to the Win32 API on his TASM book, is not what I'd > call "a complete reference".. It's good that he made it of course, and > we can give him the credit for sure, but the real advance was when > people started to BELIEVE in Win32 asm. No one said it was a "complete reference". It was proof that it could be done. The reason people didn't program Win32 apps in assembly language until the late 1990s had little to do with capability or possibility, rather, it had to do with the fact that there was a lot of work that needed to be done first to create a set of Win32 header files for assembly language programmers. It was Hutch who coordinated the development of the first practical set of header files, and Iczelion who used those headers to create the set of examples we now call the "Iczelion Tutorials". The capability to do assembly in Win32 was always there. What was needed was a lot of hard work to put together the header files to make it practical. BTW, that's where we are with X Windows today. It's not that it can't be done, but that few programmers find it practical to mess around with GUI apps under *nix because the appropriate software development tools (e.g., header files) aren't currently available. > > > In 1995, as Microsoft was preparing to release Windows 95 and the MS > > hype machine was in full swing, I decided it was time to abandon DOS > > completely. That's when I began the "UCR Standard Library for 80x86 > > Assembly Language Programmers" which quickly lead to the development of > > HLA. > > Uh, well nothing wrong with that. It was just plain dead good sense to > switch to Windows anyways, since DOS was not fitting the protected > mode.. Yes, in 1995 it was plain good sense. Prior to that, no. > > > No. I was busy implementing HLA from early 1996 to Sept 1999, when HLA > > v1.0 was released. You don't write 150,000 lines of code overnight, you > > know? My first "Win32 app" (a trivial window thing) was written in > > late summer 1999, as a proof of concept. I personally didn't write a > > win32 "app" until 2000. > > So, even if you coded your first app in 1999, you being such involved > in assembly and in windows, don't you think the assumption of Rene > saying that Assembly under windows wasn't really possible in the 90s ?? No. Because I'd read Tom's book. I knew it was possible. Yes, I knew it was a pain in the butt because I'd have to read the C documentation and create my own equates, but I knew that it was possible. Many thanks to Hutch & Co. for putting together the MASM32 package so that Win32 was not just possible, but practical as well. > > > As we can see, there is no way for coding GUI assembly application with > > > Linux. > > > > "We" do not see that. > > Nothing related to using Xlib with FASM for example can be found. There's lots of documentation for using Xlib with C. Do like the early Win32 programmers did and mentally convert this to assembly. You *do* know how to call a function written in C from assembly language, right? You do know how to translate #define and const definitions to assembly, right? You do know how to convert C data structures to assembly, right? It's not that big of a deal. Yes, it is a pain in the butt because someone else hasn't done all the work of creating the equates list for you. But that's only tedium, not an impossible wall blocking your way. > The > FASM doc, to give that one as an example, makes use of the Win32 API, > but not of Xlib.. So read the C documentation and translate. That's what people were doing with Win32 assembly in the 1990s. Indeed, to a large degree they're still doing that today because although we have header files, not everything is documented for assembly programmers yet. > > > > Yes, you can do it with GTK, but it's not what I'd call a "real" > > > way of doing it; > > > > Why? > > Because, being thinking about Assembly, is thinking low level, and > calling GTK functions, is not what I'd call "low level", since you call > a very high level library which in turn calls lower level ones, how is > that compatible with assembly programming ? Xlib is a high level library. What's your point? All you're going to do by *not* using the GTK is to write a whole host of widgets yourself in your assembly code, just duplicating what they've done in the GTK. Whatever efficiency you gain will be lost on the underlying calls to Xlib. The notion of "high-level calls" is quite a bit different from "high-level code vs. low-level code". You're not gaining a whole lot by doing your widgets in assembly - the low-level Xlib code is still *very* high-level compared with machine code. > > > > Using a 3rd party library is different than using the > > > base windowing system, as it's possible under Win32. > > > > Why? > > Read above.. Didn't answer the question. > > > programming under Linux for GUI applications; > > > > If you can call it from C, you can call it from assembly. That much > > should be obvious. > > Uuuuh I yet failed to see any information on how to interface an > assembly program with Xlib.. Maybe you have references ? ??? Can you read how to interface it with C? Then at the very worst, you write a C program that does what you want (even if it's only scaffolding code), tell your compiler to emit assembly language (you are using GCC, right?), and then do the same thing that the C compiler-emitted assembly language code is doing. Not that hard, actually. AFAIK, this is exactly how the original Win32 "pioneers" pulled it off. Cheers, Randy Hyde
From: Betov on 6 Nov 2006 15:05
"randyhyde(a)earthlink.net" <randyhyde(a)earthlink.net> ?crivait news:1162842532.695358.200840(a)m73g2000cwd.googlegroups.com: > The reason people didn't program Win32 apps in assembly > language until the late 1990s had little to do with capability or > possibility, rather, it had to do with the fact that there was a lot of > work that needed to be done first to create a set of Win32 header files > for assembly language programmers. It was Hutch who coordinated the > development of the first practical set of header files, and Iczelion > who used those headers to create the set of examples we now call the > "Iczelion Tutorials". The capability to do assembly in Win32 was always > there. What was needed was a lot of hard work to put together the > header files to make it practical. :]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] And, of course, all of the other important pioneers, like "Test Departement", who never used any header, and all of the other ones, who used their own stuff, never existed. :]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] Too bad you were not there, clown: You would understand at what extend your paragraph is laughable. Betov. < http://rosasm.org > |