Apple to remove popular DOS emulator for iOS from App Store

2»

Comments

  • Reply 21 of 25
    "Betrayal to paying customers"....people really pay money to run a DOS emulator on an iPhone in 2021? 
    Lots of people pay money for DOS software wrapped in an emulator, it's called GOG.com

    This emulator allowed people to legally use that software or copies of their original disks on their iPad or iPhone and was truly the only one of its kind on iOS.
    FileMakerFeller
  • Reply 22 of 25
    dysamoria said:
    larryjw said:
    Rayz2016 said:
    larryjw said:
    I think Apple's guideline rejecting executing code is needs to be eliminated -- an emulator is an emulator. 

    In reality, executing code in an emulator is what programs do. For example, PDF files are themselves computer programs which instruct and iPad how to render a PDF visually.

    Isn't programs as data and data as programs the basic principle of computing? 


    No, PDF is a document format. It doesn’t run, it’s rendered, same with music files. But that’s not the real problem. 

    The emulator allows apps to run code that can’t be seen or examined by Apple, and that has always been against the rules. PDFs, the other hand, are pretty benign. It would be quite hard to piggyback an App Store in a PDF document. 

    So the real problem is the lack of consistency in applying the rules. This should never have  been allowed in the App Store in the first place, so they’re going to look like real dicks for removing it now. 
    No, a PDF is a program. Just because a PDF can be labeled a document doesn’t mean it’s not a program. You need to take abstraction up a level. 

    A previous commenter also suggested that a program must be executed on the CPU. That’s also not correct.

    In designing systems, one is always trading off between the “executable” and the “data”. Different languages tend to encourage marking the boundaries differently, but it remains that these boundaries between data and executable are quite arbitrary. 

    In a micro programmed CPU, your “executable” is just data. To the hardware guys, the micro program is just data which drives NAND gates and voltage changes. 
    It’s not an executable. That’s the issue. 

    PDF Files can definitely contain executable code
    edited July 2021
  • Reply 23 of 25
    This story was written from Apple's point of view: Apple removed an iOS app because the developer did not follow the rules. This is just propaganda for Apple.
    Here's the real story: Apply denied users from being able to run the software they want to use on the devices they own. This is a much more important story. It is central to Apple's corporate culture and its belief that it should have total control over all the computers it sells. This is not about your safety as a user. It is about your freedom to make decisions for yourself. Apple Computer (as it used to be known) was founded around the idea of bringing the power of computers to everyone. On Apple's 10th anniversary, they released a book called "So Far". It is full of stories about how people became empowered through their use of Apple computers. That's not the story Apple would tell today. Instead it would be about the things that Apple allows you to do with their computers. The ultimate version of this new vision is the Apple Watch which had use cases from the very start. If your app fell into one of those use cases, it was allowed. Anything else was not just rejected, it was forcibly denied existence. That's why there are no third party watch faces even though this is an obvious app type. Apple has become a company that is all about its own power rather than empowering its customers.
    KITAelijahg
  • Reply 24 of 25
    dysamoria said:
    larryjw said:
    Rayz2016 said:
    larryjw said:
    I think Apple's guideline rejecting executing code is needs to be eliminated -- an emulator is an emulator. 

    In reality, executing code in an emulator is what programs do. For example, PDF files are themselves computer programs which instruct and iPad how to render a PDF visually.

    Isn't programs as data and data as programs the basic principle of computing? 


    No, PDF is a document format. It doesn’t run, it’s rendered, same with music files. But that’s not the real problem. 

    The emulator allows apps to run code that can’t be seen or examined by Apple, and that has always been against the rules. PDFs, the other hand, are pretty benign. It would be quite hard to piggyback an App Store in a PDF document. 

    So the real problem is the lack of consistency in applying the rules. This should never have  been allowed in the App Store in the first place, so they’re going to look like real dicks for removing it now. 
    No, a PDF is a program. Just because a PDF can be labeled a document doesn’t mean it’s not a program. You need to take abstraction up a level. 

    A previous commenter also suggested that a program must be executed on the CPU. That’s also not correct.

    In designing systems, one is always trading off between the “executable” and the “data”. Different languages tend to encourage marking the boundaries differently, but it remains that these boundaries between data and executable are quite arbitrary. 

    In a micro programmed CPU, your “executable” is just data. To the hardware guys, the micro program is just data which drives NAND gates and voltage changes. 
    It’s not an executable. That’s the issue. 

    PDF Files can definitely contain executable code
    Some of you have been around since dawn of OSX, but are forgetting OSX and it’s current derivatives use the PDF spec for graphics as a major part of the display interpretation and execution. Much of that was inherited from NeXT code with genius Avie Tevanian as major architect at NeXT and Apple.

    Any PDF graphics (all graphics for that matter) contained are handled by existing OS layer close to the kernel. It’s safe and mature. Non-PDF graphics are translated and handled as display PDF and display PDF shouldn’t be the issue. PDF documents have features like links, authentication and more that are likely at an execution of function in a sandboxed area. 
    The graphic display computing is now baked into silicon for speed in Metal. 

    I’d imagine DOS has many vulnerabilities. Whether the sandbox can be penetrated (or escaped) is something Apple engineers can determine in a non-disclosed manner. 
    There seems to be a lot of conjecture as to why the App was rejected beyond the stated reasons.
    edited July 2021 watto_cobra
  • Reply 25 of 25
    Rayz2016 said:
    larryjw said:
    I think Apple's guideline rejecting executing code is needs to be eliminated -- an emulator is an emulator. 

    In reality, executing code in an emulator is what programs do. For example, PDF files are themselves computer programs which instruct and iPad how to render a PDF visually.

    Isn't programs as data and data as programs the basic principle of computing? 


    No, PDF is a document format. It doesn’t run, it’s rendered, same with music files. But that’s not the real problem. 

    The emulator allows apps to run code that can’t be seen or examined by Apple, and that has always been against the rules. PDFs, the other hand, are pretty benign. It would be quite hard to piggyback an App Store in a PDF document. 

    So the real problem is the lack of consistency in applying the rules. This should never have  been allowed in the App Store in the first place, so they’re going to look like real dicks for removing it now. 
    PDFs can contain Javascript, so while it would be a little tricky I don't think it would be too difficult for a determined programmer. Plus you've got the PostScript angle, which is itself a programming language.
    watto_cobra
Sign In or Register to comment.