I don't understand how can a program be developed for multiple platforms.
For instance, if my program contains calls to Win32 functions, those functions will be not available for, let's say, Linux.
use an equate to define the OS
it can be set in the file or on the assembler command line
use if/then structures, based on the condition of that equate, to call the appropriate functions
Quote from: dedndave on February 26, 2010, 03:17:20 PMuse if/then structures, based on the condition of that equate, to call the appropriate functions
Am I to understand that all the (main) Win32 API functions have an equivalent in other operating systems?
Quote from: Sergiu Funieru on February 26, 2010, 03:21:39 PM
Am I to understand that all the (main) Win32 API functions have an equivalent in other operating systems?
Yes different operating systems have their own API. This is why the C run time library for routines like fopen, fread, fwrite, fseek, ftell & fclose has code to implement the functionality using Win32 API functions like CreateFile, ReadData, WriteData, SetFilePointer, GetFilePointer, GetFileSize & CloseHandle. If you want portability you need to abstract some of the functionality in this manner.
A bigger problem is getting the compiled/assembled objects into the right format. Linux uses ELF, it is possible to build code on a Windows box and convert it to the appropriate format. WLink can generate ELF objects, back when I did this in the 90's however a post link stage was required to clean the ELF objects into a form that could be used by Linux and the LD linker.
-Clive
If you want to develop for other platforms (ie CPU architectures), then assembly is not your game. x86 code obviosuly needs an x86 CPU, and there's no way around it. If you want to develop for other another O/S on an x86 chip (ie Linux), then like was said, you need to use the specific API they provide. As you are probably aware, this can't (legally) be done with MASM.
The 'regular' linux API is based on C; as such, if you use the MSVC routines instead of the Win32 ones, it will make life easier later on. GUI stuff is not inherent to linux like it is Windows, so there's no portable way to do it cross platform (or even intra-platform; Gnome and KDE must be dealt with different). The best way is to create your own custom routines to do it, and use conditional assembly to generate the right one. E.G., your function My_Open_File() is just a wrapper that either calls CreateFile() if you assemble for Windows, or open() if you assemble for linux. That keeps your main code portable, if somewhat bloated and slower.
-r
Quote from: redskull on February 26, 2010, 04:01:56 PMIf you want to develop for other platforms (ie CPU architectures), then assembly is not your game. x86 code obviosuly needs an x86 CPU, and there's no way around it. If you want to develop for other another O/S on an x86 chip (ie Linux), then like was said, you need to use the specific API they provide. As you are probably aware, this can't (legally) be done with MASM.
For the foreseeable future, I plan to develop applications for Windows, compiling with JWasm. I know that JWasm can also create code for other platforms and I was wondering if I should do something from the very beginning to make my code portable, if needed in the future.
From what I read so far, it seems to me that developing the same code for multiple platforms, using that conditional compiling/linking is not the most efficient way to do it. So, I'll stick to Windows for now, and, if at one point in time I'll need to develop for other platform, I'll rewrite the code to work best on that platform.
If I need to program cross platform I just use compiler packages which have full featured widget systems and specifically designed for such task like http://www.lazarus.freepascal.org/.
You can write a blown out GUI application in minutes would take weeks in assembler. :bg
Quote from: Sergiu Funieru on February 26, 2010, 04:13:08 PM
Quote from: redskull on February 26, 2010, 04:01:56 PMIf you want to develop for other platforms (ie CPU architectures), then assembly is not your game. x86 code obviosuly needs an x86 CPU, and there's no way around it. If you want to develop for other another O/S on an x86 chip (ie Linux), then like was said, you need to use the specific API they provide. As you are probably aware, this can't (legally) be done with MASM.
For the foreseeable future, I plan to develop applications for Windows, compiling with JWasm. I know that JWasm can also create code for other platforms and I was wondering if I should do something from the very beginning to make my code portable, if needed in the future.
From what I read so far, it seems to me that developing the same code for multiple platforms, using that conditional compiling/linking is not the most efficient way to do it. So, I'll stick to Windows for now, and, if at one point in time I'll need to develop for other platform, I'll rewrite the code to work best on that platform.
Don't use anything from the Masm32 package(macros,lib sources,etc) with JWasm as they can't be legally used on Linux.
James
Quote from: jcfuller on February 26, 2010, 04:21:35 PMDon't use anything from the Masm32 package(macros,lib sources,etc) with JWasm as they can't be legally used on Linux.
Thank you. That is crystal clear. But, the license might change until I do my first portable program. :wink
The answers I received here created a better picture in my head, regarding the basics of the process.
Asm programming isn't really portable. Anything that uses winAPI is ... well only for windows. It will only run in Linux through WINE or some virtualization program (don't know about license caveats)