For various reasons I'm planning to implement a TCP server application in either FPC, COBOL or (F)ASM (one of which being me trying to learn as many programming languages as possible and I still don't have enough experiences with either of them). While (F)ASM seems to be the most sophisticated (i.e. most interesting) and performance-winning of my three choices, I wonder if it wouldn't be incredibly stupid to use it, given that server applications should be portable (there are too many platforms and too many operating systems around).

While using TCP shouldn't differ much, I'd still need file/directory listing capabilities. Using SysCalls would probably tie my application to a very limited selection of operating systems. Is this one of the "better don't use ASM" situations or am I missing something relevant?

There are two types of portability.
1) portable across OSes
2) portable across CPUs

Assembly can give you 1) in just the same way that HLL can give you 1) i.e. it requires a lot of work and patience.

Assembly won't give you 2), you will need to rewrite for each new CPU architecture.

1) But, while HLLs provide some levels of abstraction over filesystem (and similar) APIs, ASM doesn't (AFAICS), hence my question. For some of the most interesting things I can't really find a way to circumvent OS differences. Could be just me and my limited experience...?

2) I can perfectly live with being "amd64-only", as this is probably the architecture that is most relevant on the hardware I'm targeting.

jazz wrote:

1) But, while HLLs provide some levels of abstraction over filesystem (and similar) APIs, ASM doesn't (AFAICS), hence my question. For some of the most interesting things I can't really find a way to circumvent OS differences. Could be just me and my limited experience...?

In assembly you can also use MSVCRT if you desire. Perhaps that is "cheating" though, I don't know. But if you want to avoid MSVCRT then you can write the OS interface code manually, it is actually a not-too-onerous task.

Is there a way to write an OS-independent file listing function with "if this is a Linux, do the following, if it's Windows, do this, ..." in FASM?

jazz wrote:

Is there a way to write an OS-independent file listing function with "if this is a Linux, do the following, if it's Windows, do this, ..." in FASM?

Yes, of course. It is assembly, we can do whatever we want.

Code:

ShowMeTheGoddamnedFiles: if LINUX   ;...   int 0x80 else if WINDOWS   ;...   invoke SomeThing,... end if   ret

That's neat. FASM is still in the game then.

Thank you a lot!

jazz wrote:

Is there a way to write an OS-independent file listing function with "if this is a Linux, do the following, if it's Windows, do this, ..." in FASM?

Also, you can check FreshLib - it is part of the project Fresh IDE and is created as portable library for OS independent development. Recently all my FASM software is created using FreshLib and is portable across at least Windows and Linux.

The GUI part of the library is still not finished and not suitable for production, but non-gui part is pretty stable and mature.

FreshLib for this very moment supports Linux, Windows and partially KolibriOS.

The only problem can be the relatively bad documentation, but there are some examples and I can provide some help.

The source code is in the fossil repository: here

I'd love to (and Fresh IDE is my IDE of choice), but "Linux and Windows" is not good enough. I own Unix servers.

jazz wrote:

I'd love to (and Fresh IDE is my IDE of choice), but "Linux and Windows" is not good enough. I own Unix servers.

The OS dependent layer of FreshLib is very thin and can be easily ported to Unix (BSD?) using the Linux code as a template. This way, FreshLib will have one more OS supported and you will have your portable code. Win - win.

That's inviting. Now I'm somewhat curious. I'm just afraid that I won't come really far. Porting Freshlib with my current experience in ASM (exactly 0 written "real world" LoC) sounds rather sophisticated.

Damn.

FAsm.o for UNIX will compile most easily with CLang and inline assembler is easy as pie in FPC. Have used FAsm to develop assembler code and only had to copy and past into an FPC ASM block. Just use standard Asm and all is good, but you will undoubtedly already know this. I use Lazarus IDE to wrap a GUI around my code and FPC supports direct memory access for data members from assembler blocks so it rocks.

I use FPC and Lazarus IDE for HLL and FAsm for LLL and everything works well at the x86 level. x86_64 FPC has RIP issues currently so I have regressed to x86 with FPC until such time as FPC goes native 64bit.

As you probably already know Jazz, FreeBSD has gone full support for x86_64, so 32 bit systems in a 64 bit environment is totally possible now.

FAsm and FPC are a match made in heaven as far as UNIX systems are concerned --I could not be more pleased with the pairing.

Lazarus is nice. When I was young, I was a Pascal programmer, but I can't imagine why I would prefer it to C/C++ these days. Except for GUI applications where it really shines.

Yes, I somewhat follow the FreeBSD development. Not too bad.

jazz wrote:

Lazarus is nice. When I was young, I was a Pascal programmer, but I can't imagine why I would prefer it to C/C++ these days.

Although I'm far from expert ....

Choosing FPC over C is a very obvious choice given many advantages. However, of course C++ overcomplicates everything. A quick check shows that C++17 still doesn't have proper modules. Not to mention smartlinking (which admittedly is already somewhat supported in GCC with ELF targets), which is always nice.

Granted, if you're already heavily invested in C++, already work on big projects, have no major complaints, lack time (or interest) to waste to learn "yet another" way to do the same ol' boring stuff, it's probably less important.

Is FPC "better" than C? Almost definitely. (Yes, I know everybody says stupid things like that. C isn't bad by any stretch, but ....)

Is FPC "better" than ultra-modern C++? Probably not, but I presume it's at least (roughly) equal.

I would definitely recommend giving it a look, if curious.