The All New Linux vs Windows MegaSuperThread

ErV · 08-21-2008, 01:13 PM

Quote:

Originally Posted by rocket357

The first example has two instances of "i", the second does not (or rather, the second instance of "i" is a pointer).

The problem is that second example has one instance of i.
Here is a bit modified second example:

Code:

#include <stdio.h>

class A{
public:
    int i;
};

class B: public virtual A{
public:
    B(){
	i = 3;
    }
};

class C: public virtual A{
public:
    C(){
	i = 4;
    }
};

class D: public B, public C{
};

int main(int argc, char **argv){
    D *d = new D();
    A *a = static_cast<A*>(d);
    B *b = static_cast<B*>(d);
    C *c = static_cast<C*>(d);
    printf("a->i=0x%08x\nb->i=0x%08x\nc->i=0x%08x\nd::B->i=0x%08x\nd::C->i=0x%08x\n", &(a->i), &(c->i),&(b->i),&(d->B::i), &(c->C::i));
    printf("a=0x%08x\nb=0x%08x\nc=0x%08x\nd=0x%08x\n", a, b, c, d);

    return(0);
}

On my system it prints following:

Quote:

a->i=0x0804a010
b->i=0x0804a010
c->i=0x0804a010
d::B->i=0x0804a010
d::C->i=0x0804a010
a=0x0804a010
b=0x0804a008
c=0x0804a00c
d=0x0804a008

As you can see, there is single instance of i located at one address.
But a,b and c points to different addresses, despite the fact they were created by casting "d" with static_cast pointer.

Read more about multiple inheritance and virtual classes, if you are interested. MSDN had some article on the subject, but there should be also other sources of information.

rocket357 · 08-21-2008, 01:35 PM

Quote:

Originally Posted by ErV

On my system it prints following:

As you can see, there is single instance of i located at one address.
But a,b and c points to different addresses, despite the fact they were created by casting "d" with static_cast pointer.

Read more about multiple inheritance and virtual classes, if you are interested. MSDN had some article on the subject, but there should be also other sources of information.

Interesting...I was under the impression that there was a second instance, and it pointed to the first instance.

Thanks... I'm learning a lot heh.

ussr_1991 · 08-22-2008, 03:36 AM

Quote:

Originally Posted by ErV

IMHO, this is not possible. No matter what you use, you'll have to install something to make your application work. In case of java you'll have to install java runtime environment (which may or may not be available for that platform). In case of perl/python/other script language, you'll have to install interpreter (which may or may not be available for your platform). In case of C/C++/other compiled language, you'll have to compile your program. Or you might need to install some libraries.

Language itself doesn't run on any platform, it needs compiler/interpreter to work. If you want to make portable applications, it doesn't matter much what you use (java, C, C++, python, etc), as long as you avoid platform-dependant components.

Well, true for apps that made from Java and most other language, but what is typical antivirus system reuirment? Do they say need XXX [put in your favourite language here] compiler, runtime? No.

This is what I got it http://service1.symantec.com/support...=tranus_con_br (Ok, Symantec products are laggers, point is unless Internet Explorer itself has a compiler feature, I see no reason why there is a need for compiler. (Feel free to correct if I am wrong. Is it that C / C# Compiler are defaultly installed in most OS because OS itself also need 1 compiler / interpreter before the source code of that OS (GNU, Mac, Unix, Windows etc, put in 1 favourite here.) can even run!)

ussr_1991 · 08-22-2008, 03:47 AM

Quote:

Originally Posted by ErV

It is true about C, but I wouldn't say that about C++.
Take a look at this:

Code:

#include <stdio.h>
 
class A{
public:
    int i;
};
 
class B: public A{
public:
    B(){
    i = 3;
    }
};
 
class C: public A{
public:
    C(){
    i = 4;
    }
};
 
class D: public B, public C{
};
 
int main(int argc, char **argv){
    D *d = new D();
    B *b = static_cast<B*>(d);
    C *c = static_cast<C*>(d);
    printf("b->i == %d;\nc->i == %d;\n", b->i, c->i);
 
    return(0);
}

This program will print:

Code:

b->i == 3;
c->i == 4;

Now take a look at this:

Code:

#include <stdio.h>
 
class A{
public:
    int i;
};
 
class B: public virtual A{
public:
    B(){
    i = 3;
    }
};
 
class C: public virtual A{
public:
    C(){
    i = 4;
    }
};
 
class D: public B, public C{
};
 
int main(int argc, char **argv){
    D *d = new D();
    B *b = static_cast<B*>(d);
    C *c = static_cast<C*>(d);
    printf("b->i == %d;\nc->i == %d;\n", b->i, c->i);
 
    return(0);
}

This will print:

Code:

b->i == 4;
c->i == 4;

Interesting, isn't it?

Now imagine that in this virtual class A has virtual function "f()", which is overrided (in different ways) in both "B" and "C", and both "B" and "C" also introduce several newer virtual functions, and several new class members. Both "B" and "C" are ancestors of "D". And notice that using we can cast D* to A*, B* and C*. Now the fun part. Think about it: How exactly does static_cast sort this mess out (imagine we case D* to A*, and then call virtual function of A overrided in D)? How exactly are class members stored within D? How exactly table of virtual functions is stored? How come that when we cast D* into B* or C* non-virtual functions of B and C can correctly access class members of A?
If you think about whole this concept for some time, quite a lot of questions will appear.

There are many other interesting things to think about in C++, like what exactly happens within new/delete calls, what happens in the function which calls main() function, etc. It isn't "bare metal" level language.

Ok, although I wont be fully understand this program, other than knowing

Code:

printf("b->i == %d;\nc->i == %d;\n", b->i, c->i);

means print from
"b- >i ==" (next line = \n) [Actual value of class b's where i = 3, as the code B(){i = 3;} implies.]

"c- >i ==" (next line = \n, which produced an empty line) [Actual value of class c's where i = 4, as the code C(){i = 4;} implies.]

ussr_1991 · 08-22-2008, 03:51 AM

By the way, how come they compiled as .h, what is this? From Linux Kernel to some other Linux apps that I have downloaded, there sure to be .h files. And to people who have said above that C / C# is platform independent but must be compiled on each platform differently, so does it mean that there is an option to compile as mac (.app / .pkg / .tar.gz / .pkg.gz)), windows (.exe / .msi) as well as unix (including linux / gnu which has .tar.gz / .tar.bz2 and possibly more, I am not sure) and even better which has .deb, .rpm and .yum installers??

ErV · 08-22-2008, 03:58 AM

Quote:

Originally Posted by ussr_1991

Well, true for apps that made from Java and most other language, but what is typical antivirus system reuirment? Do they say need XXX [put in your favourite language here] compiler, runtime? No.

Antivirus is already compiled for specific OS/platform/CPU architecture, so your requirement about "language" have nothing to do with antivirus. Take your antivirus and move it to different CPU architecture or another OS, and it won't work.

Quote:

Originally Posted by ussr_1991

I see no reason why there is a need for compiler.

There is need for a compiler, because program was originally created by compiling source code. You were talking about language that wont require installing anything. I suppose you are just asking questions incorrect way. Maybe someone else will explain, because I'm not in the mood.

AceofSpades19 · 08-22-2008, 11:18 AM

Quote:

Originally Posted by ussr_1991

By the way, how come they compiled as .h, what is this? From Linux Kernel to some other Linux apps that I have downloaded, there sure to be .h files. And to people who have said above that C / C# is platform independent but must be compiled on each platform differently, so does it mean that there is an option to compile as mac (.app / .pkg / .tar.gz / .pkg.gz)), windows (.exe / .msi) as well as unix (including linux / gnu which has .tar.gz / .tar.bz2 and possibly more, I am not sure) and even better which has .deb, .rpm and .yum installers??

C++ actually. .tar.gz/.bz2 are archiving formats, so you can't really compile into an achive, you compile source code into an exectutable. All those packaging formats that you listed are just basically a .tar.bz2 with special shell scripts that put the files in the right place.

ussr_1991 · 08-23-2008, 02:35 AM

So am I right to guess that in C / C# etc, actually it has compiled into various executable like .h files. Then it will (can be) comiled into .exe,.msi or .app , .pkg.gz as well as .deb,.rpm,.yum etc. But isnt .exe an executable (windows only) itself. Like CPU-Z http://www.filehippo.com/download_cpuz/ etc.

ErV · 08-23-2008, 04:26 AM

Quote:

Originally Posted by ussr_1991

actually it has compiled into various executable like .h files.

.h isn't an executable. And C/C++ program can't be compiled into *.h.

Quote:

Originally Posted by ussr_1991

Then it will (can be) comiled into .exe,.msi or .app , .pkg.gz as well as .deb,.rpm,.yum etc.

.msi, .pkg.gz, .deb, .rpm and .yum aren't executables. They are installation packages, somewhat similar to archives (.rar, .zip, .7z, .arj, .tar.gz, .tar.bz2, etc) And program can't be compiled into .msi, .pkg.gz, .deb, .rpm and .yum.
.msi - is windows installation package which is opened by windows installer. It isn't executable. .pkg.gz, .deb, .rpm and .yum are installation packages for various distributions, but they aren't executed, they are unpacked and then their contents are installed.

Honestly, learn a bit about C/C++ and operating systems. Right now you are asking "newbie" questions, and you are confusing completely different things. At least understand that "compiling"(there is also linking, by the way) is "the translation of source code into object code by a compiler.", and most formats you have listed (.h, .msi, .pkg.gz, .deb, .rpm, .yum) aren't object code.

AceofSpades19 · 08-23-2008, 12:41 PM

Quote:

Originally Posted by ussr_1991

So am I right to guess that in C / C# etc, actually it has compiled into various executable like .h files. Then it will (can be) comiled into .exe,.msi or .app , .pkg.gz as well as .deb,.rpm,.yum etc. But isnt .exe an executable (windows only) itself. Like CPU-Z http://www.filehippo.com/download_cpuz/ etc.

Did you not read my post?, first of all, for the second time, its C/C++, C# is a proprietary language for MS .Net. Linux exectutables have no extension. As stated in the above post, .deb, .rpm etc. are packaging formats, that if you read my above post, they execute a script to put files in the correct spot. AFAIK .yum isn't even a package format, yum is a program to manage .rpm. .h files are header files included into .c and .cpp files(source code) that is then compiled then linked it to make a machine readable file that is called an executable file. To summerize, a compile compiles some source files into an executable that is then put into a packaging format that has some scripts to put the files in the correct spots

rocket357 · 08-23-2008, 07:44 PM

Quote:

Originally Posted by AceofSpades19

Did you not read my post?, first of all, for the second time, its C/C++, C# is a proprietary language for MS .Net. Linux exectutables have no extension. As stated in the above post, .deb, .rpm etc. are packaging formats, that if you read my above post, they execute a script to put files in the correct spot. AFAIK .yum isn't even a package format, yum is a program to manage .rpm. .h files are header files included into .c and .cpp files(source code) that is then compiled then linked it to make a machine readable file that is called an executable file. To summerize, a compile compiles some source files into an executable that is then put into a packaging format that has some scripts to put the files in the correct spots

To summarize:

On Linux:

Building the program:
my_program.c(pp) + my_program.h -> my_program (the executable) -> my_program.rpm or my_program.tar.bz2 or my_program.deb or my_program.tar.gz

Installing the program:
my_program.rpm or my_program.tar.bz2 or my_program.deb or my_program.tar.gz -> my_program (the executable, + all support files and libs and such)

On Windows:

Building the program:
my_program.c + my_program.h -> my_program.exe -> my_program.msi (or another exe installer, or a .zip archive, which is sorta like the deb/rpm/tar.bz2/tar.gz formats above).

Installing the program:
my_program.msi or my_program_setup.exe or my_program.zip -> my_program.exe (plus dll's required to run and such).

C#, as ace stated, is an entirely different language. C# is a member of the .NET family of languages, and as such it benefits from the .NET runtime (can "consume" objects created in other .NET languages, can create objects for use in other .NET languages, less vulnerable because of the .NET runtime's checks, etc...), but it also suffers from the cons of the .NET runtime (Windows-only (for the most part), requires the .NET runtime (can't execute without it), etc...).

Edit - .h files are "header" files that contain declarations (constants, function declarations, etc...) so the .c and .cpp source files don't get clustered, and so programs that want to use the program that the .h file belongs to can know what the "interface" to the program is. Read up on Java interfaces, ussr_1991...they're sorta like that.

ussr_1991 · 08-24-2008, 03:04 AM

Ok sorry for asking such "noob" questions. I do not use C yet. Anyway, now I get clearer on all these stuffs and cleared the misunderstandings.

Now I see that .c / .cpp are the source code, on Unix, there is no extensions for executable (Maybe Macintosh is an exception that uses .app) and basically all platform starts with .c (.cpp) + .h .

Then all can conclude that C files and H files are both "Parents" while the No extensions or .exe / .app is the "Child" (Compiled from the Parent) which can be relate into .deb, .tar.gz, .tar.bz2, .msi as "Grand Children" (Archived from the true executables like .exe , No extensions.)

Only Interesting point is no extensions and yet the system take it as executable. (Is that automatically assumed??) That is interesting, maybe for properitary users as anyone tried open files without extensions will sure asked what do you want to open as. (It still work, but not from double-click then with the application open automatically, it prompts.)

Edit: On GNU, it is possible to manually set it as executable or not even in GUI. The main point is does it automatically recognized?

For this, AFAIK, I think it has to do with MIME type. Wow!!

rocket357 · 08-24-2008, 04:23 AM

Quote:

Originally Posted by ussr_1991

Only Interesting point is no extensions and yet the system take it as executable. (Is that automatically assumed??) That is interesting, maybe for properitary users as anyone tried open files without extensions will sure asked what do you want to open as.

Look up magic numbers...

Basically, Windows assumes it is executable if it has .exe on the end. So if I accidentally name a text file "file.exe", and then I double click it, Windows will throw a ton of errors. This is bad.

On Unix, the first few bytes of a file determine the file type, regardless of extension. Executables (in the purest sense...compiled code), will have ELF in the first few bytes. If the file starts with "#!", then the text that follows it will determine what program to use to run the file (that's why bash scripts have #!/bin/bash or #!/bin/sh as the first line...).

Edit - this is why you can run a Python/Perl/etc.. script like an executable without calling the interpreter...but the file has to be given executable permissions and it has to have a shebang line (the "#!" thing) as the first line in the file.

ussr_1991 · 08-25-2008, 12:59 AM

Quote:

Originally Posted by rocket357

Look up magic numbers...

Basically, Windows assumes it is executable if it has .exe on the end. So if I accidentally name a text file "file.exe", and then I double click it, Windows will throw a ton of errors. This is bad.

On Unix, the first few bytes of a file determine the file type, regardless of extension. Executables (in the purest sense...compiled code), will have ELF in the first few bytes. If the file starts with "#!", then the text that follows it will determine what program to use to run the file (that's why bash scripts have #!/bin/bash or #!/bin/sh as the first line...).

Edit - this is why you can run a Python/Perl/etc.. script like an executable without calling the interpreter...but the file has to be given executable permissions and it has to have a shebang line (the "#!" thing) as the first line in the file.

Wow, I learned something new today.

Redbug · 08-25-2008, 03:32 PM

Ok...

This is my first and last whatever you want to call it... (rave?)

I started out with a TRS-80 I. Microsoft was in the ROM.
Progressed through upgrades thru a Model III.
This consumed several years.
A friend convinced me to go to an IBM clone. Wow. Color. Microsoft...
Since then I've been through many desktops.
Several years ago I started playing with linux. I've only played with a couple of flavors and am in no way qualified about anything. Got away from linux because the machine broke.

NOW... I am tired of the re-sets. I am tired of the 'secret' code of windoz. I'm tired of fixing the problem by reloading the entire system from the CDs up.

I like the look and feel of windoz. I like the games. I like the ease of installing new programs, plug-ins, etc. Until it breaks.

I really got away from linux because the most common response to my sometimes stupid questions was 'RTFM'. I READ the 'FM'! As time went on, I had less time to devote to my pastime so I quit. Well... I'm back and still very ignorant. Hopefully not as stupid.

Windoz is ok. Linux is better. When the machine breaks before the OS it is self explanatory. Security issues are less with linux. One is as pretty as the other. What makes linux worthwhile for me? Well... I'm unsure and undecided as of yet. For me to stay, 'RTFM' has to go. That is the reason I'm here... To see if 'RTFM' has died yet.

I've been helping people all my life. Usually about what they've earned and sometimes more. I've never left myself destitute but I have been bent.

If linux is to succeed, it REQUIRES support. Money bought outrageous support for microsoft. Linux don't got no money... Microsoft got really rich with just a few dollars from all of us. Linux isn't looking for a profit. What could they do with just a fraction of that money. Only google knows... Did I say that...

Treat linux like your own child. Help it grow up. Maybe Cain will be Abel this time.

I am loading my gun and placing it next to my mouse just in case I ever want to do this again. My apologies to everyone.