The First Traditional "Hello world!" - Revision history

Krashan: /* "Hello World!" With the MorphOS Native API */ style

2012-10-19T06:15:01Z

‎"Hello World!" With the MorphOS Native API: style

Krashan: Crosslink to Polish translation.

2011-04-04T10:55:46Z

Crosslink to Polish translation.

AusPPC: Minor spelling and readability changes

2010-11-05T22:17:06Z

Minor spelling and readability changes

Krashan: AusPPC fixes.

2010-10-25T08:45:37Z

AusPPC fixes.

Krashan at 09:37, 24 October 2010

2010-10-24T09:37:10Z

Krashan: No fixed styles.

2010-10-24T09:36:44Z

No fixed styles.

Krashan: Internal link completed.

2010-10-23T17:41:20Z

Internal link completed.

Krashan at 14:58, 23 October 2010

2010-10-23T14:58:02Z

Krashan: /* "Hello World!" With the Standard C Library */ spacing

2010-10-23T14:57:38Z

‎"Hello World!" With the Standard C Library: spacing

Krashan: spacing

2010-10-23T14:57:08Z

spacing

@@ Line 43: / Line 43: @@
 =="Hello World!" With the MorphOS Native API==
-The MorphOS API (''Application Programmer Interface'') provides complete file and console input/output. In fact, functions in C and C++ standard libraries are, more or less, complex wrappers around MorphOS native calls. Using the native API has the following advantages:
+The MorphOS API (''Application Programmer Interface'') provides complete file and console input/output. In fact, functions in C and C++ standard libraries are, more or less complex wrappers around MorphOS native calls. Using the native API has the following advantages:
 * Programs are much shorter.

← Older revision		Revision as of 10:55, 4 April 2011
Line 1:		Line 1:
	''Grzegorz Kraszewski''		''Grzegorz Kraszewski''
		+	----
		+	<small>This page in other languages: [[Pierwsze tradycyjne "Hello world!"\|Polish]]</small>

← Older revision		Revision as of 22:17, 5 November 2010
Line 66:		Line 66:


−	The included header includes all things needed to use the ''dos.library'', where the ''Printf()'' function is located. The function itself works the same as the standard library ''printf()'', with some minor ~~differencies~~. The code is ~~being~~ compiled with this command:	+	The included header includes all things needed to use the ''dos.library'', where the ''Printf()'' function is located. The function itself works the same as the standard library ''printf()'', with some minor differences. The code is compiled with this command:


Line 72:		Line 72:


−	The command is the same as ~~thah~~ used for the program using ''libnix'' and the standard library ''printf()'', however, the standard C function is not used, so it is not linked. Now the executable size reduces to 13 500 bytes.	+	The command is the same as that used for the program using ''libnix'' and the standard library ''printf()'', however, the standard C function is not used, so it is not linked. Now the executable size reduces to 13 500 bytes.

@@ Line 4: / Line 4: @@
 =="Hello World!" With the Standard C Library==
-With the standard C library, one can use the "Hello World!" example exactly as found in a C handbook. It is given below, just for completness:
+With the standard C library, one can use the "Hello World!" example exactly as found in a C handbook. It is given below, just for completeness:
@@ Line 15: / Line 15: @@
-This source may be copied to a text editor and saved as ''helloworld.c''. To compile it, one opens a shell window (from Ambient menu, or using ''rcommand + n'' key combo) and changes current directory to the one, where C source is located. The compiler is ran as follows:
+This source may be copied to a text editor and saved as ''helloworld.c''. To compile it, one opens a shell window (from the Ambient menu, or using the ''rcommand + n'' key combo) and changes current directory to the one, where the C source is located. The compiler is run as follows:
@@ Line 21: / Line 21: @@
-The compiler produces ''helloworld'' executable, which has 10 340 bytes on my system. Note that MorphOS pays little attention to filename extensions, so ending the executable name with ''.exe'' is not needed, however possible. Traditionally MorphOS executables are named without any extensions. The '''&minus;o''' compiler option specifies desired executable name. If this option is not given, the executable will be named ''a.out'' (for some historical reasons).
+The compiler produces a ''helloworld'' executable, which is 10 340 bytes on my system. Note that MorphOS pays little attention to filename extensions, so ending the executable name with ''.exe'' is not needed, however, it can be done. Traditionally MorphOS executables are named without any extensions. The '''&minus;o''' compiler option specifies a desired executable name. If this option is not given, the executable will be named ''a.out'' (for some historical reasons).
-As stated in the [[Installation_of_Software_Development_Kit_and_its_basic_usage#Standard_C_and_C++_Libraries|SDK section]], the standard C library will be delivered by ''ixemul.library''. It can be easily confirmed by tracing disk activity of ''helloworld'' using ''Snoopium'' tool.
+As stated in the [[Installation_of_Software_Development_Kit_and_its_basic_usage#Standard_C_and_C++_Libraries|SDK section]], the standard C library will be provided by ''ixemul.library''. It can be easily confirmed by tracing the disk activity of ''helloworld'' using the ''Snoopium'' tool.
@@ Line 30: / Line 30: @@
-It can be also seen that many other libraries are also opened including ones related to TCP/IP networking. It looks like overkill for such a small program. This happens, because ''ixemul.library'' creates a complete unixlike environment for the application, which is not needed in this simple case. That is why ''libnix'' alternative is recommended for the standard library. To use it, a '''&minus;noixemul''' option has to be added, so the compiler is called as follows:
+It can also be seen that many other libraries are also opened including ones related to TCP/IP networking. It looks like overkill for such a small program. This happens, because ''ixemul.library'' creates a complete unixlike environment for the application, which is not needed in this simple case. That is why the ''libnix'' alternative is recommended for use of the standard library. To use it, a '''&minus;noixemul''' option has to be added, so the compiler is called as follows:
@@ Line 36: / Line 36: @@
-The generated executable is much larger (30 964 bytes here), which just confirms the fact, that ''libnix'', which is now in use, is a statically linked library. Size of functions used adds to the size of executable. Every C handbook states, that ''printf()'' is the most expensive function of standard I/O, which has been just proven experimentally... On the other hand program activity, as traced with ''Snoopium'', reduces to three entries. No external resources are opened.
+The generated executable is much larger (30 964 bytes here), which just confirms the fact, that ''libnix'', which is now in use, is a statically linked library. Size of functions used adds to the size of the executable. Every C handbook states, that ''printf()'' is the most expensive function of standard I/O, which has just been proven experimentally... On the other hand program activity, as traced with ''Snoopium'', is reduced to three entries. No external resources are opened.
-=="Hello World!" With MorphOS Native API==
+=="Hello World!" With the MorphOS Native API==
-MorphOS API (''Application Programmer Interface'') provides complete file and console input/output. In fact, functions in C and C++ standard libraries are more or less complex wrappers around MorphOS native calls. Using the native API has following advantages:
+The MorphOS API (''Application Programmer Interface'') provides complete file and console input/output. In fact, functions in C and C++ standard libraries are, more or less, complex wrappers around MorphOS native calls. Using the native API has the following advantages:
 * Programs are much shorter.
@@ Line 51: / Line 51: @@
 These advantages come at a price:
-* Programs using native API are not portable (except of porting to AmigaOS and AROS to some degree).
+* Programs using the native API are not portable (except for porting to AmigaOS and AROS to some degree).
 * Native ''printf()''-like functions do not support floating point numbers.
-The "Hello World!" example using native API looks as follows:
+The "Hello World!" example using the native API is as follows:
@@ Line 66: / Line 66: @@
-The included header includes all things needed to use the ''dos.library'', where ''Printf()'' function is located. The function itself works the same as standard ''printf()'', with some minor differencies. The code is being compiled with command:
+The included header includes all things needed to use the ''dos.library'', where the ''Printf()'' function is located. The function itself works the same as the standard library ''printf()'', with some minor differencies. The code is being compiled with this command:
@@ Line 72: / Line 72: @@
-The command is the same as for program using ''libnix'' and ''printf()'', just standard C function is not used, so it is not linked. Then, the executable size reduces to 13 500 bytes.
+The command is the same as thah used for the program using ''libnix'' and the standard library ''printf()'', however, the standard C function is not used, so it is not linked. Now the executable size reduces to 13 500 bytes.
-Why ''libnix'' is still needed in spite of standard library calls are not used? Can't one just compile with '''&minus;nostdlib'''? Except of C library, ''libnix'' provides application startup code. A program without the startup code can work launched from shell, but will crash when started from Ambient. The startup code has also automatic MorphOS libraries opening and closing feature. Then rejecting ''libnix'' completely is possible, but requires [[writing a custom startup code]] and [[MorphOS_API_and_Its_Organization#Manual_Library_Opening_and_Closing|handling libraries opening and closing manually]].
+Why is ''libnix'' still needed in spite of the standard library calls not being used? Can't one just compile with '''&minus;nostdlib'''? Other than the standard C library, ''libnix'' also provides application startup code. A program without this startup code can still work when launched from the shell, but will crash when started from Ambient. The startup code also provides an automatic MorphOS library opening and closing feature. So, excluding ''libnix'' completely is possible, but requires [[writing your own startup code]] and [[MorphOS_API_and_Its_Organization#Manual_Library_Opening_and_Closing|handling library opening and closing manually]].
-<small>Note: rejecting ''libnix'' is usually done for MorphOS components not being applications, like shared libraries or Reggae and MUI public classes. It can be also done for ordinary programs just to make them shorter, especially if a program is small. For bigger projects bytes gained by writing custom startup are not worth the effort usually.</small>
+<small>Note: excluding ''libnix'' is usually done for MorphOS components other than applications, like shared libraries or Reggae and MUI public classes. It can also be done for ordinary programs just to make them shorter, especially if a program is small. For bigger projects bytes saved by writing custom startup code are not usually worth the effort.</small>

@@ Line 25: / Line 25: @@
 As stated in the [[Installation_of_Software_Development_Kit_and_its_basic_usage#Standard_C_and_C++_Libraries|SDK section]], the standard C library will be delivered by ''ixemul.library''. It can be easily confirmed by tracing disk activity of ''helloworld'' using ''Snoopium'' tool.
 [[File:snoopium_ixemul.png]]
 It can be also seen that many other libraries are also opened including ones related to TCP/IP networking. It looks like overkill for such a small program. This happens, because ''ixemul.library'' creates a complete unixlike environment for the application, which is not needed in this simple case. That is why ''libnix'' alternative is recommended for the standard library. To use it, a '''&minus;noixemul''' option has to be added, so the compiler is called as follows:

← Older revision		Revision as of 09:36, 24 October 2010
Line 76:		Line 76:


−	<~~p style="font-size: 11px;"~~>Note: rejecting ''libnix'' is usually done for MorphOS components not being applications, like shared libraries or Reggae and MUI public classes. It can be also done for ordinary programs just to make them shorter, especially if a program is small. For bigger projects bytes gained by writing custom startup are not worth the effort usually.</p>	+	<small>Note: rejecting ''libnix'' is usually done for MorphOS components not being applications, like shared libraries or Reggae and MUI public classes. It can be also done for ordinary programs just to make them shorter, especially if a program is small. For bigger projects bytes gained by writing custom startup are not worth the effort usually.</small>

← Older revision		Revision as of 17:41, 23 October 2010
Line 73:		Line 73:


−	Why ''libnix'' is still needed in spite of standard library calls are not used? Can't one just compile with '''−nostdlib'''? Except of C library, ''libnix'' provides application startup code. A program without the startup code can work launched from shell, but will crash when started from Ambient. The startup code has also automatic MorphOS libraries opening and closing feature. Then rejecting ''libnix'' completely is possible, but requires [[writing a custom startup code]] and [[handling libraries opening and closing manually]].	+	Why ''libnix'' is still needed in spite of standard library calls are not used? Can't one just compile with '''−nostdlib'''? Except of C library, ''libnix'' provides application startup code. A program without the startup code can work launched from shell, but will crash when started from Ambient. The startup code has also automatic MorphOS libraries opening and closing feature. Then rejecting ''libnix'' completely is possible, but requires [[writing a custom startup code]] and [[MorphOS_API_and_Its_Organization#Manual_Library_Opening_and_Closing\|handling libraries opening and closing manually]].


	<p style="font-size: 11px;">Note: rejecting ''libnix'' is usually done for MorphOS components not being applications, like shared libraries or Reggae and MUI public classes. It can be also done for ordinary programs just to make them shorter, especially if a program is small. For bigger projects bytes gained by writing custom startup are not worth the effort usually.</p>		<p style="font-size: 11px;">Note: rejecting ''libnix'' is usually done for MorphOS components not being applications, like shared libraries or Reggae and MUI public classes. It can be also done for ordinary programs just to make them shorter, especially if a program is small. For bigger projects bytes gained by writing custom startup are not worth the effort usually.</p>

← Older revision		Revision as of 14:58, 23 October 2010
Line 35:		Line 35:

	The generated executable is much larger (30 964 bytes here), which just confirms the fact, that ''libnix'', which is now in use, is a statically linked library. Size of functions used adds to the size of executable. Every C handbook states, that ''printf()'' is the most expensive function of standard I/O, which has been just proven experimentally... On the other hand program activity, as traced with ''Snoopium'', reduces to three entries. No external resources are opened.		The generated executable is much larger (30 964 bytes here), which just confirms the fact, that ''libnix'', which is now in use, is a statically linked library. Size of functions used adds to the size of executable. Every C handbook states, that ''printf()'' is the most expensive function of standard I/O, which has been just proven experimentally... On the other hand program activity, as traced with ''Snoopium'', reduces to three entries. No external resources are opened.
		+

	=="Hello World!" With MorphOS Native API==		=="Hello World!" With MorphOS Native API==