<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>
	Comments on: Wlink-ing for fun &#038; &#8230; profit?	</title>
	<atom:link href="https://virtuallyfun.com/2021/05/12/wlink-ing-for-fun-profit/feed/" rel="self" type="application/rss+xml" />
	<link>https://virtuallyfun.com/2021/05/12/wlink-ing-for-fun-profit/</link>
	<description>Fun with Virtualization</description>
	<lastBuildDate>Sat, 15 May 2021 03:33:00 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.0.1</generator>
	<item>
		<title>
		By: neozeed		</title>
		<link>https://virtuallyfun.com/2021/05/12/wlink-ing-for-fun-profit/comment-page-1/#comment-271948</link>

		<dc:creator><![CDATA[neozeed]]></dc:creator>
		<pubDate>Sat, 15 May 2021 03:33:00 +0000</pubDate>
		<guid isPermaLink="false">https://virtuallyfun.com/wordpress/?p=11004#comment-271948</guid>

					<description><![CDATA[In reply to &lt;a href=&quot;https://virtuallyfun.com/2021/05/12/wlink-ing-for-fun-profit/comment-page-1/#comment-271947&quot;&gt;Fernando&lt;/a&gt;.

it does it&#039;s own magic, but yeah there is the old binutils based one.  I managed to get it running under 32bit Linux. I need to finish porting the a.out to OMF converter, so then GCC can use WLINK.  I&#039;m like half way there before trying to test, but it&#039;s been interesting to go through all the LINK386 variations and see what works with what.]]></description>
			<content:encoded><![CDATA[<p>In reply to <a href="https://virtuallyfun.com/2021/05/12/wlink-ing-for-fun-profit/comment-page-1/#comment-271947">Fernando</a>.</p>
<p>it does it&#8217;s own magic, but yeah there is the old binutils based one.  I managed to get it running under 32bit Linux. I need to finish porting the a.out to OMF converter, so then GCC can use WLINK.  I&#8217;m like half way there before trying to test, but it&#8217;s been interesting to go through all the LINK386 variations and see what works with what.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Fernando		</title>
		<link>https://virtuallyfun.com/2021/05/12/wlink-ing-for-fun-profit/comment-page-1/#comment-271947</link>

		<dc:creator><![CDATA[Fernando]]></dc:creator>
		<pubDate>Sat, 15 May 2021 03:17:30 +0000</pubDate>
		<guid isPermaLink="false">https://virtuallyfun.com/wordpress/?p=11004#comment-271947</guid>

					<description><![CDATA[Probably you could add the linker from EMX to that list. I not sure that will work but probably worth trying.]]></description>
			<content:encoded><![CDATA[<p>Probably you could add the linker from EMX to that list. I not sure that will work but probably worth trying.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: neozeed		</title>
		<link>https://virtuallyfun.com/2021/05/12/wlink-ing-for-fun-profit/comment-page-1/#comment-271941</link>

		<dc:creator><![CDATA[neozeed]]></dc:creator>
		<pubDate>Sat, 15 May 2021 02:43:00 +0000</pubDate>
		<guid isPermaLink="false">https://virtuallyfun.com/wordpress/?p=11004#comment-271941</guid>

					<description><![CDATA[yeah it gets a bit confusing.. hence the &#039;wasteland&#039;  more so of my attempt to find and categorize tools

&lt;code&gt;
c050fa0c465988f34093e58713d0c2d4 Citrix_Multiuser_2\LINK386.EXE
22/03/1992  01:34 pm           144,113 LINK386.EXE
b67808642825b657494d0298376e7408 MSOS2.20\OLD-LINK\LINK386.EXE
08/05/2021  09:58 am           123,008 LINK386.EXE
2e3275c0079f8c86152743cfaee75685 MSOS2.20\SDK20\TOOLKT20\OS2BIN\LINK386.EXE
30/05/1990  11:32 am           133,102 LINK386.EXE
b67808642825b657494d0298376e7408 nt35-bh\LINK386.EXE
02/03/1994  04:37 pm           123,008 LINK386.EXE
be0188e56b0e243c7d6ca158558dd157 os2_2.00_v123\LINK386.EXE
28/11/1990  09:23 pm           138,829 LINK386.EXE
bd266c8b27e8cfe0e2b0d4956bc939cb OS2_DDK_1.2\LINK386.EXE
21/02/1994  12:19 pm           151,395 LINK386.EXE
3c7f7227c47e185c60a4df34a6b2213d OS2_DDK_2.0\LINK386.EXE
10/04/1995  07:43 pm           154,052 LINK386.EXE
b67808642825b657494d0298376e7408 Windows3.1DDK\link386.exe
04/01/1992  02:52 pm           123,008 link386.exe
&lt;/code&gt;

I&#039;m still looking for stuff, but it&#039;s by no mean an exhaustive collection of linkers.]]></description>
			<content:encoded><![CDATA[<p>yeah it gets a bit confusing.. hence the &#8216;wasteland&#8217;  more so of my attempt to find and categorize tools</p>
<p><code><br />
c050fa0c465988f34093e58713d0c2d4 Citrix_Multiuser_2\LINK386.EXE<br />
22/03/1992  01:34 pm           144,113 LINK386.EXE<br />
b67808642825b657494d0298376e7408 MSOS2.20\OLD-LINK\LINK386.EXE<br />
08/05/2021  09:58 am           123,008 LINK386.EXE<br />
2e3275c0079f8c86152743cfaee75685 MSOS2.20\SDK20\TOOLKT20\OS2BIN\LINK386.EXE<br />
30/05/1990  11:32 am           133,102 LINK386.EXE<br />
b67808642825b657494d0298376e7408 nt35-bh\LINK386.EXE<br />
02/03/1994  04:37 pm           123,008 LINK386.EXE<br />
be0188e56b0e243c7d6ca158558dd157 os2_2.00_v123\LINK386.EXE<br />
28/11/1990  09:23 pm           138,829 LINK386.EXE<br />
bd266c8b27e8cfe0e2b0d4956bc939cb OS2_DDK_1.2\LINK386.EXE<br />
21/02/1994  12:19 pm           151,395 LINK386.EXE<br />
3c7f7227c47e185c60a4df34a6b2213d OS2_DDK_2.0\LINK386.EXE<br />
10/04/1995  07:43 pm           154,052 LINK386.EXE<br />
b67808642825b657494d0298376e7408 Windows3.1DDK\link386.exe<br />
04/01/1992  02:52 pm           123,008 link386.exe<br />
</code></p>
<p>I&#8217;m still looking for stuff, but it&#8217;s by no mean an exhaustive collection of linkers.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		By: Nathan Anderson		</title>
		<link>https://virtuallyfun.com/2021/05/12/wlink-ing-for-fun-profit/comment-page-1/#comment-271938</link>

		<dc:creator><![CDATA[Nathan Anderson]]></dc:creator>
		<pubDate>Sat, 15 May 2021 01:58:13 +0000</pubDate>
		<guid isPermaLink="false">https://virtuallyfun.com/wordpress/?p=11004#comment-271938</guid>

					<description><![CDATA[I downloaded and built 2ine, and tested the various EXEs I linked with the various linker versions under the various OS/2 builds.

I had no problems running the EXE generated by link386 2.01.005 from OS/2 2.0 FixPak 2, so I don&#039;t know why you did.  The error you got, though -- &quot;not an OS/2 module&quot; -- is what 2ine shows if you try to run an LE binary (or any other format it wouldn&#039;t understand).  Are you 100% positive you didn&#039;t accidentally try to run the EXE you linked with 6.123?

All of the other LX binaries from all of the other OS/2 versions also ran fine for me under 2ine, *except* for the one from Citrix / 6.177.  It bombs out with the same mmap error yours did.

If I use lx_dump to get details about each executable and then compare them, the only difference I see between the Citrix-generated one and the others is this (one generated by 2.0 GA is -, and one generated by Citrix is +):

@@ -44,7 +44,7 @@
 Object table (2 entries):
 Object #1:
 Virtual size: 4106
-Relocation base address: 0x10000
+Relocation base address: 0x0
 Object flags: READ EXEC BIG
 Page table index: 1
 Number of page table entries: 2
@@ -516,7 +516,7 @@

 Object #2:
 Virtual size: 8944
-Relocation base address: 0x20000
+Relocation base address: 0x10000
 Object flags: READ WRITE BIG
 Page table index: 3
 Number of page table entries: 1

So reloc base address of the executable object code is 0 on the Citrix one.

I did find these notes within the 2ine CMake file:

# Note that this project doesn&#039;t work on Mac OS X because I can&#039;t mmap()
#  address 0x10000, which is the usual base address for OS/2 binaries.
# It appears the address is already accessible when main() begins, but no
#  objects seem to be loaded there. I don&#039;t know what it is...maybe some
#  thing allocated by the C runtime at startup? Have to solve that somehow or
#  give up on Mac support.

So 0x10000 is the &quot;usual&quot; base address; hmm.  I wonder if 2ine is making some assumptions that don&#039;t always hold true.

Now, it&#039;s possible that this is a bug in Citrix&#039;s linker, but the resulting binary runs fine on genuine OS/2 for me.  It&#039;s just 2ine that can&#039;t handle it.  So OS/2 seems capable of fixing that entry point up.  Even more interesting is that the linker from 6.167 (October 1991 pre-release, first with LX and WPS, preceding 2.0 LA / 6.177 by 3 months) used base offset 0x10000 too, just like all the other linkers.

So either it changed from 64k to 0 between 6.167 and 6.177, and then *back* to 64k after 6.177, *or* maybe for some reason Citrix specifically wanted their linker to behave differently in this regard.  Probably worth installing genuine OS/2 2.0 LA instead of Citrix and seeing if its link386 behaves the same way!  (I&#039;m going to guess not, because Citrix linker is dated March 1992, which is even later than the linker that shipped with 2.0 GA.  So Citrix 2.0 runs an older kernel than OS/2 2.0 GA, but not everything in Citrix 2.0 was taken from the older OS/2 2.0 LA.)

It might also be interesting to look at any 32-bit executables that shipped with Citrix.]]></description>
			<content:encoded><![CDATA[<p>I downloaded and built 2ine, and tested the various EXEs I linked with the various linker versions under the various OS/2 builds.</p>
<p>I had no problems running the EXE generated by link386 2.01.005 from OS/2 2.0 FixPak 2, so I don&#8217;t know why you did.  The error you got, though &#8212; &#8220;not an OS/2 module&#8221; &#8212; is what 2ine shows if you try to run an LE binary (or any other format it wouldn&#8217;t understand).  Are you 100% positive you didn&#8217;t accidentally try to run the EXE you linked with 6.123?</p>
<p>All of the other LX binaries from all of the other OS/2 versions also ran fine for me under 2ine, *except* for the one from Citrix / 6.177.  It bombs out with the same mmap error yours did.</p>
<p>If I use lx_dump to get details about each executable and then compare them, the only difference I see between the Citrix-generated one and the others is this (one generated by 2.0 GA is -, and one generated by Citrix is +):</p>
<p>@@ -44,7 +44,7 @@<br />
 Object table (2 entries):<br />
 Object #1:<br />
 Virtual size: 4106<br />
-Relocation base address: 0x10000<br />
+Relocation base address: 0x0<br />
 Object flags: READ EXEC BIG<br />
 Page table index: 1<br />
 Number of page table entries: 2<br />
@@ -516,7 +516,7 @@</p>
<p> Object #2:<br />
 Virtual size: 8944<br />
-Relocation base address: 0x20000<br />
+Relocation base address: 0x10000<br />
 Object flags: READ WRITE BIG<br />
 Page table index: 3<br />
 Number of page table entries: 1</p>
<p>So reloc base address of the executable object code is 0 on the Citrix one.</p>
<p>I did find these notes within the 2ine CMake file:</p>
<p># Note that this project doesn&#8217;t work on Mac OS X because I can&#8217;t mmap()<br />
#  address 0x10000, which is the usual base address for OS/2 binaries.<br />
# It appears the address is already accessible when main() begins, but no<br />
#  objects seem to be loaded there. I don&#8217;t know what it is&#8230;maybe some<br />
#  thing allocated by the C runtime at startup? Have to solve that somehow or<br />
#  give up on Mac support.</p>
<p>So 0x10000 is the &#8220;usual&#8221; base address; hmm.  I wonder if 2ine is making some assumptions that don&#8217;t always hold true.</p>
<p>Now, it&#8217;s possible that this is a bug in Citrix&#8217;s linker, but the resulting binary runs fine on genuine OS/2 for me.  It&#8217;s just 2ine that can&#8217;t handle it.  So OS/2 seems capable of fixing that entry point up.  Even more interesting is that the linker from 6.167 (October 1991 pre-release, first with LX and WPS, preceding 2.0 LA / 6.177 by 3 months) used base offset 0x10000 too, just like all the other linkers.</p>
<p>So either it changed from 64k to 0 between 6.167 and 6.177, and then *back* to 64k after 6.177, *or* maybe for some reason Citrix specifically wanted their linker to behave differently in this regard.  Probably worth installing genuine OS/2 2.0 LA instead of Citrix and seeing if its link386 behaves the same way!  (I&#8217;m going to guess not, because Citrix linker is dated March 1992, which is even later than the linker that shipped with 2.0 GA.  So Citrix 2.0 runs an older kernel than OS/2 2.0 GA, but not everything in Citrix 2.0 was taken from the older OS/2 2.0 LA.)</p>
<p>It might also be interesting to look at any 32-bit executables that shipped with Citrix.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
