The MASM Forum

64 bit assembler => 64 bit assembler. Conceptual Issues => Topic started by: Gunther on January 08, 2018, 09:04:20 AM

Title: Some Relocations Required (not for the faint of heart)
Post by: Gunther on January 08, 2018, 09:04:20 AM
The background for this post is this old thread. (http://masm32.com/board/index.php?topic=1911.msg19863#msg19863)

The program was inspired by Dr. Paul Carter's book. It was written, assembled and linked under Ubuntu 16. I needed a framework so that students who are currently learning assembler can look at the registers in the processor and the contents of the floating point unit in their programs. So far so good.

You can of course do all the outputs through system calls. Then, however, routines must be written for output of all possible data types (strings, different integer types, different floating point numbers etc.). That works fine, but I was too lazy for that. That's why I liked Carter's idea of linking the assembly language code against libc and getting printf to do the job, for example. This works even under newer Linux distributions of Ubuntu or Debian and the application runs fine. The tricky problem is, for example, you can still assemble with Ubuntu 17 but no longer link the object modules against libc.

That has to do with position independent code and data. The precondition when writing 64-bit Linux assembly code is that the symbol must be "local" (i.e. not global), otherwise the linker will complain, a bit like this:

relocation R_X86_64_PC32 against symbol 'hello' can not be used when making a shared object; recompile with -fPIC
final link failed: Bad value

That's pretty tricky. The simple idea behind this is: It's possible to make the code section of the application truly position independent, in the sense that it can be easily mapped into different memory addresses without needing to change one bit. This is the default behavior among many 64-bit Linux distributions (Ubuntu, Debian, Gentoo, Fedora), especially since the advent of the Gold Linker. (https://en.wikipedia.org/wiki/Gold_(linker)) It was written by Lance Taylor and he is a huge fan of that described technique.

But the main reason for this is that Position Independent Executables (PIE) are an output of the hardened package build process. A PIE binary and all of its dependencies are loaded into random locations within virtual memory each time the application is executed. This makes Return Oriented Programming (ROP) attacks much more difficult to execute reliably. This is the address space layout randomization (ASLR). (https://en.wikipedia.org/wiki/Address_space_layout_randomization) I will not discuss the various attack techniques (Buffer overflow, Return into libc, Stack buffer overflow etc.) in detail here, because that's forbidden by the forum rules. I just want to mention that all the effort is being made to complicate such attacks by Script Kiddies. We have a very serious background here.

What does this mean for a programmer who wants to link his assembly language code against libc or libm? Here's what I learned about it in the last few days. I found some important pieces of the puzzle, but others are still missing. My search process is far from finished.

In a gross generalization, I think there are two basic types indirect addressing: by PC-relative offset (i.e. by an offset from the current address of the instruction pointer), or through a pointer. There are two ELF constructs which assist in locating the run time addresses of symbols (function addresses as well): the Global Offset Table (GOT) and the Procedure Linkage Table (PLT). I'm sure you've already heard of them. Every newly started process gets a GOT and a PLT in the Unix world. While almost all position-independent 32-bit code will reference to the symbol _GLOBAL_OFFSET_TABLE_  (__GLOBAL_OFFSET_TABLE_ with double underscore under BSD) at some point, 64-bit code can use their relocation types to address values in the GOT, so you typically won't see the symbol being used in assembly language code as frequently. The address of the GOT is within the read-only segment.

The operation of the PLT is one of the better-documented areas of an ELF binary. Suffice it to say that on a lazy-linked function's initial invocation, the instruction pointer jumps using an address in the PLT to the dynamic linker — which changes the contents at that PLT address to be the real address of the function — and then jumps again to that target function (all the jumping is important as the target function's eventual ret statement will still find the original return address on the stack). Subsequent invocations no longer detour via the dynamic linker but jump from the PLT directly to the target function. So the PLT is a kind of a trampoline.

All this now means the following. You can't write, for example:

mov        rax, [myVar]

That won't work no longer. Instead, the variables must be addressed via the GOT and the functions must be called via the PLT. That's the difficulty.

My first attempts were with YASM. The manual describes the WRT operator together with the PIC relocation types:

..gotpcrel, ..got, ..plt, ..sym

But it does not work. I could link the object module against libc, but there was a segmentation fault. In addition, YASM is apparently no longer maintained. The last release is from 2014. Yasm is not up to date anymore.

Next try with NASM. The manual knows a bit about GOT but nothing about ..gotpcrel Bad luck.

The last salvation was the GNU assembler (GAS). GAS is tough, relentless and forgives no mistake. But it is well maintained, up to date and does a good job in the end. Here is the result. The attached ZIP file contains the sources and 64-bit binaries of the application. There are 3 sources:
Here is the output of the program:

That's a C string (zero terminated).
32 bit unsigned integer value =  4294967295
32 bit integer value          = -2147483648
64 bit unsigned integer value =  858993459234567
64 bit integer value          = -858993459234567
REAL4 (float) value           =  1.730000
REAL8 (double) value          =  3.1415926535897931

CPU register dump:
------------------
RAX   = 1122334455667788   RBX   = 0000000000000000   RCX = 2233445566778899
RDX   = 33445566778899AA   RDI   = 00007F70DB3D2720   RSI = 0000000000000000
RBP   = 00007FFC994EB5E8   R8    = 445566778899AABB   R9  = 5566778899AABBCC
R10   = 66778899AABBCCDD   R11   = 778899AABBCCDDEE   R12 = 000055791CEFE540
R13   = 00007FFC994EB730   R14   = 0000000000000000   R15 = 8899AABBCCDDEEFF
RSP   = 00007FFC994EB5C0   Flags = 0000000000000206

However, it takes strong nerves to read the source code. You will not find any clever hll constructs there, just mnemonics. Moreover, parts of the source are written in Intel syntax, but other parts in the archaic AT&T syntax. The reason is simple. I have no idea how to write something like that:

       movq       msg1@GOTPCREL(%rip), %rsi               # get C string address
       call       print_Cstring@PLT                       # print_Cstring

in Intel syntax.

I have written to the maintainers of the binutils (GAS is a part of it), how can one write that in Intel syntax. That would be a big step forward, but so far no answer. I also wrote Frank Kotler (NASM developer) and asked for information, no answer so far. I will contact Hans Peter Anvin (chief maintainer of NASM), maybe he can help.

I hope that Branislav and johnsa know a way how to do that with UASM. The big advantage of JWASM was that it works on different operating systems (DOS, Windows, OS/2, Unix, Linux, BSD, etc.). This advantage should not be out of hand. So it should be possible to access GOT and PLT with UASM, right? For me that would be the cleanest option.

Some more comments at the end. Of course I could have done the register dump over the stack as well. But I wanted to show how to access any variables in data or bss section. The program still lacks parts: FPU dump, the dumps of the XMM, YMM and ZMM registers. But that's just a little hard work.

I hope nobody scared anyone.

Gunther
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: hutch-- on January 08, 2018, 10:48:40 AM
Could you use this instead of "mov        rax, [myVar]"

    lea rax, myVar

I don't know enough about Unix based systems for any of the higher level code but mnemonics like this should work if the random location code can still use LEA.
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: Gunther on January 08, 2018, 11:33:02 AM
Steve,

thank you for your fast reply.

Quote from: hutch-- on January 08, 2018, 10:48:40 AM
Could you use this instead of "mov        rax, [myVar]"

    lea rax, myVar

That was my first idea, but that doesn't work. Here is a short explanation from the NASM manual (http://www.nasm.us/doc/nasmdoc9.html#section-9.2). Sure, the manual is incomplete, partly unclear and only handles 32-bit code for shared libraries. But these principles have now been fully adopted for all applications in the 64-bit world. There is no other chance to access variables, this is only possible via the GOT (with several possibilities). Here is a very detailed explanation of the whole process by Ulrich Drepper (https://www.akkadia.org/drepper/dsohowto.pdf), libc maintainer. Of course, he is a complicated personality, but what he writes has hand and foot.

All things considered, the whole thing is very vexing.

Gunther
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: johnsa on January 09, 2018, 08:58:14 AM
I've been following the PIE saga for a bit now.. along with meltdown and spectre .. i'm almost of the opinion we shouldn't bother trying to code anymore..
they're complicating and slowing it down so significantly to try and secure the un-securable. No matter how many ways they come up with to make hacking more difficult, the hackers will over come and the only ones who suffer are legitimate users and developers.

The whole arrangement with GOT and PLTs is a total shambles.. I really hope the people who came up with such BS along with the people who designed ACPI and all go shoot themselves..
*rant*

The impact on performance is not negligible, let alone these people never seem to think beyond C ... they construct mechanisms which are so utterly filthy no one coming at them from an assembler point of view could stomach it. A classic point in case under Linux/Unix based systems is trying to extract a location out of libc for error messages.. which is non standard.. poor old win32 just provides something like GetLastError...
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: johnsa on January 09, 2018, 09:14:21 AM
The reason that even LEA won't work anymore is although lea rax,[var] is technically position independent, the distance between rip and var is known at compile time. With ASLR and PIE that distance is subject to change at any moment depending on the dynamic linker. So there really is no quick fix apart from using the GOT and PLT. It's filthy... horrible.. and has been hacked repeatedly already.. so their attempts at hardening and securing flaws have already failed miserably.. and we're left to suffer their incompetence.. *another rant* :)

Title: Re: Some Relocations Required (not for the faint of heart)
Post by: hutch-- on January 09, 2018, 10:33:30 AM
John,

Its good to hear some sense in this area, I have been looking around trying to find HOW it will infect any specific computer and all I hear at the moment is a mountain of waffling bullsh*t with no detail. If I start on the premise that an isolated computer can never be infected, then for it to get infected, it must be transferred to the computer by some means, either by connecting it to the internet OR something like data on a USB stick.

If this is the case and its not done by magic, then it sounds like "just another exploit" and the old rule has always been, let garbage into your computer and you can kiss your arse goodbye in terms of security. There have long been nasty and destructive exploits that will stop a computer stone dead and the only solution has always been to keep garbage out of a computer. Don't download rubbish, never ever let an email client run attachments and keep a boot disk image that can overwrite a damaged boot partition.
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: Gunther on January 09, 2018, 02:38:08 PM
John,

I can understand your anger and share it in part. The GOT and PLT for shared libraries (SO are pretty similar to the DLL) to use is one thing. But using the concept for all applications is a completely different matter. Here we agree 100%. It makes the code inefficient and increases the register pressure. But as I said, it was not our decision.

What I'm describing now is just the view of an assembler programmer. In the Windows world the MASM is unchallenged the top dog. It can only be used there, but you can use it to create all sorts of binary code (EXE, DLL, Drivers whatever you want). Behind MASM are decades of continuous development and a lot of manpower. That should be noted.

JWASM now UASM is 99% compatible with MASM. it has his own merits. It can run on different operating systems: Windows, Linux, OS/2, MacOS. Even DOS is still possible with an older version, although the DOS version is no longer maintained. These are undeniable advantages over MASM, and that makes UASM, of course, attractive. I can only hope that these benefits will continue in the future.

For now, however, you can not create a shared library with UASM, either under 32 or under 64 bit. Shared libraries are a concept in Linux, BSD or Solaris for many years if not decades. MacOS also uses this concept (https://developer.apple.com/library/content/qa/qa1118/_index.html); Mach-O shared libraries have the file type MH_DYLIB and the .dylib (dynamic library) suffix. Unfortunately that is not possible at the moment with UASM.

However, it's also about using an assembler under an operating system to create all kinds of binary code. That's the main job of an assembler. From this perspective, it does not look very good at the moment. YASM had support for GOT and PLT, but has not been maintained for 4 years. The support of NASM is rudimentary, but seems to be flawed. It seems that FASM is able to allow access to the GOT and PLT (https://board.flatassembler.net/topic.php?t=4964) so that shared objects can be created. By the way, the link from the FASM forum is from 2003. I have not yet checked how the situation is now. Besides, I have not worked with FASM yet. But maybe there will be nothing left for me in the future, who knows?

So only the gas remains. The GNU assembler is even more stubborn than MASM, but it makes the job. That was my luck. You can create any sort of binary code with it; that's proven. About this gas is present on a wide range of architectures and operating systems. I am not happy with this situation. I ask myself the following question: Will UASM continue to support various operating systems in the sense that every conceivable type of binary code can be generated? That would be very desirable. I realize that this means a lot of work. How can I help with my modest means?

Gunther
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: aw27 on January 09, 2018, 05:06:10 PM
Quote
For now, however, you can not create a shared library with UASM, either under 32 or under 64 bit. ... Unfortunately that is not possible at the moment with UASM.
Actually, it is possible and there is also a sample in there since the JWASM times.  :lol: (aproximately 10 years old)
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: hutch-- on January 09, 2018, 05:45:16 PM
Ok,

Yet another suggestion. If as I grasp, the code can be located at random addresses without build time addresses available, I wonder if you can set a reference point at the location where the code is called which is within the relocatable code that itself can be used as a reference for LEA so that you have something like virtual addresses from that reference point ?

I don't know how ELF file formats work but I know the normal executable files in Windows environment using COFF format files have a starting address which has offsets based from its location that are used and any data available to the code is located in reference to the start address. Now of course if when the code is called, an argument is passed to it that gives the actual start address of the caller and thus its details become accessible, what would stop that from working.

It would mean that while the code can be located anywhere in application accessible memory, it could still access any data and code that the main app has available.

Guess work and unverified speculation from a Unix amateur.  :P
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: Gunther on January 09, 2018, 05:54:24 PM
Quote from: aw27 on January 09, 2018, 05:06:10 PM
Actually, it is possible and there is also a sample in there since the JWASM times.  :lol: (aproximately 10 years old)

So, try to link it with a new distribution and see what happens.

Gunther
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: aw27 on January 09, 2018, 06:04:48 PM
Quote from: Gunther on January 09, 2018, 05:54:24 PM
Quote from: aw27 on January 09, 2018, 05:06:10 PM
Actually, it is possible and there is also a sample in there since the JWASM times.  :lol: (aproximately 10 years old)

So, try to link it with a new distribution and see what happens.

Gunther

All right, let's bet $100.00 on that.
I have Ubuntu 64-bit 16.04.3 LTS. I will make an equivalent sample for 64-bit (even more difficult) and will make it work. Deal?
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: johnsa on January 09, 2018, 08:12:54 PM

I'm also on 16.04 ubuntu at present, but I believe the issue has become more apparent in 17.x where PIE has been made mandatory and default.
But I think it's definitely worth us trying to create some shared objects (.so) and see where we get too between aw, myself and Gunther across the different nix versions.
I know some other distros have made PIE mandatory going back a bit further.

In terms of planning for the future and how we get over this.. as much as my inner self really just wants to say "screw" linux then if they're going to come up with such nonsense .. I guess my obligation as maintainer of UASM is to do something about it :)

So here are my initial suggestions, and I think it would be valuable if Nidud joined in this debate. Given that in this particular area asmc and uasm should still be identical it would make sense that whatever solutions we come up with can be shared between the two projects, a collaboration of sorts to get it done as there is quite a bit involved.

My thinking thus far based on what I know of ELF/PIE:

1) Exports need to be declared as to whether they are data or function. Other assemblers provide a specific syntax for this however I don't think we need to given our implementation of PROC and invoke. If we rely on that we know which items are data and which are PROC, so this can be done seamlessly behind the scenes.

2) As far as I can tell Func@PLT type notation should only be required when calling a function which is NOT in the same compilation unit/module even under the PIE 17.x model, so if that is true then in theory we should be aware of this scenario by the very existence of a PROTO which has no PROC defined for it in the current module or an EXTERN PROC. If that is true then once again in theory we could make that transparent and avoid ugly syntax with all the @PLT stuff and implement that behind the scenes and make sure we add the relevant relocation type and PLT entry in the object.

3) movq var@GOTRELPC(%rip),%rdi should translate into a single instruction as far as I am aware, and much the same as with point 2 this should only be required to access the address of a variable in another compilation unit. So once again, we would know this as it would be marked as EXTERN and should be able to convert any memory address lookup to an item marked as EXTERN into the relevant GOT form.
This may require an additional check that prevents the use of LEA reg,VAR when VAR is extern as I figure that will need a different instruction.
In addition this would also change the implementation of ADDR when used in INVOKE and OFFSET would be prohibited for any inter-module reference too.

So in summary, from what I know..
1) I believe it should be possible to make this happen without ANY syntax modifications and filthy special operators to deal with GOT, PCREL, WRT etc.
2) We would probably want a command line switch -PIE to enable all of this.
3) The next step is to test the situation as it currently stands for .SO and DYLIB on ELF64 and MACHO64 and see where we get to.
4) Following on we need to verify the assumptions I've laid out above, Gunther perhaps you could add some tests into your GAS sample that references local functions and variables inside the same module without the gotpcrel/plt to test it?
5) Then we need to spec out the changes and "just do it"(tm).


Title: Re: Some Relocations Required (not for the faint of heart)
Post by: johnsa on January 09, 2018, 08:21:42 PM
One more point is that obviously we have to make sure the changes can be applied to both ELF64 and MACHO64, which of course work slightly differently.. of course they do.. why would there be a standard...
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: aw27 on January 09, 2018, 09:53:57 PM
All shared objects (.so libraries) are compiled as PIE since long. What Japheth has done with his sample is a trick, much in the line of Hutch's thoughts. I tested it long time ago and know it works. I am pretty sure it will work too as 64-bit, so I placed a challenge for that (I know Gunther is intelligent enough to not accept it).
Of course, nothing like doing the things according to the best rules and Johnsa has all my support.
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: johnsa on January 09, 2018, 11:06:12 PM
I believe you are correct, you could implement a workaround in a similar fashion to how libraries were loaded on the  Amiga, there is a fixed call which loads the library and returns it's base-address, from there all access to the library are relative to that base something along the lines of:

jsr LoadLibrary
move.l d0,a6
jsr _LVOLibFunction(a6)

roughly..

So it would be possible to have each module provide some form of hook to establish a base, but I guess it could get quite ugly having to remember to add that base to all the relevant address calculations.
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: aw27 on January 10, 2018, 05:13:35 AM
You can have a look at the NASM source to see how to insert the .got section in the elf. Then how to access it.
Looks easy, said this way, doesn't it?  :biggrin:
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: johnsa on January 10, 2018, 08:04:00 PM
Indeed :) Honestly I don't think it would be that complex a thing to do.. I just want to make sure I understand it 100% before trying, mainly to know if we can fully automate it and avoid all those horrible operators like WRT and GOTPCREL .. that just make asm code look really ugly.
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: Gunther on January 11, 2018, 02:50:36 AM
Hi John,

please excuse the break. But at the university is exam time and I have a lot to do.

John, what I'm writing now has nothing to do with you and is definitely not against you. These are just general considerations.

There are people who can not read or read properly. It's interesting that these people also cheat on certain timings and believe that nobody notices. That only incidentally.

In my first post of this thread I have written clearly and distinctly about the different Linux versions. In Ubuntu 16, this is not a problem at all. There you can always dynamically link the assembly language code against libc or libm. The created applications run even under newer distributions. But on Ubuntu 17, for example, you can not build programs from sources anymore.

Of course, there is usually a way to somehow manage something like that. An easy example: The PowerBASIC inline assembler does not support all instructions - Hutch can confirm that. Now it is easy to write the missing instructions via DB into the source code. This is called a workaround. But the fundamental problem (missing instructions) is still far from being solved. The current situation is quite comparable. With UASM we currently have no way to cleanly access the GOT or PLT, except through a workaround. That certainly works, but does not solve the fundamental problem. That was my reasoning from the beginning, but you know that yourself.

But there are, as I said, people who do not understand or want to understand. Instead, they blow up trivialities, so they are penny wise and pound foolish. This problem is not new. St. Matthew already reports about it: "Ye blind guides, which strain at a gnat, and swallow a camel." (Matthew 23, 24) Therefore, years ago I decided to ignore such people, but ignoring is already too much. You can not choose your own family and relatives. That's where you're born. But the friends and acquaintances, with whom one has dealings, one can choose. This is a privilege that I use. That's why I've been posting for years no longer in threads of self-advocates and know-it-alls. Unfortunately I have to endure that such people post into my threads and spread their balderdash there. But sometimes I wonder if some long-standing members are not visiting the forum because of such smart alecks.

John, we both have always respected each other. This will remain so. Therefore, we should look for a way to discuss the technical aspects. Maybe over PM? This thread is inappropriate for this purpose in my opinion. I can not and do not want to discuss or even work together with certain people.

At the weekend, I'm going to install the latest BSD on a machine to see how the situation is there. I will inform you then with PM about the result. To start a new thread is not worth it in my eyes. On the one hand there is not much interest in BSD in the forum, on the other hand it would not be good to give certain smarties reasons to get started. I think you understand that.

Gunther
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: aw27 on January 11, 2018, 03:45:48 AM
To be sincere I don't give a damn to some persons, if they sound fake I simply tell it.
I know the kind that goes to online forum to make politics, show familiarity with most, treat them by the first name and pat on their shoulders.

I am not talking specifically about the person that produces graphics code for CERN, that was blindly contracted for 120,000 euro per annum to produce PowerPoint Addins, that has FIDE Masters 2300 ELO Chess rating, that tutored a major hacker mentioned on the Wikipedia, that is PHd at some Deutsch Universtat and God knows what else.

What I have seen so far is the code that such person releases, of very poor quality and usually buggy. This is not from now, I have checked also from a few years ago. If it is bad I tell it. If the person shows ignorance I tell it.






Title: Re: Some Relocations Required (not for the faint of heart)
Post by: hutch-- on January 11, 2018, 07:21:52 AM
Guys,

Can I ask this favour of all involved, we all differ here and there on code, ideas and methods but there is too much talent here to waste the effort of anyone. RE: The differences between people, I have a simple system to deal with this, if anyone disagrees with me I just feel sorry for them but if they make sense I will at least listen to them.  :P

As far as the Unix stuff that is being addressed here, I have a double bias, I will only run a web site on a Unix box (of whatever flavour) and I see the better end of Unix versions as far better web servers with the LAMP setup than either Windows or MAC network systems but I lament just how bad the documentation is, the age of some of the interfaces (privileges set in OCTAL) etc and reference material spread around the internet like a mad woman's sewerage. You can find you way around MS-DOS easier than a Unix system and you are free from that PHUKING "sudo" (pseudo).

With Windows code I can still run my 1995 32 bit software where Unix version (Linux distros) you often have to re-compile your "sauce" for each version. The problem will be that as soon as anyone settles on a mechanism to address certain types of hack attempts, someone else will break it. Making a non accessible colonel (kernel) is probably the only way to make a machine really hard to hack. Randomising the stack address is one way that helped and the ever irritating DEP in Windows made me a mountain of work to fix it. The old Microsoft "interconnectivity" was like people sleeping around and catching socially transferrable diseases and it worked to the same rule, the more you spread it around, the more you catch.

If the only way to update a machine was with a bootable CD/DVD then there would be no way to access the OS code at all.
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: Gunther on January 11, 2018, 11:58:19 AM
Steve,

you see yourself.

Envy and blind rage are always bad guides. There remains only the question: Have some people foaming at the mouth before writing or until they have written? I really can not answer that.

If, like me, you were not in the forum for a while, you realize that the whole atmosphere has changed. I've already written about longtime members that we've probably lost forever. For example, I'm thinking of Bill Cravener, Antariy or Clive. These were all good people that I miss very much. These are excellent programmers who know a lot, but have not boasted. Clive is still very active, but in the Google groups and not in our forum anymore. Antariy just had enough of the pomposity and pretension. From Bill, I know exactly what happened. That had nothing to do with you, Steve. I can gladly forward you Bill's mail.

Of course nobody will post in this forum forever and nobody should waste his precious life with endless, unfruitful debates. Dixi et salvavi animam meam (Ezekiel 3,19).

Gunther
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: jj2007 on January 11, 2018, 07:13:54 PM
Quote from: Gunther on January 11, 2018, 11:58:19 AMIf, like me, you were not in the forum for a while, you realize that the whole atmosphere has changed. I've already written about longtime members that we've probably lost forever. For example, I'm thinking of Bill Cravener, Antariy or Clive.

Right. Add MichaelW (Last Active: October 08, 2017), DednDave, rrr314159, adeyblue, ... there are 559 members right now, most are inactive.

But I don't think that the atmosphere has dramatically deteriorated. There were always moments of tension, and occasionally we kicked out somebody who indulged too much in personal insults. Compared to some other forums I know, this is a civilised place, and in general we respect each other even if we don't speak the same language. Fake Italians can communicate with Real Norwegians :t
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: aw27 on January 11, 2018, 07:33:43 PM
Looking at the contributors list for JWASM 2.11 I don't see the name of some people that are so regrettably missed or people that only come here for politics and gossip.
Incidentally, I am on the list although not a member of the forum at the time.


    8. Contributors

    These people contributed to JWasm ( additions, bugfixes, bug reports):

    agner, BlackVortex, dosfan01, drizz, Paul Edwards, filofel, Peter Flass,
    James C. Fuller, gfalen, habran, Japheth, Jimg, jj2007, John Hankinson,
    Khusraw, Alex Kozlov, Peter Kuznetsov, misca, Michal Necasek, H. Nidudsson,
    Nikitakita, Jose Pascoa, Terry Philips, qWord, RotateRight, Ito Toshimitsu,
    Vortex.

    Japheth
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: hutch-- on January 11, 2018, 10:09:32 PM
I have funded this forum since about 2003 after the script kiddies that took over the old win32asm forum tried to take over the masm32 project as well but landed flat on their arse. In part it because I still enjoy writing assembler code and interacting with many other very good assembler language programmers. I worked with some excellent programmers from 1997 up to about 2003 extending the project but as various people faded away for a variety of reasons, Iczelion got married, others left for other reasons, work, life, family etc ... I took on the workload of maintaining the project and improving it over time.

I was always happy to share the stuff I bothered to write but over time this ceased to be reciprocated and by the time I did the last update on the masm32 SDK, the workload to get that all done left me brain dead and losing interest. I got no assistance at all even in testing bits of it and after I released it I heard some whining about bits and pieces that a few did not like. I have tended to take the approach that if someone wants something, they can get off their arse and write it themselves because the world where the masm32 project was started no longer exists.

I make no apology for having worked in Microsoft software since I started back in about 1990 but I have got really tired of morons attacking me because of it. After being attacked by an army of bludgers who though they could steal copyright content and give it to the GNU organisation and when they failed they tried to attack the old 1997 licence to use a number on Microsoft binaries. My response since then is to give them nothing as the project is protected by copyright to ensure it did not end up as a pile of sh*t dumped somewhere that no-one cared about.

Then there was my foolish attempt to support Japheth with his assembler but got knifed every time I tried to support it. I had a dedicated subforum for JWASM but without notice Japheth moved to Sourceforge and abandoned it so I deleted the entire subforum. I started this forum long ago to originally support people who wanted to write Microsoft assembler and over time I have tried to support people who were developing their own. I have supported John as he is a hard worker doing good work but much of the rest contribute nothing and just suck the life out of anything they can find.

Closed source systems vying for dominance over other tools and systems has been a genuine pest and among other things it is the reason why the LAB has died some years ago. Where once you saw excellent code from various contributors, over the years all you got if you bothered to post algorithms was closed source binaries with no explanation or source code using the LAB as advertising.

Something that has really pissed me off is the amount of criticism because I choose to write 64 bit MASM code. After waiting years for Japheth to get off his arse and not seeing a 64 bit version that would be finished in my lifetime, I found Vasily's work and after rewriting some massive amount of it I have ended up with a more or less viable 64 bit system and to be blunt, I don't give a flying PHUK who does not like it. I fought the assembler wars long ago against a pile of bludgers so I am reasonably well practised at it and I will never kiss the arse of Open Sauce as I have been shit on too many times.

I do have a solution to the endless attacks, I am still more or less a human being and object to being treated like an internet object so if it pisses me off enough, its easy to pull the plug on the whole forum and spend the money on a yearly trip or a couple of new cameras or whatever else I feel like.
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: johnsa on January 11, 2018, 11:52:39 PM
Speaking of Japheth (note subtle subject change)... ;)

Does anyone know what actually happened to the guy ? He fell off the face of the earth, I can only assume something unfortunate..
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: aw27 on January 12, 2018, 02:37:25 AM
Quote from: johnsa on January 11, 2018, 11:52:39 PM
Speaking of Japheth (note subtle subject change)... ;)

Does anyone know what actually happened to the guy ? He fell off the face of the earth, I can only assume something unfortunate..
He ("My real-life name is Andreas Grech, living in the vicinity of Stuttgart, Germany") had a website, let me see if I remember... ahhh! got it: www.Japheth.de  :biggrin:
The website is still reported by whois.com but has no pages since Sept 2014 (web.archive.org).
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: johnsa on January 12, 2018, 03:16:38 AM
Very strange.. oh well.. no matter :)
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: Gunther on January 12, 2018, 03:53:11 AM
John,

Quote from: johnsa on January 12, 2018, 03:16:38 AM
Very strange.. oh well.. no matter :)

Yes, indeed. But I think it's time for a clear word now.

If someone writes and in the end assumes that only people who have participated in the development of JWASM/UASM seriously work in the forum, this only shows his great ignorance and arrogance, as well as his very limited thinking. I can name on the spot a long series of forum members who were not involved in the development of JWASM/UASM, but still made excellent contributions in other areas: Hutch with several MASM projects, Jochen with his development of MASM BASIC, Bogdan with the development of SOL ASM and SOL OS, Edgar, rsala, Vortex, Mikl__, Raistlin, FORTRANS,  Raymond and, and, and ... I could continue this list for a long time.

That should be all people who do not work seriously and only those interested in politics and gossip? Is that really true?

I'm seriously asking: How long do the many seriously working members want to let this impudence and blatancy go? Exactly that, Jochen, I meant with atmospheric change. You must have noticed that too.

Gunther
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: aw27 on January 12, 2018, 03:53:44 AM
Quote from: johnsa on January 12, 2018, 03:16:38 AM
Very strange.. oh well.. no matter :)
Yeap, he has the right to disappear without leaving any trace.  :icon_cool:
BTW, I have nothing against Germans, some of them are nice people (not all!  :badgrin: . Prost to the nice ones.  :icon14:)
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: GoneFishing on January 12, 2018, 04:08:29 AM
Very interesting  ;)
Maybe he still has H2INCX source code?
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: jj2007 on January 12, 2018, 06:15:53 AM
Quote from: johnsa on January 11, 2018, 11:52:39 PMHe fell off the face of the earth, I can only assume something unfortunate...

Maybe Andreas leads a pleasant, quiet life in Neckartailfingen taking care of his grandkids... ;)
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: felipe on January 12, 2018, 12:44:23 PM
Hutch i'm really grateful to what you have done and to others contributions too. Unfortunately i'm still an apprentice and i can't make to much work for now either. You are completely in your right to do whatever you want with the forum. I'm sure i will always remember it.
It's a little sad to me, and maybe to others too, to post code that's too simple. Sometimes i think it should go to the campus (the code i'm working with), then i think: "maybe really newbies will be confused or intimidated" (probably i'm exaggerating here). Then i think: "this is to simple crap to the people in the forum who know all this things". So, sometimes i think it's difficult to post code for those reasons (but i have never made a post, with just the .exe). As far as i know it's not an academic forum (i mean strictly speaking, like a college property or similar), it has helped a lot to beginners (at least i think that's my case). Well, in conclusion, it's not an easy task to have a forum running with an exclusive profile. Btw, i think the emerge, in the same forum, of 64 bits (a very natural thing of course) have made even more difficult to post 32 bits programs without thinking: "this is a crap that nobody will like". But assembly language it has been always like this (probably), in the end, it's a pretty lonely path. Of course you can change this with a good community. As far as the forum exists (with reasonable rules like the ones that exists now) i will be a happy member (if allowed to me) but i guess it will take time to me to produce some code than others can enjoy.  :idea:
Title: Re: Some Relocations Required (not for the faint of heart)
Post by: hutch-- on January 12, 2018, 04:16:15 PM
felipe,

The code you post is in fact useful to other people, we all had to start somewhere and progressively more complex code helps others on the same path. This type of code is not a status symbol, its just work and more work and more work but you do get faster with practice and that simplifies the process of developing more advanced code over time. It is often the case that if one of the older fellas post some very complex code, few others will understand it so it is no use to them.

You may laugh at this, I will never post the asm code for QE as it is written with all of my own bad habits and quirks and would be a genuine nightmare for anyone else to try and comprehend. Over time as you get enough practice, the best way to post complex code is to put it into a library module so that others can read it if they want to but can use it without having to digest its internals. Often the fastest code is just about unreadable to human beings.