History Main / SoftwarePorting

31st Mar '15 4:49:56 PM MarkLungo
Is there an issue? Send a Message
Namespace change.
The term ''porting'' is one that is feared by software developers, loved by [[PointyHairedBoss management]], and possibly thrown left and right indiscriminately by consumers. Software porting is when software written for one environment, which can be a particular hardware configuration, OS, API, etc., is written for another environment. The reality sets in when every environment is typically different from one another. It's like trying to make ''San Francisco Sourdough Bread'' when you're in another part of the world. There's a reason why it's specific to the city [[note]]It's due to the [[https://en.wikipedia.org/wiki/Lactobacillus_sanfranciscensis Lactobacillus Sanfranciscensis]] bacteria that was found there, but it can be found elsewhere.[[/note]] PortingDisaster is a good read. Considering how long the list is, it can be obviously shown that porting is ''not an easy thing to do!'' Scenarios that make porting much harder include: * Hardware incompatibilities ** Processor architectures vary wildly from one another, and it's probably a miracle that two are even "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process ''exactly the same''). For example, porting from the 65816 (Super Nintendo) architecture to the M68000 (Sega Genesis) is no easy task, since the two processors use entirely different, entirely incompatible machine languages. These days this is much less of a problem, because nowadays code is usually written in a high-level language such as C++, but processor architecture can still cause issues in high-performance code. ** Even if the port is going from one environment to a very similar one, other hardware considerations must be taken to account. *** For example, ''VideoGame/DeusExInvisibleWar'', which was made for the XBox in mind, was considered paltry on the PC, despite the XBox running fully compatible x86 PC hardware. While not exactly a port, the developers didn't want to "port" it and thus the levels were assuming a machine with 64MB of memory, when [=PCs=] of the time could easily have 512MB of memory. ** Custom hardware. Many 8- and 16-bit computers (and nearly all game consoles) were packed with custom chips to handle graphics, sound and other tasks. Applications and games that make use of that hardware can be especially tricky to port. *** For example, a common complaint when SNES games that were ported over to the GameBoyAdvance was usually the music. The audio chip used was only a DAC, software had to do all the mixing whereas the {{SNES}} [=SPC700=] had hardware mixing. * Software incompatibilities ** Programs between operating systems won't work, even if the hardware is exactly the same. The OS has specific function calls to do things, and between Linux, UNIX, [=Mac OS X=], and Windows, they're all different. [[note]]Linux, UNIX, and [=Mac OS X=] more or less follow POSIX which is a standard. Of course, nobody told them how to implement the standard.[[/note]] ** Using a programming language that has limited or no support for the platform. One of the easiest ways to make software not-portable is to write it in assembly language (which is specific to a family of hardware). Even among high-level languages, some are used more on some environments than others: it would be harder to port a C# application to Mac OS, or an Objective-C application to Windows, than it would be to port a C++ application either way. *** This also includes relying on libraries or UsefulNotes/{{API}}s that don't have support on the platform. ** Fortunately, there is a novel approach to avoiding potential software incompatibilities, and that is translating and compiling the base code from one programming language to another without the need for additional libraries or [=APIs=] that will bloat both the program and the system it is installed in. One example is [[http://www.eqela.com/ Eqela]]. Many programmers today try to avoid porting disasters and minimize the time to port by carefully designing their software such that the core parts are the only thing that needs changing. Everything else can just "plug in" and work as expected.
to:
The term ''porting'' is one that is feared by software developers, loved by [[PointyHairedBoss management]], and possibly thrown left and right indiscriminately by consumers. Software porting is when software written for one environment, which can be a particular hardware configuration, OS, API, etc., is written for another environment. The reality sets in when every environment is typically different from one another. It's like trying to make ''San Francisco Sourdough Bread'' when you're in another part of the world. There's a reason why it's specific to the city [[note]]It's due to the [[https://en.wikipedia.org/wiki/Lactobacillus_sanfranciscensis Lactobacillus Sanfranciscensis]] bacteria that was found there, but it can be found elsewhere.[[/note]] PortingDisaster is a good read. Considering how long the list is, it can be obviously shown that porting is ''not an easy thing to do!'' Scenarios that make porting much harder include: * Hardware incompatibilities ** Processor architectures vary wildly from one another, and it's probably a miracle that two are even "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process ''exactly the same''). For example, porting from the 65816 (Super Nintendo) architecture to the M68000 (Sega Genesis) is no easy task, since the two processors use entirely different, entirely incompatible machine languages. These days this is much less of a problem, because nowadays code is usually written in a high-level language such as C++, but processor architecture can still cause issues in high-performance code. ** Even if the port is going from one environment to a very similar one, other hardware considerations must be taken to account. *** For example, ''VideoGame/DeusExInvisibleWar'', which was made for the XBox in mind, was considered paltry on the PC, despite the XBox running fully compatible x86 PC hardware. While not exactly a port, the developers didn't want to "port" it and thus the levels were assuming a machine with 64MB of memory, when [=PCs=] of the time could easily have 512MB of memory. ** Custom hardware. Many 8- and 16-bit computers (and nearly all game consoles) were packed with custom chips to handle graphics, sound and other tasks. Applications and games that make use of that hardware can be especially tricky to port. *** For example, a common complaint when SNES games that were ported over to the GameBoyAdvance was usually the music. The audio chip used was only a DAC, software had to do all the mixing whereas the {{SNES}} [=SPC700=] had hardware mixing. * Software incompatibilities ** Programs between operating systems won't work, even if the hardware is exactly the same. The OS has specific function calls to do things, and between Linux, UNIX, [=Mac OS X=], and Windows, they're all different. [[note]]Linux, UNIX, and [=Mac OS X=] more or less follow POSIX which is a standard. Of course, nobody told them how to implement the standard.[[/note]] ** Using a programming language that has limited or no support for the platform. One of the easiest ways to make software not-portable is to write it in assembly language (which is specific to a family of hardware). Even among high-level languages, some are used more on some environments than others: it would be harder to port a C# application to Mac OS, or an Objective-C application to Windows, than it would be to port a C++ application either way. *** This also includes relying on libraries or UsefulNotes/{{API}}s that don't have support on the platform. ** Fortunately, there is a novel approach to avoiding potential software incompatibilities, and that is translating and compiling the base code from one programming language to another without the need for additional libraries or [=APIs=] that will bloat both the program and the system it is installed in. One example is [[http://www.eqela.com/ Eqela]]. Many programmers today try to avoid porting disasters and minimize the time to port by carefully designing their software such that the core parts are the only thing that needs changing. Everything else can just "plug in" and work as expected.[[redirect:UsefulNotes/SoftwarePorting]]
9th Nov '14 1:09:12 PM xenol
Is there an issue? Send a Message
The term ''porting'' is one that is feared by software developers, loved by [[PointyHairedBoss management]], and possibly thrown left and right indiscriminately by consumers. Software porting is when software written for one environment, which can be a particular hardware configuration, OS, API, etc., is written for another environment. The reality sets in when every environment is typically different from one another. It's like trying to make ''San Francisco Sourdough Bread'' when you're in another part of the world. There's a reason why it's specific to the city [[note]]It's due to the [[https://en.wikipedia.org/wiki/Lactobacillus_sanfranciscensis Lactobacillus Sanfranciscensis]] bacteria that's local only to the San Francisco Bay Area region[[/note]]
to:
The term ''porting'' is one that is feared by software developers, loved by [[PointyHairedBoss management]], and possibly thrown left and right indiscriminately by consumers. Software porting is when software written for one environment, which can be a particular hardware configuration, OS, API, etc., is written for another environment. The reality sets in when every environment is typically different from one another. It's like trying to make ''San Francisco Sourdough Bread'' when you're in another part of the world. There's a reason why it's specific to the city [[note]]It's due to the [[https://en.wikipedia.org/wiki/Lactobacillus_sanfranciscensis Lactobacillus Sanfranciscensis]] bacteria that's local only to the San Francisco Bay Area region[[/note]] that was found there, but it can be found elsewhere.[[/note]]
9th Nov '14 1:07:36 PM xenol
Is there an issue? Send a Message
The term ''porting'' is one that is feared by software developers, loved by [[PointyHairedBoss management]], and possibly thrown left and right indiscriminately by consumers. Software porting is when software written for one environment, which can be a particular hardware configuration, OS, API, etc., is written for another environment. The reality sets in when every environment is typically different from one another. It's like trying to make ''San Francisco Sourdough Bread'' when you're in another part of the world. [[note]]There's a reason why it's specific to the city.[[/note]]
to:
The term ''porting'' is one that is feared by software developers, loved by [[PointyHairedBoss management]], and possibly thrown left and right indiscriminately by consumers. Software porting is when software written for one environment, which can be a particular hardware configuration, OS, API, etc., is written for another environment. The reality sets in when every environment is typically different from one another. It's like trying to make ''San Francisco Sourdough Bread'' when you're in another part of the world. [[note]]There's There's a reason why it's specific to the city.[[/note]] city [[note]]It's due to the [[https://en.wikipedia.org/wiki/Lactobacillus_sanfranciscensis Lactobacillus Sanfranciscensis]] bacteria that's local only to the San Francisco Bay Area region[[/note]]
8th Oct '14 8:56:52 PM FurryKef
Is there an issue? Send a Message
Code for modern consoles is almost invariably C++ or something similar, making the processor architecture much less relevant. Replacing with better examples.
** Processor architectures vary wildly from one another, and it's probably a miracle that two are even "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process ''exactly the same''). For example, porting from the x86 (PC) architecture to the [=POWER5=] ({{Xbox 360}} or {{Play Station 3}}) is no easy task. The x86 is a CISC processor, [=POWER5=] is a RISC processor. x86 addresses memory Little Endian style, while [=POWER5=] does it Big Endian style. And ultimately, the processors' machine language is different.
to:
** Processor architectures vary wildly from one another, and it's probably a miracle that two are even "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process ''exactly the same''). For example, porting from the x86 (PC) 65816 (Super Nintendo) architecture to the [=POWER5=] ({{Xbox 360}} or {{Play Station 3}}) M68000 (Sega Genesis) is no easy task. The x86 is a CISC processor, [=POWER5=] is a RISC processor. x86 addresses memory Little Endian style, while [=POWER5=] does it Big Endian style. And ultimately, task, since the processors' two processors use entirely different, entirely incompatible machine languages. These days this is much less of a problem, because nowadays code is usually written in a high-level language is different.such as C++, but processor architecture can still cause issues in high-performance code.
8th Oct '14 8:52:21 PM FurryKef
Is there an issue? Send a Message
much more harder -> much harder
Scenarios that make porting much more harder include:
to:
Scenarios that make porting much more harder include:
8th Oct '14 8:51:37 PM FurryKef
Is there an issue? Send a Message
apostrophe
** Processor architectures vary wildly from one another, and it's probably a miracle that two are even "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process ''exactly the same''). For example, porting from the x86 (PC) architecture to the [=POWER5=] ({{Xbox 360}} or {{Play Station 3}}) is no easy task. The x86 is a CISC processor, [=POWER5=] is a RISC processor. x86 addresses memory Little Endian style, while [=POWER5=] does it Big Endian style. And ultimately, the processors machine language is different.
to:
** Processor architectures vary wildly from one another, and it's probably a miracle that two are even "binary compatible" (this is the most compatibility you can get, where the 0s and 1s process ''exactly the same''). For example, porting from the x86 (PC) architecture to the [=POWER5=] ({{Xbox 360}} or {{Play Station 3}}) is no easy task. The x86 is a CISC processor, [=POWER5=] is a RISC processor. x86 addresses memory Little Endian style, while [=POWER5=] does it Big Endian style. And ultimately, the processors processors' machine language is different.
22nd Jun '14 11:20:46 PM SpiderRider3
Is there an issue? Send a Message
** Programs between operating systems won't work, even if the hardware is exactly the same. The OS has specific function calls to do things, and between Linux, UNIX, [=MacOS X=], and Windows, they're all different. [[note]]Linux, UNIX, and [=Mac OSX=] more or less follow POSIX which is a standard. Of course, nobody told them how to implement the standard.[[/note]]
to:
** Programs between operating systems won't work, even if the hardware is exactly the same. The OS has specific function calls to do things, and between Linux, UNIX, [=MacOS [=Mac OS X=], and Windows, they're all different. [[note]]Linux, UNIX, and [=Mac OSX=] OS X=] more or less follow POSIX which is a standard. Of course, nobody told them how to implement the standard.[[/note]]
26th Jan '14 8:29:39 PM MoonlightBomber
Is there an issue? Send a Message
Learned about Eqela from the Manila Game Jam, which I participated in.
to:
** Fortunately, there is a novel approach to avoiding potential software incompatibilities, and that is translating and compiling the base code from one programming language to another without the need for additional libraries or [=APIs=] that will bloat both the program and the system it is installed in. One example is [[http://www.eqela.com/ Eqela]].
1st Sep '13 3:25:35 AM Viira
Is there an issue? Send a Message
The term ''porting'' is one that is feared by software developers, loved by [[PointyHairedBoss management]], and possibly thrown left and right indiscriminately by consumers. Software porting is when software written for one environment, which can be a particular hardware configuration, OS, API, etc., is written for another environment. The reality sets in when every environment is typically different from one another. It's like trying to make ''San Francisco Sourdough Bread'' when you're in another part of the world. [[hottip:*:There's a reason why it's specific to the city.]]
to:
The term ''porting'' is one that is feared by software developers, loved by [[PointyHairedBoss management]], and possibly thrown left and right indiscriminately by consumers. Software porting is when software written for one environment, which can be a particular hardware configuration, OS, API, etc., is written for another environment. The reality sets in when every environment is typically different from one another. It's like trying to make ''San Francisco Sourdough Bread'' when you're in another part of the world. [[hottip:*:There's [[note]]There's a reason why it's specific to the city.]] [[/note]]
18th Aug '13 2:26:30 PM FearlessSon
Is there an issue? Send a Message
** Even if the port is going from one environment to a very similar one, hardware considerations must be taken to account.
to:
** Even if the port is going from one environment to a very similar one, other hardware considerations must be taken to account.
This list shows the last 10 events of 35. Show all.