Significant Pure Assembler Application In MASM ?
in [ASM]
|
Prev: aeBIOS Test Request
Next: CMOVcc vs. Jcc
From: santosh on 8 Oct 2007 09:02 Herbert Kleebauer wrote: > santosh wrote: >> Herbert Kleebauer wrote: > >> >> It more than a "beginning." Tell me one reasonable thing that you >> >> can do with your Windows that I cannot do with my Ubuntu here. >> > >> > Try to execute a binary you generated with Linux ten years ago. >> >> Yes compile your kernel with a.out support added in. > > The file format isn't the problem (I don't think they will change > it every year). The problem seems to be the libraries and the kernel > API. And I don't care about the past, but there must be some day > where they declare a final version 1.0 of the API to which all > later versions will be backward compatible. It doesn't make any sense > to develop software for a continuously changing system. Every significant system has to change. The change from Windows 3.xx to the Win32 API was complicated. Again the change to the 64-bit Windows API will again involve some difficulties. This is why insulation layers like the C library exist. No one is to be blamed when you knowingly make your application depend on evolving interfaces. >> > In Windows I can execute DOS programs written twenty years ago >> > (and I hope MS will be forced by the user base to also include >> > 16 bit support in 64 bit Windows). >> >> Whatever. Why not also force them to support binaries written for the >> PDP, OS/360 and MULTICS? > > ??? All I expect is, that when I write software for a system, this > software will also run on a new version of the same system. Just > imagine, every new version of Acrobat reader couldn't display pdf > files generated for a previous version. You are over exaggerating. By and large for a volunteer based effort Linux has retained very good backwards compatibility. The kernel API has been quite stable for many years now. >> > For me Linux becomes an >> > alternative to Windows (as a desktop system) only if: >> > >> > 1. There is a version where they can guarantee that any BINARY >> > written for this version can be executed on any newer release >> > (for at least ten years). >> >> I think this guarantee is already there in practise. > > ??? Wasn't easy to find a binary of Midnight Commander which was > happy with my Linux version. Don't know if there is a NASM > binary which can be executed on all Linux versions not older than > two years. This not a problem with Linux per se, but some lacking object files. This problem exists on Windows too where applications often need specific versions of many DLLs. >> > 2. This also must be true for the graphics (multimedia) system. >> > This means, the OS and THE (we don't need more than one) >> > graphics system has to be unified like in Windows. >> >> Now you're talking like Betov. X Windows is universal under Linux and >> UNIXes. Integrating it into the kernel has not been done for obvious >> reasons. UNIXes run on a far wider variety of hardware than Windows >> and in situations where a GUI is not needed. > > But if Linux want to be a replacement for a mainstream OS like > Windows, there has to be a version with a bundled graphics interface > (by the OS and not by the distribution). The distribution _is_ the OS and your distinction probably arises from a neurotic dislike of multiplicity. Do you want the already taxed Linus to duplicate the efforts of the X developers? You are out of touch with reality for someone who proclaims every other post that assembly is not suitable for writing serious applications.
From: santosh on 8 Oct 2007 09:04 Herbert Kleebauer wrote: > Betov wrote: >> Herbert Kleebauer <klee(a)unibwm.de> �crivait > >> > if Linux want to be a replacement for a mainstream OS like >> > Windows, there has to be a version with a bundled graphics >> > interface (by the OS and not by the distribution). >> >> Yes. Do you think a GTK bet could be wise? GTK is not a graphics subsystem. It's a toolkit. > I don't know anything, but I think Linus refuses to add the graphical > subsystem to the core OS and X is much to slow for graphic games. With appropriate hardware acceleration X is comparable to Windows' GUI.
From: santosh on 8 Oct 2007 09:23 Betov wrote: > santosh <santosh.k83(a)gmail.com> �crivait news:feclhk$elk$1(a)aioe.org: > >> How exactly? Something like GTK is available wherever X is available. >> I think this fear of getting "locked in" is just paranoia. > > As you seem to be aware... does there exist something > like the Windows Debug APIs under Linux? Also the canonical Linux debugger GDB has a manual explaining it's implementation: <http://sourceware.org/gdb/current/onlinedocs/gdbint.html>
From: Robert Redelmeier on 8 Oct 2007 09:28 Herbert Kleebauer <klee(a)unibwm.de> wrote in part: >> > I don't know anything, but I think Linus refuses to add the >> > graphical subsystem to the core OS and X is much to slow for >> > graphic games. I don't know whether GTK works with OpenGL. Of course Linus refuses to add graphics to the kernel. In his opinion, there is no compelling reason to do so. I agree: 1) Kernel code on user data is difficult (walking pagemaps) and even the transition to/fro Ring0 is costly (cycles). 2) Everything graphical _can_ be done in userspace with ioperm() and memory mapping. 3) Of course X is slow -- it is a communications protocol more than a graphics system. I routinely run a browser on one machine and display the pages on another. 4) If you want tighter binding to the machine and hardware (and games often do), then use svgalib or write yer own. 5) One useful project for game porting might be an OpenDirectX accepting MS-DirectX calls and translating them into X or local device driver calls. But PC gaming loses to consoles. > Maybe you should ask in a linux group. I did this a year ago, > but without much success: > http://groups.google.com/group/comp.os.linux.development.apps/browse_frm/thread/2c17c983165f27d4/2de83fa1b524e4bb?#2de83fa1b524e4bb Doh! It is a FAQ and you should RTFM: http://www.kernel.org/pub/linux/docs/lkml/ You can also look up KGI. -- Robert
From: Betov on 8 Oct 2007 09:57
santosh <santosh.k83(a)gmail.com> �crivait news:fed95t$b8s$1(a)aioe.org: > Yes. The ptrace system call. This provides only "bare minimum" > facility. Building something like the RosAsm debugger on top of this > is likely to be a lot of work. See the link: > > <http://www.linuxmanpages.com/man2/ptrace.2.php> Many thanks. Yes, this seems to be OK. If i go for it, it will be all needed for having, at least, something similar to what i used for the first RosAsm Debugger. Additional question: Is this Function available at any time (like any API)? Or will something be required before simply calling for it? Or will a port of the given ptrace.h file be required? [... because i see that it is bound to the Kernel itself, at a source point of view... ] Betov. < http://rosasm.org > |