640K!enough wrote:

The question is why we should want to run mobile software on a desktop computer.

Are you a mac user? An awful lot of mac users are very happy this, just read some of the comments from mac users in regards to Marzipan. They are quite chuffed!.. but yes personally I can't see the point unless there is a killer app that only exists on iOS and could function on a desktop environment.

640K!enough wrote:

Tim Cook has already told us how much of a "compromised" experience touch on the desktop provides, so how will this work exactly?

meh... they will change their minds... https://www.youtube.com/watch?v=qr_KxouI8Zs

640K!enough wrote:

Are any details available? Will iOS software really be running on the Mac, or will there just be some link to an iOS device? Current and legacy software straight from the store, or will they be twisting developers' arms to rebuild their applications to support this?

Well an ARM compatibility layer was discovered in OSX a few years ago now... turns it was probably Marzipan. There was this https://appleinsider.com/articles/12/02/07/ap … _arm_processors, then someone found some leaked code back in 2016 had the start of an ARM compatiblity layer (google-fu needs to be better for this search since querying 'ARM' and 'OSX' or 'macOS' is polluted by all this recent news 😢 ... but trust me the articles are out there), Darwin runs on ARM.... and if you have ever written an iOS program, this needs to be done on an x86 machine, and you use the similator (this has been there since iOS2/3), so there has always been some form of compatibility layer there... although I think in the case of the simulator it's using x86 compiled binaries... but means the iOS environment (or at least majority of it) existed on x86 since pretty much day one.

640K!enough wrote:

You do realise that we've been hearing the same story for over twenty years, right? In recent memory, first it was Java with "write once, run anywhere" and "the network is the computer". Then, some claimed that .NET would finally usher in that era, and more such predictions were made repeatedly.

Every closed source program is "Write once, run anywhere" surely? The user isn't required to write their own program each time o.0

.NET is a runtime library.... nothing to do with SaaS or cloud based computing (not including any cloud/network services in the .NET framework of course). Despite the name its not anything to do with the 'net' directly.

640K!enough wrote:

We're getting a little closer now, but we're still waiting, and given poor availability of high-speed Internet service and ridiculous overage charges for data usage on home and mobile connections in a number of countries, I doubt we're quite ready for that yet.

There is a fundamental difference between then and now... namely the coupling of the OS to said functionality and services... back then an OS wasn't always expected to go online and they were written to these requirements (can be entirely self-contained) ... these days it's a given. Back then you needed to run it through a browser (not natively in the OS environment... within a browse environment) to get anything remotely similar to what we see as interaction with a 'cloud' service.... these days... your file manager could be executed remotely and streamed and you may be none the wiser until the power goes out.

There are cloud services that can hook into AWS GPU grids and stream this HD/4K back to the user for gaming... this kind of power and bandwidth was unheard of back then limiting what you could do on the 'cloud'/online.

This type of client-server based OS is not unheard of, AT&T did one called Plan9 from Bell labs, which morphed into Inferno. In terms of kenrel design and architecture, it could be argued this was wayyyy ahead of its time, of couse back then we had mainframes and terminals... these days same setup, except the mainframe ain't down the hall... it's "on the other side of the planet".

Streaming is another way to say 'cloud services'... and how much content is streamed these days o.0.

appiah4 wrote:

Not sure I agree with .Net as it's really not platform agnostic as it was fist sold as an idea, but Java certainly is where it aimed to be..

Well, the basic .NET IL has always been platform-agnostic, and Microsoft even provided an open sourced implementation of a .NET VM for FreeBSD. And of course there was Mono.
Problem was that unlike Java, not the entire framework was available for OSes outside of Windows. So only a limited number of applications could run on Mono (Microsoft obviously was never interested in doing any kind of development or support for OSes other than their own, and saw .NET mainly as a way to bridge different CPU architectures and OS variations within the Windows family).
But .NET Core solves that now: just like Java, you get an entire framework that is cross-platform, not just the VM/common language runtime.

Speaking of .NET, there were earlier Windows products that used non-x86 code internally.
* Visual Basic Classic with its P-Code (alternatively, machine code in Pro. versions)
* Windows Scripting Host (Win9x), based on VBScript (or JScript).

Jo22 wrote:

Speaking of .NET, there were earlier Windows products that used non-x86 code internally.
* Visual Basic Classic with its P-Code (alternatively, machine code in Pro. versions)
* Windows Scripting Host (Win9x), based on VBScript (or JScript).

We can probably go back further than that even... The C64 version of BASIC used a form of bytecode as well. That one was based on Microsoft BASIC. So I wouldn't be surprised if Microsoft developed it like that. It makes sense, both performance-wise and storage-wise.

Another thing to keep in mind, Apple wants to make iOS a thing on the Mac lineups for developing apps for the iPhone, iPad, and iPod touch. Microsoft did that when they first released the Surface tablets when Windows 8 came out for developing apps for tablets, laptops (2-in-1 style or standard), and desktops (with touch screen or mouse) that have Windows 8, 8.1, or 10 installed.

bjwil1991 wrote:

Another thing to keep in mind, Apple wants to make iOS a thing on the Mac lineups for developing apps for the iPhone, iPad, and iPod touch. Microsoft did that when they first released the Surface tablets when Windows 8 came out for developing apps for tablets, laptops (2-in-1 style or standard), and desktops (with touch screen or mouse) that have Windows 8, 8.1, or 10 installed.

What do you mean? like UWP?

All iOS development (outside Apple themselves...probably) has to be done through xCode (on macOS only, so macs only) ergo all iOS development is done on x86/x64 and 'cross compiled' to ARM. When they port xCode to the new macOS/ARM, I doubt 90% of iOS developers (and macOS developers) will notice any change to the toolchain other than IDE-isms and wotnot o.0. The frameworks will no doubt come together even more and mature into a single one for the sandboxed ARM deployment.

Question is what will this new macOS/ARM be like? Will they allow the terminal and gcc for example? Will it loose its Unix standard? How much Desktop vs Mobile isms will there be (MetroUI 🤣).

Scali wrote:

Well, the basic .NET IL has always been platform-agnostic, and Microsoft even provided an open sourced implementation of a .NET VM for FreeBSD. And of course there was Mono.
Problem was that unlike Java, not the entire framework was available for OSes outside of Windows. So only a limited number of applications could run on Mono (Microsoft obviously was never interested in doing any kind of development or support for OSes other than their own, and saw .NET mainly as a way to bridge different CPU architectures and OS variations within the Windows family).
But .NET Core solves that now: just like Java, you get an entire framework that is cross-platform, not just the VM/common language runtime.

From what I read, WPF/GUI stuff is Windows/UWP only. Is there any work being done to extend this or is the primary focus of .NET Core on providing additional platforms for Microsoft's Web and business logic stack?

gdjacobs wrote:

From what I read, WPF/GUI stuff is Windows/UWP only.

You're confusing two things here:
.NET is not the same as .NET Core.
.NET Core is platform-indepdenent.
WPF is not part of .NET Core.
Therefore, WPF isn't available on .NET Core on Windows either, since it's the same on all platforms.

gdjacobs wrote:

Is there any work being done to extend this or is the primary focus of .NET Core on providing additional platforms for Microsoft's Web and business logic stack?

I have no idea. Of course, any third-party could develop a GUI framework for .NET Core as well. Basically the same as what AWT and Swing are for Java.
This is probably available already, because I've seen such things for Mono in the past.

Scali wrote:

[We can probably go back further than that even... The C64 version of BASIC used a form of bytecode as well. [..]

I completely agree. The oldest system using byte-code I know of (personally) is CHIP-8.
It originates back to the 70s and the COSMAC platform and became popular among the young emulation scene.
There even was one implementation for Win 3.1, at least. In some way or another, CHIP-8 can be seen as the ancestor of Java..

http://www.cosmacelf.com/history/

spiroyster wrote:

Are you a mac user? An awful lot of mac users are very happy this, just read some of the comments from mac users in regards to Marzipan. They are quite chuffed!.. but yes personally I can't see the point unless there is a killer app that only exists on iOS and could function on a desktop environment.

I guess I'm not a typical Mac user by modern standards, but yes, a Mac is among the platforms I use. Just like when the iPad first shipped and most of the software available for it was really developed for the iPhone, I think this will be a sub-par experience, unless they've done an exceptionally good job. Frankly, I still don't see the point. If your platform has a mobile application that is so compelling, yet there is no desktop counterpart, to me, that says that something is not right in your "eco-system". If the application in question is really mobile-centric, or works best on mobile, then what is the point of trying to shoe-horn it onto the desktop? I guess we'll see what actually comes of this following its unveiling, but it seems like a strange way to do things.

spiroyster wrote:

Every closed source program is "Write once, run anywhere" surely? The user isn't required to write their own program each time o.0

Maybe you avoided the many articles of the time, but that wasn't what they were promising/predicting at all. The promise there was that I, as the developer, could write my application once, with a single source tree, and have it run on my PowerPC Mac, your BlackBerry, Scali's Windows machine and Mr. Torvalds's Linux machine, all with minimal or no modifications, and maybe even without re-compilation.

The commonly-believed extension to that, was the concept of "the network is the computer", another Sun-ism. The story commonly thrown around at the time was that, through the magic of Java, we soon wouldn't "buy" or install software anymore, and wouldn't have computers as we knew them. We would subscribe to applications, and always have the latest version. Our systems would be dumb, having no local secondary storage, little processing power or memory. Our work and environment would all be accomplished by transferring bits over the network, and those all-powerful servers would crunch all of everybody's data and send back the new display/content/results. So, as I said, we are somewhat closer, but we are still not there, and I'm not so sure we're going there, exactly.

Even from your description, we don't really have the level of connectivity necessary. How many people, even in urban areas of the United States, can't get anything better than 3008/256 DSL on an unstable line that should have been replaced long ago? How many people can't get wired service at all and rely on satellite connections and all of the compromises that that entails? How many North American providers price their offering reasonably, to the point where an existence that is connected to the extent you describe would be feasible?

EDIT: There were also Java processor prototypes, at one point, promising to offer better performance for Java software. No JVM, no JIT; just native execution of bytecode. I think they were calling them picoJava, microJava, etc. Thankfully, that is an idea that didn't last too long, either.

Scali wrote:

You're confusing two things here: .NET is not the same as .NET Core. .NET Core is platform-indepdenent. WPF is not part of .NET […]
Show full quote

You're confusing two things here:
.NET is not the same as .NET Core.
.NET Core is platform-indepdenent.
WPF is not part of .NET Core.
Therefore, WPF isn't available on .NET Core on Windows either, since it's the same on all platforms.

I'm pretty clear on the difference. .NET Core is meant to be a portable re-implementation of the majority of the framework. I was mistaken about there being a desktop GUI toolkit included in .NET Core. I'm actually kind-of glad that it's not included, although that will leave some developers out in the rain.

They say it's ~90% shared code with a little bit being platform specific. Not quite platform independent, but much more portable.

Our systems would be dumb, having no local secondary storage, little processing power or memory. Our work and environment would […]
Show full quote

Our systems would be dumb, having no local secondary storage, little processing power or memory.
Our work and environment would all be accomplished by transferring bits over the network, and those all-powerful servers would
crunch all of everybody's data and send back the new display/content/results. So, as I said, we are somewhat closer, but we are still not
there, and I'm not so sure we're going there, exactly.

It is ironic, how society describes the future of computing, when in reality, this vision leads back to the roots of computing.
The host/terminal concept from the 60s/70s is quite similar to that, as well as the client/server concept in general is:
Multiple, rather dumb terminals are connected to a powerful main computer that hosts all applications, does the calculations
by priority on a time-sharing basis, etc.

This is in stark contrast to the enthusiasm of users of the mid-late 70s, when personal computers debuted.
How happy they were to have heir own computers at hand and were able to get rid of the necessity to have to wait
for free computing time when they had to login at a terminal at the university (or workplace) in order to do some calculations.

Now we're heading away, heading back to an old concept. We give up on individualism and self-sufficiency that we got.
In the years to come, we'll loose step-by-step the ability to even write a simple document, edit pictures or listen to music without beeing
connected to the internet. If a disaster strucked or a malware infected servers of "our" service company,
we'll either loose access to all our data at once or are unable to open it, because that app we need is not locally available.

"I think there is a world market for maybe five computers."

Errius wrote:

"I think there is a world market for maybe five computers."

Oh yes, I remember that one, hah. 😁

Sorry if my previous post sounded a bit exaggerated, it wasn't meant that way. 😅
Thin Clients or similar underpowered devices are on their way, though.
Thanks to the whole Cloud and IoT visions.

I just hope that people (esp. IT professionals, PC maker, etc) are smart enough ("smart" device are a thing)
to not treat a full-featured computer like a kitchen terminal build into a fridge or a washing machine.
Just to think of that Personal Computers might become as limited as a WinCE device, gives me chills.

Just saw it in the news - "iOS will not merge with Mac OS":
https://www.phonearena.com/news/apple-wont-co … nd-ios_id104237

Whatever that means in the end.
Well, at least they somehow recognize that users want them to stay separate OSes.
Not all big companies seem to understand this. 😉

Jo22 wrote:

Whatever that means in the end.
Well, at least they somehow recognize that users want them to stay separate OSes.
Not all big companies seem to understand this. 😉

As a developer I think the split between macOS and iOS is horrible. Having a single OS for all devices makes it much easier to port applications.
I am talking about the OS at a lower level of course. Not about the GUI, which is... a GUI. Just something that runs on top of an OS. A single OS can support multiple GUIs, and a single GUI could be supported by multiple OSes.

Basically shared APIs and tools is what you want. There's no reason for something like iOS to have different APIs and frameworks for the same tasks.
Microsoft understands this like no other (Developers developers developers!). Native code can be compiled for any Windows 10 variation without a problem, and .NET code doesn't even need to be compiled for a specific OS/CPU in the first place. It just runs as-is.

Of course if everything were using the same OS it would make the job easier for everyone 😀
OTOH it's not that bad, if you use something like SDL, not much special work needed for different OS' 😀

Dominus wrote:

Of course if everything were using the same OS it would make the job easier for everyone 😀

It doesn't necessarily have to be the same OS underneath (which technically it isn't in the case of Windows 10), but the same APIs and frameworks help a lot.

Dominus wrote:

OTOH it's not that bad, if you use something like SDL, not much special work needed for different OS' 😀

Actually it is, because crap like SDL is always super-bugged and lowest-common-denominator.
You can't do the stuff you want to do, and some of the stuff starts running at seconds-per-frame speed on certain devices for no apparent reason.

The beauty of Windows 10 is that I get the EXACT same DirectX on desktops, servers, tablets, smartphones and whatnot.
No surprises.
(Unlike OpenGL... even though they ported OpenGL to mobile devices, they STILL screwed it up in OpenGL ES by changing the API and introducing new shader dialects, so shit still doesn't work).

Well, IMO SDL is great and not crap. Makes Exult easy to port and run great on different devices and OS. And since it takes care of the graphics backend, no need to worry too much about DirectX, OpenGL etc...
But whatever floats your boat, doesn't sound as if you want to stray from Windows 10 anyway...

Dominus wrote:

And since it takes care of the graphics backend, no need to worry too much about DirectX, OpenGL etc...

It doesn't though.
SDL just does the basic window management and 2d rendering. If you want to use 3d acceleration, you still need to use OpenGL directly.

Dominus wrote:

But whatever floats your boat, doesn't sound as if you want to stray from Windows 10 anyway...

Why not?
It's just that when I use OpenGL, I write my own wrapper, to avoid the limitations and bugs that SDL offers (or any other wrapper for that matter, such as GLUT).
My OpenGL engine currently runs on Windows, FreeBSD, macOS, iOS, linux and Android. But every step took quite a bit more work than getting my D3D engine to run on all Windows devices. Just stating those facts.
And the reason is that Windows has a higher level of standardization in their APIs. This leads to less special-case code on the CPU-side, and no extra work at all on the GPU side. With OpenGL, I have to use separate sets of shaders for different API versions/devices. I say that fails at being a standard.