Q. Would the software we use today in general be better e.g. more advanced and faster than it is currently?
A. It would be as good, maybe better. Back in the day there were plenty of good operating systems and software packages competing with Microsoft. Gates bought them, outmanuevered them, or bludgeoned them with brute force marketing muscle.
I used and preferred Novell DOS (aka DrDos, originally from Digital Research) to MS-DOS. It required less memory, ran better, and had more features. SuperCalc, QuattroPro, and even Lotus were far superior to Excel in price, performance, and features.
Even today, I use Openoffice instead of Microsoft Office. I've been using Windows as an operating system only because I haven't had time to investigate Linux alternatives.
I used and preferred Novell DOS (aka DrDos, originally from Digital Research) to MS-DOS. It required less memory, ran better, and had more features. SuperCalc, QuattroPro, and even Lotus were far superior to Excel in price, performance, and features.
Even today, I use Openoffice instead of Microsoft Office. I've been using Windows as an operating system only because I haven't had time to investigate Linux alternatives.
How to connect to a mySQL database on a Linux machine from Windows terminals?
Q. Im planning on a new setup for our office, a Linux server that will have the mySQL database, all other terminals have windows OS like WIn98, Win2000 and tey will need to access the database from the Linux server how to do it?
A. There are so many ways, but I'd recommend making your application web-based and server-side only and access via a web browser. Ancient, unsupported systems like Microsoft Windows 98 are barely able to function in todays world.
Go for a LAMP system.
Go for a LAMP system.
Why is there a difference and what is it between assembly language in Linux and Windows?
Q. I am just wondering why the assembly languages for Windows and Linux are different since they are both based on the x86 architecture. And is there a basic assembly language that doesn't rely on an OS? And if so, what is it?
Ok, if they are the same, then why do the different OSs interact differently with it and is there a way to bypass the OS so that you can just program directly to the computer?
Ok, if they are the same, then why do the different OSs interact differently with it and is there a way to bypass the OS so that you can just program directly to the computer?
A. For a particular architecture (i.e. CPU type) the assembly language is the same. Realize that even modern intel CPUs have different instruction sets but in general most compilers stick to common instruction sets shared amoung all intel CPUs unless advanced instruction sets (aka extensions) are specifically enabled. MMX was one such extension.
Assembly really doesn't have much to do with device IO or drivers since assembly is *below* the operating system. In assembly, you write to or read from (poke/peek) memory locations which may be mapped to devices or be actual memory. If you are actually programming in assembly (not in a compiled language) then you'd just have to know what locations mean what. This "abstraction" is what the OS and compilers provide to higher level languages.
What you are confused about is binary executable format which *is* os dependent. Every executable binary contains information in it that helps the OS know how to run it and what it's called and so forth. Binaries contain the assembly instructions that needs to run but modern binaries are also often not self standing. The "assembly" code in a binary has to be "loaded" and run along with any other "shared" binary code fragments (i.e. shared libraries). This is where the portability breaks down. On the hardware abstraction side, there is also some runtime adjustments that the OS has to do in order to map the right locations into the assembly code. This is because hardware today are not in fixed predictable locations. The bios can move a device from one memory address to another at boot time or even at run time. This is basically what PnP is. It provides a way for the OS to modify how the bios positions hardware in memory to avoid conflicts. That is why if you are running an OS that is *not* PnP aware, you need to disable the feature in the bios so that the bios will initialize and fix those parameters for the hardware at boot time. Once the OS is done with relocation and device mapping, the "code" that is sent to the CPU is assembly and for all intents and purposes this code would be basically the same no matter what OS is used.
So what are some binary formats that are shared... well, ELF is one. Elf is used on various Unix and Unix-like OSs such as Linux and Solaris. Unfortunately binary compatibility is not a useful reality because it requires all the shared components to be compatible versions and format. In a sense, the WINE project in Linux is an attempt to emulate the Windows HAL (Hardware Abstraction Layer) in order to "load" a binary and do all of the necessary relocations for IO and shared components that windows does and then send it to the CPU. In a way, WINE is an attempt to create binary compatibility with windows "EXE" files.
Assembly really doesn't have much to do with device IO or drivers since assembly is *below* the operating system. In assembly, you write to or read from (poke/peek) memory locations which may be mapped to devices or be actual memory. If you are actually programming in assembly (not in a compiled language) then you'd just have to know what locations mean what. This "abstraction" is what the OS and compilers provide to higher level languages.
What you are confused about is binary executable format which *is* os dependent. Every executable binary contains information in it that helps the OS know how to run it and what it's called and so forth. Binaries contain the assembly instructions that needs to run but modern binaries are also often not self standing. The "assembly" code in a binary has to be "loaded" and run along with any other "shared" binary code fragments (i.e. shared libraries). This is where the portability breaks down. On the hardware abstraction side, there is also some runtime adjustments that the OS has to do in order to map the right locations into the assembly code. This is because hardware today are not in fixed predictable locations. The bios can move a device from one memory address to another at boot time or even at run time. This is basically what PnP is. It provides a way for the OS to modify how the bios positions hardware in memory to avoid conflicts. That is why if you are running an OS that is *not* PnP aware, you need to disable the feature in the bios so that the bios will initialize and fix those parameters for the hardware at boot time. Once the OS is done with relocation and device mapping, the "code" that is sent to the CPU is assembly and for all intents and purposes this code would be basically the same no matter what OS is used.
So what are some binary formats that are shared... well, ELF is one. Elf is used on various Unix and Unix-like OSs such as Linux and Solaris. Unfortunately binary compatibility is not a useful reality because it requires all the shared components to be compatible versions and format. In a sense, the WINE project in Linux is an attempt to emulate the Windows HAL (Hardware Abstraction Layer) in order to "load" a binary and do all of the necessary relocations for IO and shared components that windows does and then send it to the CPU. In a way, WINE is an attempt to create binary compatibility with windows "EXE" files.
Nec Projector Review
Plastic Shed Reviews
Ati Graphic Reviews
Nurse Uniforms Reviews
Cabochons Reviews
Inflatable Water Slides Reviews
Barcode Scanner Reviews
No comments:
Post a Comment