ELF loading
in [ASM]
|
From: Herbert Kleebauer on 27 Aug 2007 09:48 Betov wrote: > Herbert Kleebauer <klee(a)unibwm.de> �crivait news:46D2B295.8E3CF198 > @unibwm.de: > > > Just a question: are the executable and the embedded source > > always at the same version level? What happens when you modify > > the source in a way that it produces a compilation error, > > can you then not save the source or is the source saved > > without a binary? > > And what happends, with any Compiler having a downward > incompatiblity? You misunderstood my question. As far as I understand it, a PE exe generated by RosAsm contains also the source code of the binary. My question was, if I recompile the embedded source, will I get the same binary or can the author of the software edit the embedded source and then not recompile it so that the embedded source differs from the binary. I don't see any sense to embed the the source within the binary. It would be more interesting to embed the source of the application in the RosAsm binary instead of the application binary. And if RosAsm is as fast as you say, it wouldn't matter that RosAsm has to compile the application every time it is executed. But this way you always have the source and the source code debugger available when something went wrong at execution time. RosAsm also could determine the CPU version and if there is an instruction in the source which isn't supported by the CPU it could emit an error at load/compilation time instead of an crash at run time.
From: Robert Redelmeier on 27 Aug 2007 09:48 santosh <santosh.k83(a)gmail.com> wrote in part: > Robert Redelmeier wrote: >> 0) GUI pgms are harder to write than console apps. > Harder or more tedious? Both. Not only more complicated mechnically, but also more considerations to think about. >> GUI users are harder to teach to program. > Any evidence for this assertion? Seems to me like prejudice. Personal observation. GUI users are more divorced from the 'operation of the machine and seem to have more trouble grasping the abstractions of machine state and instructions. Admittedly over a small number and uncorrected for time/interest. Randy would have a much better opinion on this subject. >> GUIs are a learning crutch which tends to hobble more advanced users. > > How can something that is not used, hobble you, (not you > personally), the advanced user? Of course it does not. However, too much time on GUIs seems to slow users down on learning CLI. >> No upgrade path. > I cant understand this. There is a rather natural path on CLI: commands, pipes, scripts, pgms. Of course it can be shortcut. But once a user grasps the idea that a pgm/cmd does something, it is fairly easy to teach them to write one to do something else. GUIs are a bit of a far abstraction, and it is not apparent how to create an app. A bigger hurdle to clear. >> 1) All GUIs are fundmentally menuing systems. > So far. I have not seen any ideas otherwise. MS has been trying with their "ribbons" and adaptive menus. >> Limited choice. You >> can only run whatever has been configured. > And with a text mode program, you can only give it the > options it is programmed to receive... Whence the importance of pipes. `dir` should not have any sorting options. But it needs them because MS-SORT.EXE is indescribably lame. >> If you can find it. >> My $PATH has 2995 executables on it. A very busy GUI max 100. > What has $PATH to do with anything? That is the number of pgms I can access _directly_ without specifying a path. To contrast with menuing limited choices. >> 2) GUIs are bloated bugfests. > As much an "abusive generalisation" as Betov's statements > on text mode programs. I agree it is somewhat inflammatory, but not abusive. GUIs are "bloated" in the sense of requiring many MB of both disk and RAM. "bugfests" since all contain more bugs than their base CLIs. >> Poor use of hardware. > Huh? A GUI or text mode program can only "use" the hardware to > the extent that the underlying OS allows and understands. How > exactly does, for example, vim uses the hardware better than gvim? Yes. 160x72 vs 132x55 the graphical/font abstraction costs pixels. At least in the framing and usually in the fonts. I especially regret fewer lines giving less of an overview. Aggravated by the loss to menu lines. I'm convinced it leads to misunderstandings. > Now it's true that a typical GUI program consumes more > resources than a text mode program implementing the same > overall functionality, but that is more the fault of bloated > toolkits rather than a specific program. No, they need more resources (bitmaps, etc) even with slim kits. Textmode loads fonts _once_ into the GPU and frees the RAM afterwards. >> 3) GUIs abandon that great IT invention of 7000 years ago -- >> the alphabet! Icons are cryptic pictographs. > Both have their uses. I did not say otherwise. GUIs have their place on simple /multilingual systems (phones) or for beginner use. >> 4) GUIs don't permit pgms to co-operate. How do you do >> a pipe | ? > Lack of an example doesn't mean that the said functionality > is somehow inherently impossible. Yet I have never seen it. And many smart people (Bruce Tognazzini) have worked hard on GUIs. >> 5) Most GUIs are very poorly implemented, with poor UI choices, > Agree. >> and excessive mouse precision required. > How? Read Tog. Corners and borders are underutilized. >> In fairness, many CLI are also poorly implemented. >> MS-Windows COMMAND.COM is horrible, and CMD.EXE is only >> marginally better. > Yes. >> 6) Most GUIs make excessive use of the mouse which tends to >> cause Repetitive Strain Injuries (carpal tunnel). > Isn't this disorder possible for those who type excessively > too? Certainly. But most cases I've seen affect the right hand (used by most for mousing) while the QWERTY kbd actually puts more stress on the left. Often people switch the mouse to the left and the trouble re-appears there. >> Tasks are hard to describe, automate (scripting?) or >> repeat (history?) > I agree. -- Robert
From: CodeMonk on 27 Aug 2007 09:54 Betov wrote: > > Betov. > While I *think* I'm actually beginning to have an appreciation for your sense of humor, your terse responses or evasion of questions isn't included in that appreciation. I see you're very busy this morning, so I'll let you off the hook for now. - Scott
From: Betov on 27 Aug 2007 10:05 santosh <santosh.k83(a)gmail.com> �crivait news:fauj7t$oa5$1(a)aioe.org: > Also Betov comment on hidden files and folders in Linux is disingenuous. > Windows has them too. In fact, IIRC, you _cannot_ move or delete certain > files and folders in Windows, even as an "administrative" user. Much more > of a "Big Brother" attitude than Linux You like it or not, i *NEVER* downloaded anything under Windows, without knowing what, how and where. And i never saw any download of mines going magically into any hidden Folder. To be compared to Linux, where 9 times on 10, it is not possible to know *what* (???!!!...), nor how, and surely never *where* it goes. We are luky when it comes with a Menu Item (without asking, of course), and when it works. Then, when it works we are luck if this is something we wanted to have. I just went for a News Reader. Hope to find out something called "News Reader", or "gnews", or whatever, that would make sense. Nope. I found out a package wich is supposed to have a News Reader inside. I download it... Half an hour... Over. Silent. Fortunatly, i see new items in the main menu... No news reader. 6 "things" more on disk. How to remove them? No idea. No Un-install of course. So, stop comparing, please. This is pathetic. Good will: Yes. Bias: No. Betov. < http://rosasm.org >
From: rhyde on 27 Aug 2007 10:11
On Aug 27, 6:48 am, Robert Redelmeier <red...(a)ev1.net.invalid> wrote: > > Personal observation. GUI users are more divorced from the > 'operation of the machine and seem to have more trouble grasping the > abstractions of machine state and instructions. Admittedly over a > small number and uncorrected for time/interest. Randy would have > a much better opinion on this subject. > My opinion on the (whole) subject is rather simple: GUIs have their advantages and disadvantages, console apps have their advantages and disadvantages. Interestingly enough, these two types of applications seem to be rather complementary: that is, the things that GUI apps are good at, CLI apps are poor at, and vice-versa. For example, it's pretty miserable to have to delete every file that ends with "$" (something I do relatively often when moving data between Mac OSX and Windows) with a GUI, but it's a breeze with a decent shell interpreter. OTOH, converting an arbitrary set of files (not all of them) in a directory via some "drag and drop" application works a whole lot smoother than doing it via command line. The big mistake, IMO, comes when people claim "apps are only GUI apps" (e.g., Rene) or "apps are only console apps". Both have their uses. A *good* computer user will know when to use the appropriate form. As for GUI users being "more divorced" from the machine? Ha! I was around in the DOS days (and, indeed, before that). The use of console apps doesn't necessarily imply that the user knows any more about the machine. Perhaps this confusion exists only because to do reasonable *programming* tasks, the person generally has to know how to use a command line and that raises the percentage of people who know the machine for that group? hLater, Randy Hyde |