Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #32455 > unrolled thread
| Started by | rdelaney2001@gmail.com |
|---|---|
| First post | 2015-09-01 15:26 -0700 |
| Last post | 2015-09-24 12:04 -0400 |
| Articles | 20 on this page of 105 — 10 participants |
Back to article view | Back to comp.lang.java.programmer
questions re Javascript rdelaney2001@gmail.com - 2015-09-01 15:26 -0700
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-01 23:26 +0000
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-02 10:00 +0100
Re: questions re Javascript e.d.programmer@gmail.com - 2015-09-02 05:32 -0700
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-03 20:17 -0400
Re: questions re Javascript e.d.programmer@gmail.com - 2015-09-04 05:33 -0700
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:42 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-01 20:00 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-05 20:40 +0100
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-09-23 16:10 -0700
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-24 10:40 +0100
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-24 11:21 +0000
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-24 20:10 +0100
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-09-24 13:18 -0700
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 19:40 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 01:15 +0000
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:25 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 03:46 +0100
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 09:59 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 15:32 +0100
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-10-02 13:02 -0700
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-02 16:24 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 23:02 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-10-03 13:30 +0100
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-10-04 21:31 -0700
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-10-05 07:48 +0100
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 20:53 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:46 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:00 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 21:19 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:26 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 15:32 +0100
Re: questions re Javascript Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-24 16:58 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-24 21:45 +0000
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 18:27 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 19:53 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:03 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:34 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:46 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 09:56 -0400
Re: questions re Javascript Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-25 10:15 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 11:44 -0400
Re: questions re Javascript Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-09-25 14:09 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 15:15 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:45 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 22:48 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-28 03:29 +0000
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-28 00:02 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-28 11:33 +0000
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-28 10:44 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:42 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 22:51 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:38 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 22:59 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:47 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:48 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:53 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:52 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:03 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 21:25 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:41 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:11 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 22:19 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 22:27 -0400
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 22:30 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:42 -0400
Re: Aho, A. V., & Ullman, J. D. (1972). The theory of parsing, translation, and compiling. Englewood Cliffs, N.J: Prentice-Hall. Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 23:26 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 23:07 -0400
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-24 23:55 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:46 -0400
Re: questions re Javascript e.d.programmer@gmail.com - 2015-09-25 05:20 -0700
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-27 20:54 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 23:05 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-02 22:36 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-03 10:57 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-10-05 21:10 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-10-05 21:27 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-27 23:19 -0400
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 03:46 +0100
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 23:35 -0400
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-09-24 13:10 -0700
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 19:55 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 00:48 +0000
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 20:55 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 11:17 +0000
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 12:30 +0100
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 17:00 +0000
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 14:03 -0400
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 14:14 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 19:59 +0000
Re: questions re Javascript Jeff Higgins <jeff@invalid.invalid> - 2015-09-25 17:13 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 22:15 +0000
Re: questions re Javascript Lew <lewbloch@gmail.com> - 2015-10-02 13:07 -0700
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-10-03 16:48 +0100
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:02 -0400
Re: questions re Javascript Martin Gregorie <martin@address-in-sig.invalid> - 2015-09-25 17:32 +0000
Re: questions re Javascript Eternal Hope <laughingspam99@gmail.com> - 2015-09-25 03:45 +0100
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:13 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 21:58 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:34 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-24 22:35 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 22:51 -0400
Re: questions re Javascript Arne Vajhøj <arne@vajhoej.dk> - 2015-09-24 23:00 -0400
Re: questions re Javascript Jerry Stuckle <jstucklex@attglobal.net> - 2015-09-25 10:17 -0400
Re: questions re Javascript Tim Slattery <tim@risingdove.com> - 2015-09-24 12:04 -0400
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-09-25 10:15 -0400 |
| Message-ID | <mu3kr9$hjo$1@dont-email.me> |
| In reply to | #32689 |
On 9/25/2015 9:56 AM, Jerry Stuckle wrote:
>
> In ANY operating system, code is compiled into an object file. The
> result is machine code. However, an additional step is required to link
> in necessary libraries and other files.
>
> That does not mean the output of the compiler is not machine code. It's
> just not executable-ready machine code. Once the link step is done, the
> program is ready to run without any other program such as a jvm.
If all the executables are "ready to run without any other
program," does that mean I can safely delete ld.so from my Unix box?
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-25 11:44 -0400 |
| Message-ID | <mu3q0h$6n7$1@dont-email.me> |
| In reply to | #32693 |
On 9/25/2015 10:15 AM, Eric Sosman wrote: > On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >> >> In ANY operating system, code is compiled into an object file. The >> result is machine code. However, an additional step is required to link >> in necessary libraries and other files. >> >> That does not mean the output of the compiler is not machine code. It's >> just not executable-ready machine code. Once the link step is done, the >> program is ready to run without any other program such as a jvm. > > If all the executables are "ready to run without any other > program," does that mean I can safely delete ld.so from my Unix box? > ld.so is simply a loader in Linux. It's job is to simply read the file from disk, load it into memory and create any fixups. The same could easily be done in the Linux kernel, as it is in other OS's. It just isn't. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-09-25 14:09 -0400 |
| Message-ID | <mu42h4$9c8$1@dont-email.me> |
| In reply to | #32698 |
On 9/25/2015 11:44 AM, Jerry Stuckle wrote:
> On 9/25/2015 10:15 AM, Eric Sosman wrote:
>> On 9/25/2015 9:56 AM, Jerry Stuckle wrote:
>>>
>>> In ANY operating system, code is compiled into an object file. The
>>> result is machine code. However, an additional step is required to link
>>> in necessary libraries and other files.
>>>
>>> That does not mean the output of the compiler is not machine code. It's
>>> just not executable-ready machine code. Once the link step is done, the
>>> program is ready to run without any other program such as a jvm.
>>
>> If all the executables are "ready to run without any other
>> program," does that mean I can safely delete ld.so from my Unix box?
>>
>
> ld.so is simply a loader in Linux. It's job is to simply read the file
> from disk, load it into memory and create any fixups. The same could
> easily be done in the Linux kernel, as it is in other OS's. It just isn't.
"Simply?" That's why it's so compact, right?
Question: Without those fixups -- that is, without locating the
shared libraries required by the program, without patching up jump
tables and the like, without adjusting pointers and so on, without
taking care of memory mappings -- without all these fixups, I ask,
would the program run at all? No, of course not. It follows that
the compiler's output *does* require assistance from another program
before it can run ...
... and that using "it needs outside help" as a criterion to
distinguish compiled from interpretive implementations simply doesn't
hold up to scrutiny. Aside from the cold-boot image, *everything*
needs a helping hand before (and usually during) execution.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-25 15:15 -0400 |
| Message-ID | <mu46cs$pbg$1@dont-email.me> |
| In reply to | #32704 |
On 9/25/2015 2:09 PM, Eric Sosman wrote: > On 9/25/2015 11:44 AM, Jerry Stuckle wrote: >> On 9/25/2015 10:15 AM, Eric Sosman wrote: >>> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>>> >>>> In ANY operating system, code is compiled into an object file. The >>>> result is machine code. However, an additional step is required to >>>> link >>>> in necessary libraries and other files. >>>> >>>> That does not mean the output of the compiler is not machine code. >>>> It's >>>> just not executable-ready machine code. Once the link step is done, >>>> the >>>> program is ready to run without any other program such as a jvm. >>> >>> If all the executables are "ready to run without any other >>> program," does that mean I can safely delete ld.so from my Unix box? >>> >> >> ld.so is simply a loader in Linux. It's job is to simply read the file >> from disk, load it into memory and create any fixups. The same could >> easily be done in the Linux kernel, as it is in other OS's. It just >> isn't. > > "Simply?" That's why it's so compact, right? > > Question: Without those fixups -- that is, without locating the > shared libraries required by the program, without patching up jump > tables and the like, without adjusting pointers and so on, without > taking care of memory mappings -- without all these fixups, I ask, > would the program run at all? No, of course not. It follows that > the compiler's output *does* require assistance from another program > before it can run ... > > ... and that using "it needs outside help" as a criterion to > distinguish compiled from interpretive implementations simply doesn't > hold up to scrutiny. Aside from the cold-boot image, *everything* > needs a helping hand before (and usually during) execution. > That is part of the OS's responsibility. In the case of Linux, it is handled by ld.so. However, in most other OS's, it is handled by the OS itself. And once the program is loaded and control turned over to it, ld.so has nothing left to do. Don't confuse loading a program into memory with running an interpreter. They are two different things. But only Java programmers seem to have trouble with the difference. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-09-27 20:45 -0400 |
| Message-ID | <mua2j9$deo$2@speranza.aioe.org> |
| In reply to | #32706 |
On 9/25/2015 3:15 PM, Jerry Stuckle wrote: > That is part of the OS's responsibility. In the case of Linux, it is > handled by ld.so. However, in most other OS's, it is handled by the OS > itself. No. All Unix and Unix like also have ld. DOS has LINK. Windows has link. OS/W has link. OpenVMS have LINK. zOS has linkage editor. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-27 22:48 -0400 |
| Message-ID | <mua9lb$dee$1@dont-email.me> |
| In reply to | #32718 |
On 9/27/2015 8:45 PM, Arne Vajhøj wrote: > On 9/25/2015 3:15 PM, Jerry Stuckle wrote: >> That is part of the OS's responsibility. In the case of Linux, it is >> handled by ld.so. However, in most other OS's, it is handled by the OS >> itself. > > No. > > All Unix and Unix like also have ld. > DOS has LINK. > Windows has link. > OS/W has link. > OpenVMS have LINK. > zOS has linkage editor. > > Arne > LINK is not the same as ld.so. But a programmer should know that. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2015-09-28 03:29 +0000 |
| Message-ID | <muac74$du7$1@dont-email.me> |
| In reply to | #32723 |
On Sun, 27 Sep 2015 22:48:07 -0400, Jerry Stuckle wrote: > On 9/27/2015 8:45 PM, Arne Vajhøj wrote: >> On 9/25/2015 3:15 PM, Jerry Stuckle wrote: >>> That is part of the OS's responsibility. In the case of Linux, it is >>> handled by ld.so. However, in most other OS's, it is handled by the >>> OS itself. >> >> No. >> >> All Unix and Unix like also have ld. >> DOS has LINK. >> Windows has link. >> OS/W has link. >> OpenVMS have LINK. >> zOS has linkage editor. >> >> Arne >> >> > LINK is not the same as ld.so. But a programmer should know that. Arne is right to say that ld is the same as LINK: ld is the compile-time linker needed to make compiler output executable and to fix up all static references. But he is wrong to conflate ld with ld.so - ld.so is a dynamic linking loader, so apart from its obvious job of loading an executable into memory, it also finds and loads all the dynamically linked libraries referenced by the executable and fixes up their references. FWIW, in Linux (and probably most other Unices) the code needed to load and link dynamic libraries is in libdl.so and is embodied by the four functions dlopen(), dlsym(), dlclose(), dlerror(). You only call these functions from application code if you need C plugins whose names are not known when the executable is loaded because they will be obtained later from a configuration file or as a result of user interaction. Getting back onto a Java-related topic, Java makes an exactly equivalent facility available via the abstract ClassLoader class, which can be used in exactly the same way to load Java plugins and as a convenient way to select which program is to be run from a jarfile containing several programs. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-28 00:02 -0400 |
| Message-ID | <muae0v$p2l$1@dont-email.me> |
| In reply to | #32730 |
On 9/27/2015 11:29 PM, Martin Gregorie wrote: > On Sun, 27 Sep 2015 22:48:07 -0400, Jerry Stuckle wrote: > >> On 9/27/2015 8:45 PM, Arne Vajhøj wrote: >>> On 9/25/2015 3:15 PM, Jerry Stuckle wrote: >>>> That is part of the OS's responsibility. In the case of Linux, it is >>>> handled by ld.so. However, in most other OS's, it is handled by the >>>> OS itself. >>> >>> No. >>> >>> All Unix and Unix like also have ld. >>> DOS has LINK. >>> Windows has link. >>> OS/W has link. >>> OpenVMS have LINK. >>> zOS has linkage editor. >>> >>> Arne >>> >>> >> LINK is not the same as ld.so. But a programmer should know that. > > Arne is right to say that ld is the same as LINK: ld is the compile-time > linker needed to make compiler output executable and to fix up all static > references. > > But he is wrong to conflate ld with ld.so - ld.so is a dynamic linking > loader, so apart from its obvious job of loading an executable into > memory, it also finds and loads all the dynamically linked libraries > referenced by the executable and fixes up their references. > > FWIW, in Linux (and probably most other Unices) the code needed to load > and link dynamic libraries is in libdl.so and is embodied by the four > functions dlopen(), dlsym(), dlclose(), dlerror(). You only call these > functions from application code if you need C plugins whose names are not > known when the executable is loaded because they will be obtained later > from a configuration file or as a result of user interaction. > > Getting back onto a Java-related topic, Java makes an exactly equivalent > facility available via the abstract ClassLoader class, which can be used > in exactly the same way to load Java plugins and as a convenient way to > select which program is to be run from a jarfile containing several > programs. > > Yes, I realize that ld.so is different from ld. But I think you're correct in that he has the two mixed up. And yes, I'm familiar with libdl.so - it can come in quite handy. I'm not sure if it is used by ld.so or not - I haven't looked at that code (and quite frankly, don't care about that level). And while libdl.so performs a similar function as ClassLoader, the results are much different. The dynamic library is machine code, but you still have to locate every entry point you wish to use. The ClassLoader is compiled Java code who's methods are known when it is loaded, but it is still compiled Java code which must be interpreted by the jvm. It does, however, make the Java class much easier to deal with. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2015-09-28 11:33 +0000 |
| Message-ID | <mub8hv$d71$1@dont-email.me> |
| In reply to | #32731 |
On Mon, 28 Sep 2015 00:02:35 -0400, Jerry Stuckle wrote: > And while libdl.so performs a similar function as ClassLoader, the > results are much different. The dynamic library is machine code, but > you still have to locate every entry point you wish to use. The > ClassLoader is compiled Java code who's methods are known when it is > loaded, but it is still compiled Java code which must be interpreted by > the jvm. It does, however, make the Java class much easier to deal > with. > I did say 'similar function' rather than 'same function', and ClassLoader is a little easier to use once you've discovered how. At least, unlike libdl.so it can't discover and report name clashes at run time. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-28 10:44 -0400 |
| Message-ID | <mubjk0$rnd$1@dont-email.me> |
| In reply to | #32732 |
On 9/28/2015 7:33 AM, Martin Gregorie wrote: > On Mon, 28 Sep 2015 00:02:35 -0400, Jerry Stuckle wrote: > >> And while libdl.so performs a similar function as ClassLoader, the >> results are much different. The dynamic library is machine code, but >> you still have to locate every entry point you wish to use. The >> ClassLoader is compiled Java code who's methods are known when it is >> loaded, but it is still compiled Java code which must be interpreted by >> the jvm. It does, however, make the Java class much easier to deal >> with. >> > I did say 'similar function' rather than 'same function', and ClassLoader > is a little easier to use once you've discovered how. At least, unlike > libdl.so it can't discover and report name clashes at run time. > > I agree - I was just pointing out that ClassLoader is much easier to use. Load the class and you're ready to go. Not so much with libdl.so. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-09-27 20:42 -0400 |
| Message-ID | <mua2dh$deo$1@speranza.aioe.org> |
| In reply to | #32698 |
On 9/25/2015 11:44 AM, Jerry Stuckle wrote: > On 9/25/2015 10:15 AM, Eric Sosman wrote: >> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>> >>> In ANY operating system, code is compiled into an object file. The >>> result is machine code. However, an additional step is required to link >>> in necessary libraries and other files. >>> >>> That does not mean the output of the compiler is not machine code. It's >>> just not executable-ready machine code. Once the link step is done, the >>> program is ready to run without any other program such as a jvm. >> >> If all the executables are "ready to run without any other >> program," does that mean I can safely delete ld.so from my Unix box? >> > > ld.so is simply a loader in Linux. It's job is to simply read the file > from disk, load it into memory and create any fixups. The same could > easily be done in the Linux kernel, as it is in other OS's. It just isn't. But the fact that it is not done by the OS means that that the input is not directly executable, which is the topic under discussion. BTW, it would not be easy to make the OS do this function. If you have several libraries with the referenced functions, then the OS would not know which to pick (ld knows because they are explicit specified). Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-27 22:51 -0400 |
| Message-ID | <mua9qu$dsp$1@dont-email.me> |
| In reply to | #32717 |
On 9/27/2015 8:42 PM, Arne Vajhøj wrote: > On 9/25/2015 11:44 AM, Jerry Stuckle wrote: >> On 9/25/2015 10:15 AM, Eric Sosman wrote: >>> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>>> >>>> In ANY operating system, code is compiled into an object file. The >>>> result is machine code. However, an additional step is required to >>>> link >>>> in necessary libraries and other files. >>>> >>>> That does not mean the output of the compiler is not machine code. >>>> It's >>>> just not executable-ready machine code. Once the link step is done, >>>> the >>>> program is ready to run without any other program such as a jvm. >>> >>> If all the executables are "ready to run without any other >>> program," does that mean I can safely delete ld.so from my Unix box? >>> >> >> ld.so is simply a loader in Linux. It's job is to simply read the file >> from disk, load it into memory and create any fixups. The same could >> easily be done in the Linux kernel, as it is in other OS's. It just >> isn't. > > But the fact that it is not done by the OS means that that the input is > not directly executable, which is the topic under discussion. > > BTW, it would not be easy to make the OS do this function. If you have > several libraries with the referenced functions, then the OS would not > know which to pick (ld knows because they are explicit specified). > > Arne > > Actually, I have to rephrase that. ld.so IS part of the kernel - it is a dynamic link library loaded by the kernel as necessary. And it is the kernel's responsibility to ensure the application and all necessary libraries are loaded. Once again you show you are arguing from a position of complete ignorance. But that's pretty normal for you. You really should have stopped while you were behind. You're only continuing to make a bigger fool of yourself with every pose. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-09-27 20:38 -0400 |
| Message-ID | <mua269$d3r$1@speranza.aioe.org> |
| In reply to | #32689 |
On 9/25/2015 9:56 AM, Jerry Stuckle wrote: > On 9/24/2015 10:46 PM, Arne Vajhøj wrote: >> On 9/24/2015 10:34 PM, Jerry Stuckle wrote: >>> And yes, object code is considered machine code by virtually programmers >>> with reasonable experience in multiple platforms and languages. Only >>> Java programmers and troll try to make the distinction. >> >> The fact that you call it machine code does not make it directly >> executable. >> >> The question was not whether it was byte cod eor machine code. >> >> The question was whether it was directly executable. >> >> It is not. > In ANY operating system, code is compiled into an object file. Actually not. There are a few exceptions. Like DOS and compilation to COM files. > The > result is machine code. However, an additional step is required to link > in necessary libraries and other files. > > That does not mean the output of the compiler is not machine code. It's > just not executable-ready machine code. Once the link step is done, the > program is ready to run without any other program such as a jvm. Exactly. Which made the original claim of the output being directly executable false. It is not. The output from an additional step make it directly executable. >>>> Given that the naming convention is also used in C#, VB.NET, PHP, >>>> UCSD Pascal, then I think that it is you that are way behind >>>> in knowing about other programming languages. >>> >>> Wrong answer. VB.NET and PHP are interpreted languages. >> >> Wrong. >> >> VB.NET is compiled. By the VB.NET compiler - the vbc command. > > Yes, but it is not executable code. It still requires the vb runtime > executable (not just libraries). VB.NET compiler compiles to MSIL. There are no such thing as a VB.NET runtime executable. VB.NET only relies on .NET framework. >>> UCSD Pascal >>> (which, unlike you, I DID use) compiled to P-code. >> >> Which is byte code. >> > > That is true - and it required the p-code runtime exeuctable to do it. Just like Java requires the java executable. And guess what UCSD Pascal was called a compiler. >>> And C# is it's own >>> thing. It compiles to an executable, >> >> Wrong. >> >> It compiles to MSIL byte code. >> > > C# can also be compiled to executable code. It just requires the .net > libraries. But it is an executable, not byte code as you claim. There are no switch to the C# compiler to generate native code. It always generate MSIL. And MSIL is byte code. >>> but requires the .NET framework. >>> Really not that much different than requiring OS libraries, except that >>> .NET is shipped separately. >> >> ,NET uses the same model as Java. >> > > Again, it shows how little you know. I can call .NET from C/C++ and > assembler, for instance. And those are all compiled (or in the case of > assembler, assembled) languages. Sure. But that does not make .NET native. I can also call Java from C/C++. That does not make Java byte code native. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-09-27 22:59 -0400 |
| Message-ID | <muaab6$f1u$1@dont-email.me> |
| In reply to | #32716 |
On 9/27/2015 8:38 PM, Arne Vajhøj wrote: > On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >> On 9/24/2015 10:46 PM, Arne Vajhøj wrote: >>> On 9/24/2015 10:34 PM, Jerry Stuckle wrote: >>>> And yes, object code is considered machine code by virtually >>>> programmers >>>> with reasonable experience in multiple platforms and languages. Only >>>> Java programmers and troll try to make the distinction. >>> >>> The fact that you call it machine code does not make it directly >>> executable. >>> >>> The question was not whether it was byte cod eor machine code. >>> >>> The question was whether it was directly executable. >>> >>> It is not. > >> In ANY operating system, code is compiled into an object file. > > Actually not. There are a few exceptions. Like DOS and compilation > to COM files. > Wrong once again. DOS compiled to object files, and the linker created the .com file. >> The >> result is machine code. However, an additional step is required to link >> in necessary libraries and other files. >> >> That does not mean the output of the compiler is not machine code. It's >> just not executable-ready machine code. Once the link step is done, the >> program is ready to run without any other program such as a jvm. > > Exactly. > > Which made the original claim of the output being directly executable > false. > > It is not. > > The output from an additional step make it directly executable. > I never said it was directly executable. Those are your words. I said the output is machine code - which it is. >>>>> Given that the naming convention is also used in C#, VB.NET, PHP, >>>>> UCSD Pascal, then I think that it is you that are way behind >>>>> in knowing about other programming languages. >>>> >>>> Wrong answer. VB.NET and PHP are interpreted languages. >>> >>> Wrong. >>> >>> VB.NET is compiled. By the VB.NET compiler - the vbc command. >> >> Yes, but it is not executable code. It still requires the vb runtime >> executable (not just libraries). > > VB.NET compiler compiles to MSIL. > > There are no such thing as a VB.NET runtime executable. > > VB.NET only relies on .NET framework. > Try again. VB.NET can also be compiled to an executable. >>>> UCSD Pascal >>>> (which, unlike you, I DID use) compiled to P-code. >>> >>> Which is byte code. >>> >> >> That is true - and it required the p-code runtime exeuctable to do it. > > Just like Java requires the java executable. > > And guess what UCSD Pascal was called a compiler. > That's right. And it output code which had to be interpreted - not machine code. >>>> And C# is it's own >>>> thing. It compiles to an executable, >>> >>> Wrong. >>> >>> It compiles to MSIL byte code. >>> >> >> C# can also be compiled to executable code. It just requires the .net >> libraries. But it is an executable, not byte code as you claim. > > There are no switch to the C# compiler to generate native code. > > It always generate MSIL. > > And MSIL is byte code. > ROFLMAO! Still arguing that lost cause? Just to prove once again you are arguing from ignorance, see https://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx >>>> but requires the .NET framework. >>>> Really not that much different than requiring OS libraries, except that >>>> .NET is shipped separately. >>> >>> ,NET uses the same model as Java. >>> >> >> Again, it shows how little you know. I can call .NET from C/C++ and >> assembler, for instance. And those are all compiled (or in the case of >> assembler, assembled) languages. > > Sure. > > But that does not make .NET native. > > I can also call Java from C/C++. > > That does not make Java byte code native. > > Arne > Once again you are arguing from a position of ignorance. You should learn when to stop instead of continuing to make a bigger fool of yourself with each post. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-10-02 22:47 -0400 |
| Message-ID | <munfjv$gtn$5@speranza.aioe.org> |
| In reply to | #32725 |
On 9/27/2015 10:59 PM, Jerry Stuckle wrote: > On 9/27/2015 8:38 PM, Arne Vajhøj wrote: >> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>> result is machine code. However, an additional step is required to link >>> in necessary libraries and other files. >>> >>> That does not mean the output of the compiler is not machine code. It's >>> just not executable-ready machine code. Once the link step is done, the >>> program is ready to run without any other program such as a jvm. >> >> Exactly. >> >> Which made the original claim of the output being directly executable >> false. >> >> It is not. >> >> The output from an additional step make it directly executable. > > I never said it was directly executable. Those are your words. I said > the output is machine code - which it is. Not true. Eternal hope wrote: #Well when I went to school (jeez, was it *that* long ago) a compiled #language was one where the compiler took source code as input and #produced native machine code that was directly executable on the #underlying hardware as output. Lew replied: #You misunderstood your classes. You replied: #No, he didn't. It was that way in my classes in the 1960's and 1970's, #also. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-03 10:48 -0400 |
| Message-ID | <muopmr$dds$2@dont-email.me> |
| In reply to | #32772 |
On 10/2/2015 10:47 PM, Arne Vajhøj wrote: > On 9/27/2015 10:59 PM, Jerry Stuckle wrote: >> On 9/27/2015 8:38 PM, Arne Vajhøj wrote: >>> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>>> result is machine code. However, an additional step is required to >>>> link >>>> in necessary libraries and other files. >>>> >>>> That does not mean the output of the compiler is not machine code. >>>> It's >>>> just not executable-ready machine code. Once the link step is done, >>>> the >>>> program is ready to run without any other program such as a jvm. >>> >>> Exactly. >>> >>> Which made the original claim of the output being directly executable >>> false. >>> >>> It is not. >>> >>> The output from an additional step make it directly executable. >> >> I never said it was directly executable. Those are your words. I said >> the output is machine code - which it is. > > Not true. > > Eternal hope wrote: > > #Well when I went to school (jeez, was it *that* long ago) a compiled > #language was one where the compiler took source code as input and > #produced native machine code that was directly executable on the > #underlying hardware as output. > > Lew replied: > > #You misunderstood your classes. > > You replied: > > #No, he didn't. It was that way in my classes in the 1960's and 1970's, > #also. > > Arne > And yet once again you show your ignorance and lack of understanding. But that's quite normal for you. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-10-02 22:53 -0400 |
| Message-ID | <munfug$ih2$1@speranza.aioe.org> |
| In reply to | #32725 |
On 9/27/2015 10:59 PM, Jerry Stuckle wrote: > On 9/27/2015 8:38 PM, Arne Vajhøj wrote: >> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>> On 9/24/2015 10:46 PM, Arne Vajhøj wrote: >>>> On 9/24/2015 10:34 PM, Jerry Stuckle wrote: >>>>>> Given that the naming convention is also used in C#, VB.NET, PHP, >>>>>> UCSD Pascal, then I think that it is you that are way behind >>>>>> in knowing about other programming languages. >>>>> >>>>> Wrong answer. VB.NET and PHP are interpreted languages. >>>> >>>> Wrong. >>>> >>>> VB.NET is compiled. By the VB.NET compiler - the vbc command. >>> >>> Yes, but it is not executable code. It still requires the vb runtime >>> executable (not just libraries). >> >> VB.NET compiler compiles to MSIL. >> >> There are no such thing as a VB.NET runtime executable. >> >> VB.NET only relies on .NET framework. > > Try again. VB.NET can also be compiled to an executable. There are no command line switch on the VB.NET compiler vbc to generate native code. >>>>> UCSD Pascal >>>>> (which, unlike you, I DID use) compiled to P-code. >>>> >>>> Which is byte code. >>> >>> That is true - and it required the p-code runtime exeuctable to do it. >> >> Just like Java requires the java executable. >> >> And guess what UCSD Pascal was called a compiler. > > That's right. And it output code which had to be interpreted - not > machine code. So now we agree on that a compiler does not need to generate machine code???? >>>>> And C# is it's own >>>>> thing. It compiles to an executable, >>>> >>>> Wrong. >>>> >>>> It compiles to MSIL byte code. >>>> >>> >>> C# can also be compiled to executable code. It just requires the .net >>> libraries. But it is an executable, not byte code as you claim. >> >> There are no switch to the C# compiler to generate native code. >> >> It always generate MSIL. >> >> And MSIL is byte code. > > ROFLMAO! Still arguing that lost cause? Just to prove once again you > are arguing from ignorance, see > > https://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx Maybe you should read what you link to. That link is to the NGEN utility not the C# compiler. The NGEN utility can generate native code. The C# compiler can not. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-03 10:52 -0400 |
| Message-ID | <muopvs$esf$1@dont-email.me> |
| In reply to | #32773 |
On 10/2/2015 10:53 PM, Arne Vajhøj wrote: > On 9/27/2015 10:59 PM, Jerry Stuckle wrote: >> On 9/27/2015 8:38 PM, Arne Vajhøj wrote: >>> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>>> On 9/24/2015 10:46 PM, Arne Vajhøj wrote: >>>>> On 9/24/2015 10:34 PM, Jerry Stuckle wrote: >>>>>>> Given that the naming convention is also used in C#, VB.NET, PHP, >>>>>>> UCSD Pascal, then I think that it is you that are way behind >>>>>>> in knowing about other programming languages. >>>>>> >>>>>> Wrong answer. VB.NET and PHP are interpreted languages. >>>>> >>>>> Wrong. >>>>> >>>>> VB.NET is compiled. By the VB.NET compiler - the vbc command. >>>> >>>> Yes, but it is not executable code. It still requires the vb runtime >>>> executable (not just libraries). >>> >>> VB.NET compiler compiles to MSIL. >>> >>> There are no such thing as a VB.NET runtime executable. >>> >>> VB.NET only relies on .NET framework. >> >> Try again. VB.NET can also be compiled to an executable. > > There are no command line switch on the VB.NET compiler vbc to > generate native code. > Once again you show your ignorance. But that's normal. vbc is not the only tool for VB; neither is it necessarily the last step in building native code. >>>>>> UCSD Pascal >>>>>> (which, unlike you, I DID use) compiled to P-code. >>>>> >>>>> Which is byte code. >>>> >>>> That is true - and it required the p-code runtime exeuctable to do it. >>> >>> Just like Java requires the java executable. >>> >>> And guess what UCSD Pascal was called a compiler. >> >> That's right. And it output code which had to be interpreted - not >> machine code. > > So now we agree on that a compiler does not need to generate machine > code???? > No, YOU agree on it. >>>>>> And C# is >>>>>> it's own >>>>>> thing. It compiles to an executable, >>>>> >>>>> Wrong. >>>>> >>>>> It compiles to MSIL byte code. >>>>> >>>> >>>> C# can also be compiled to executable code. It just requires the .net >>>> libraries. But it is an executable, not byte code as you claim. >>> >>> There are no switch to the C# compiler to generate native code. >>> >>> It always generate MSIL. >>> >>> And MSIL is byte code. >> >> ROFLMAO! Still arguing that lost cause? Just to prove once again you >> are arguing from ignorance, see >> >> https://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx > > Maybe you should read what you link to. > > That link is to the NGEN utility not the C# compiler. > > The NGEN utility can generate native code. > > The C# compiler can not. > > Arne > And what does NGEN run against? Maybe .net code? Yes, you should read. But I understand that anything with more than two syllables is beyond your comprehension. You only continue to make a fool of yourself by arguing with people more knowledgeable than you (and I'm not the only one). Either you are very stoopid, or you are a troll. Personally, I think you are both. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2015-10-05 21:03 -0400 |
| Message-ID | <muv6lr$8av$1@speranza.aioe.org> |
| In reply to | #32784 |
On 10/3/2015 10:52 AM, Jerry Stuckle wrote: > On 10/2/2015 10:53 PM, Arne Vajhøj wrote: >> On 9/27/2015 10:59 PM, Jerry Stuckle wrote: >>> On 9/27/2015 8:38 PM, Arne Vajhøj wrote: >>>> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>>>> On 9/24/2015 10:46 PM, Arne Vajhøj wrote: >>>>>> On 9/24/2015 10:34 PM, Jerry Stuckle wrote: >>>>>>>> Given that the naming convention is also used in C#, VB.NET, PHP, >>>>>>>> UCSD Pascal, then I think that it is you that are way behind >>>>>>>> in knowing about other programming languages. >>>>>>> >>>>>>> Wrong answer. VB.NET and PHP are interpreted languages. >>>>>> >>>>>> Wrong. >>>>>> >>>>>> VB.NET is compiled. By the VB.NET compiler - the vbc command. >>>>> >>>>> Yes, but it is not executable code. It still requires the vb runtime >>>>> executable (not just libraries). >>>> >>>> VB.NET compiler compiles to MSIL. >>>> >>>> There are no such thing as a VB.NET runtime executable. >>>> >>>> VB.NET only relies on .NET framework. >>> >>> Try again. VB.NET can also be compiled to an executable. >> >> There are no command line switch on the VB.NET compiler vbc to >> generate native code. >> > > Once again you show your ignorance. But that's normal. vbc is not the > only tool for VB; neither is it necessarily the last step in building > native code. vbc is the only compiler for VB.NET. >>>>>>> And C# is >>>>>>> it's own >>>>>>> thing. It compiles to an executable, >>>>>> >>>>>> Wrong. >>>>>> >>>>>> It compiles to MSIL byte code. >>>>>> >>>>> >>>>> C# can also be compiled to executable code. It just requires the .net >>>>> libraries. But it is an executable, not byte code as you claim. >>>> >>>> There are no switch to the C# compiler to generate native code. >>>> >>>> It always generate MSIL. >>>> >>>> And MSIL is byte code. >>> >>> ROFLMAO! Still arguing that lost cause? Just to prove once again you >>> are arguing from ignorance, see >>> >>> https://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx >> >> Maybe you should read what you link to. >> >> That link is to the NGEN utility not the C# compiler. >> >> The NGEN utility can generate native code. >> >> The C# compiler can not. > > And what does NGEN run against? Maybe .net code? Yes. It takes MSIL as input. MSIL that is output from C# compiler or .NET compiler or another .NET compiler. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2015-10-05 21:25 -0400 |
| Message-ID | <muv7pl$act$1@dont-email.me> |
| In reply to | #32805 |
On 10/5/2015 9:03 PM, Arne Vajhøj wrote: > On 10/3/2015 10:52 AM, Jerry Stuckle wrote: >> On 10/2/2015 10:53 PM, Arne Vajhøj wrote: >>> On 9/27/2015 10:59 PM, Jerry Stuckle wrote: >>>> On 9/27/2015 8:38 PM, Arne Vajhøj wrote: >>>>> On 9/25/2015 9:56 AM, Jerry Stuckle wrote: >>>>>> On 9/24/2015 10:46 PM, Arne Vajhøj wrote: >>>>>>> On 9/24/2015 10:34 PM, Jerry Stuckle wrote: >>>>>>>>> Given that the naming convention is also used in C#, VB.NET, PHP, >>>>>>>>> UCSD Pascal, then I think that it is you that are way behind >>>>>>>>> in knowing about other programming languages. >>>>>>>> >>>>>>>> Wrong answer. VB.NET and PHP are interpreted languages. >>>>>>> >>>>>>> Wrong. >>>>>>> >>>>>>> VB.NET is compiled. By the VB.NET compiler - the vbc command. >>>>>> >>>>>> Yes, but it is not executable code. It still requires the vb runtime >>>>>> executable (not just libraries). >>>>> >>>>> VB.NET compiler compiles to MSIL. >>>>> >>>>> There are no such thing as a VB.NET runtime executable. >>>>> >>>>> VB.NET only relies on .NET framework. >>>> >>>> Try again. VB.NET can also be compiled to an executable. >>> >>> There are no command line switch on the VB.NET compiler vbc to >>> generate native code. >>> >> >> Once again you show your ignorance. But that's normal. vbc is not the >> only tool for VB; neither is it necessarily the last step in building >> native code. > > vbc is the only compiler for VB.NET. > Once again you show your ignorance. I didn't say that there are other compilers for vbc. But I did say it is not necessarily the last step in building native code. But I also understand that is a more complex idea than you can handle. >>>>>>>> And C# is >>>>>>>> it's own >>>>>>>> thing. It compiles to an executable, >>>>>>> >>>>>>> Wrong. >>>>>>> >>>>>>> It compiles to MSIL byte code. >>>>>>> >>>>>> >>>>>> C# can also be compiled to executable code. It just requires the >>>>>> .net >>>>>> libraries. But it is an executable, not byte code as you claim. >>>>> >>>>> There are no switch to the C# compiler to generate native code. >>>>> >>>>> It always generate MSIL. >>>>> >>>>> And MSIL is byte code. >>>> >>>> ROFLMAO! Still arguing that lost cause? Just to prove once again you >>>> are arguing from ignorance, see >>>> >>>> https://msdn.microsoft.com/en-us/library/6t9t5wcf%28v=vs.110%29.aspx >>> >>> Maybe you should read what you link to. >>> >>> That link is to the NGEN utility not the C# compiler. >>> >>> The NGEN utility can generate native code. >>> >>> The C# compiler can not. >> >> And what does NGEN run against? Maybe .net code? > > Yes. It takes MSIL as input. > > MSIL that is output from C# compiler or .NET compiler or > another .NET compiler. > > Arne > > Gee, so you CAN generate native code from C# and other .net files then! Hallelujah! But I'm sure that disclosure has caused your brain to implode. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web