Microsoft Acquires Obsidian & inXile Entertainment

[stormcrow]

Is anyone else confused by this? I don't much care they were bought. Money talks if you have enough of it, and Microsoft does. That's not the surprising part. If the employees are upset about this, they'll simply leave when their contracts are up and form a new independent company with new titles and story worlds. That's pretty much a given.

What confuses me is that neither company makes games that would translate well to the limited control interfaces on consoles - isometric RPGs. If Microsoft intends to bring such games to the XBox I simply cringe at the idea of using a controller to play a Wasteland and Pillars adapted to a console controller interface. Brings to mind the days of playing Gold Box D&D games on my C64 and having to use an Atari joystick for pointing because I couldn't afford a mouse. It worked, but it wasn't pleasant. If they're doing it to enhance their in house PC games portfolio, I'm still confused because neither studio (or even the others they bought this year) is going to bring in hordes of gamers to the Microsoft Store and UWP. For many PC gamers if it's not on Steam, they never see it despite having the Store built into Windows. (Like myself, if it's not on Steam or GOG I won't buy it.)

Exclusivity isn't always a bad thing... until you're trying to push a square peg into a very well established triangular hole.

[Nille]

Bradley Kuhn, who knows a thing or two about this, is not so sure about that.[1]

Or maybe not. But FUD is also something in the FOSS-Camp.

Nat Friedman from Microsoft make it clear that all Microsoft Patents are included even exfat.

https://twitter.com/natfriedman/status/1050035501569167362

So, for example, does this mean the Microsoft-OIN arrangement cover patents pertaining to the File Allocation Table (FAT), Extended FAT (ExFAT), and Virtual (VFAT)? Erich Andersen, Microsoft's corporate vice president and chief intellectual property (IP) counsel, replied: "We're licensing all patents we own that read on the 'Linux system.'"

And even tough this has been voiced by a number of parties, Microsoft has so far (a month has passed) decided not to comment on that.

They have (just hours after the announcement) but its easier to feed his own hate and ignore everything that happened in the past 10 years.

Since Microsoft _has_ sued companies on patent grounds for shipping ExFAT in Linux systems, it would be foolish to just assume that its now fine, even tough the OIN definition does not include things like ExFAT.

Today, Microsoft is making hundreds of millions of dollars in patent licenses just for ExFAT. Do you really assume they will just give that up if they don't have to? In my opinion this would be naive.

And they can sue everyone else who is not in the OIN if they use some of Microsofts patents. So where is now you problem? I guess patents in general. But if you are in the OIN and you Software met the condidions you are free to use Microsoft Patents or any other patent from the OIN Patent pool.

[tg--]

Or maybe not. But FUD is also something in the FOSS-Camp.

Nat Friedman from Microsoft make it clear that all Microsoft Patents are included even exfat.

https://twitter.com/natfriedman/status/1050035501569167362

They have (just hours after the announcement) but its easier to feed his own hate and ignore everything that happened in the past 10 years.

And they can sue everyone else who is not in the OIN if they use some of Microsofts patents. So where is now you problem? I guess patents in general. But if you are in the OIN and you Software met the condidions you are free to use Microsoft Patents or any other patent from the OIN Patent pool.

Nat Friedman is in some way correct that all Microsoft patents seem to be included.
However, that misses the valid point Bradley Kuhn of Software Freedom Conservancy makes, which you also chose to ignore.

The patents are licensed for the "Linux System", which is defined by the OIN.
Bradley is concerned, that the narrow definition the OIN put in their legal text will simply not include things like exFAT.

As I said, these concerns have not been addressed, Nat Friedman of Github (who is not in Microsofts legal team) repeating in a loop that "all patents are included" doesn't help.

I can't understand how you read into that, that I must be against patents in general or spreading FUD.

Conservancy and Kuhn have been in court many times, have handled dozends of court cases regarding the GPL, Linux and patents, and generally have been a well trusted institution.
Mentioning their genuine concern is now considered spreading FUD against Microsoft?

[oiaohm]

It's called Win32 for both man. Just type Win32.

If you are going to correct at least get right.

https://en.wikipedia.org/wiki/Windows_API#Versions

The generic term is WinAPI

Using win32 as generic is abused term because people use to use win32 for Windows 9x to mean Win16 and Win32 now you see people using Win32 as a abused term to mean Win32 and Win64. By Microsoft own documentation when you say win32 you mean 32 bit only.

I am not required to copy other people incorrect usage of terms.

[coder111]

Hello fellow retro-gamer.

Although I'm now in ~2010 era games, I played Build engine games to death more than a decade ago. I don't have much time for games these days...

What I did enjoy recently is using some good reimplementations of classic old games, like 1oom for Master of Orion 1, OpenXcom, etc. Native Linux versions are available which rules.

Oh, and GOG rules. That's the only shop where I plan to spend cash. Steam and other stores with DRM can fuck right off.

--Coder

I agree with this. So long as DRM and the locked down platforms of the future do not get in our way, the gamers should be setting the pace.

For me, I am happy playing through the Build Engine era of games (Blood, Duke 3D, Shadow Warrior). Then I might get onto the Quake Era. By the time I get past the Quake 4 era, I will have a shedload of new titles available as abandonware

[Weasel]

If you are going to correct at least get right.

https://en.wikipedia.org/wiki/Windows_API#Versions

The generic term is WinAPI

Using win32 as generic is abused term because people use to use win32 for Windows 9x to mean Win16 and Win32 now you see people using Win32 as a abused term to mean Win32 and Win64.

That wikipedia article is wrong. Everything it says about Win64 "API" is, in fact, ABI. Size of pointers is ABI (with B) as is any other Binary representation.

Does the Win64 API look different in source code than Win32? Yes? No?

No. Hence it's the same API. API is for source code.

Win32 is different than Win16 though, at the source code level. It tries to be similar, but it's not.

By Microsoft own documentation when you say win32 you mean 32 bit only.

Link?

Here's answer from moderator on Microsoft forum: https://social.msdn.microsoft.com/Fo...rum=netfx64bit

Excerpt:

Win32 is the API set that was introduced with WinNT as a transition to 32-bit code, used in Win95 and lives as the Windows API to today.

64-bit Windows has the Win32 API at its core, with pointer sizes (and pointer sized things) increased to 64-bits, but otherwise the API is intact. There is no Win64 API. It is an unfortunate artifact of naming that the Win32 API is at the heart of writing 64-bit unmanaged code, but that is history for you.

[AlexFonewn]

What confuses me is that neither company makes games that would translate well to the limited control interfaces on consoles - isometric RPGs. If Microsoft intends to bring such games to the XBox I simply cringe at the idea of using a controller to play a Wasteland and Pillars ...

Not that I like this move by MS, but just today has been announced the general availability of mouse+keyboard in Xbox consoles for every game.

[oiaohm]

Does the Win64 API look different in source code than Win32? Yes? No?

Yes it does look minor different between Win32 and Win64 why you have _WIN32 and _WIN64 compiler flags.

https://docs.microsoft.com/en-us/windows/desktop/winprog64/the-new-data-types

POINTER_64 has to be the most deceptive thing left. It use to be way worse. Win64 and Win32 API due to independent development had a stack of typing differences.

https://docs.microsoft.com/en-us/windows/desktop/apiindex/windows-api-list

(Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)
That is the current documentation.
https://docs.microsoft.com/en-us/pre...5(v=technet.10)
Environment. The Win64 API environment is almost the same as the Win32 API environment—unlike the major shift from Win16 to Win32. The Win32 and Win64 APIs are now combined and called the Windows API. Using the Windows API, you can compile the same source code to run natively on either 32-bit Windows or 64-bit Windows. To port the application to 64-bit Windows, just recompile the code.
Some of the prior documentation include notes over what happened.

Please note the now combined bit. Win32 and Win64 use to be published as their own API this why there are some odd #if defined(_WIN64) spreed over Windows API the combined one due issues in selected typing in places. Yes when Win32 and Win64 were two different API there were a few sync errors in typing this resulted before Windows API that you had to code for Win32 or Win64 API and do a lot more #if defined(_WIN64)/#if defined(_WIN32). Yes the big selling point of the new Windows API is the typing mess sorted out so you can get away with 1 source code to build Win32 and Win64 without having to go though #if defined hell.

Reality here when Microsoft added 64 bit they ceased calling the API Win32 API ever since the generic term has been Windows API. Apparently some Microsoft staff did not read the memo. It is now the Windows API like it was called in the first standard. WinAPI short comes from the first standard.

Windows API term is overlaps for the historic generic term for Win16 and this was intentional.

If you go through Microsoft documentation Win32 API only ever applies to the 32 bit version. Win16 API applies to the 16 bit form and Win64 applies to the 64 . Combined forms of either win16+win32 or win32+ win64 is always called Windows API.

Really all your quote shows is that the Microsoft moderator did not read the Microsoft documentation. This is really useful for support.

[Weasel]

Yes it does look minor different between Win32 and Win64 why you have _WIN32 and _WIN64 compiler flags.
https://docs.microsoft.com/en-us/win...new-data-types
POINTER_64 has to be the most deceptive thing left. It use to be way worse. Win64 and Win32 API due to independent development had a stack of typing differences.

That is ABI with a damn B. _WIN64 is a flag for the 64-bit ABI -- i.e. you build the binary for 64-bit.

https://docs.microsoft.com/en-us/win...ndows-api-list
(Note that this was formerly called the Win32 API. The name Windows API more accurately reflects its roots in 16-bit Windows and its support on 64-bit Windows.)
That is the current documentation.
https://docs.microsoft.com/en-us/pre...5(v=technet.10)
Environment. The Win64 API environment is almost the same as the Win32 API environment—unlike the major shift from Win16 to Win32. The Win32 and Win64 APIs are now combined and called the Windows API. Using the Windows API, you can compile the same source code to run natively on either 32-bit Windows or 64-bit Windows. To port the application to 64-bit Windows, just recompile the code.
Some of the prior documentation include notes over what happened.

You realize you just wrecked your own arguments right? There is no Win64 API. You can't just make up stuff like "it's now known as Windows API" and claim it as proof for your bullshit. I don't have issue with "Windows API" so don't think it is any backup to your lies.

Really all your quote shows is that the Microsoft moderator did not read the Microsoft documentation. This is really useful for support.

Or maybe you're just the clueless puppet, ever thought about it, instead of everyone else being wrong?

_WIN64 does not prove in any shape or form that it's the API. It's a preprocessor macro.

[oiaohm]

You realize you just wrecked your own arguments right? There is no Win64 API. You can't just make up stuff like "it's now known as Windows API" and claim it as proof for your bullshit. I don't have issue with "Windows API" so don't think it is any backup to your lies..

Like it or not there is a Win64 API. You do need to find it when you are doing support for old windows xp 64 bit. This is before Win32 and Win64 merged and become Windows API.

https://docs.microsoft.com/en-us/pre...5(v=technet.10)
Environment. The Win64 API environment is almost the same as the Win32 API environment—unlike the major shift from Win16 to Win32. The Win32 and Win64 APIs are now combined and called the Windows API. Using the Windows API, you can compile the same source code to run natively on either 32-bit Windows or 64-bit Windows. To port the application to 64-bit Windows, just recompile the code.

The now combined bit happens at Windows Vista/Windows 2008.

Windows Datacenter Server Limited Edition the first 64 bit version of windows that was basically the prerelease of 2003 64bit had quite differences from the normal; Win32 API in the Win64 API.

http://www.windowswiki.info/2012/07/...ia-64-windows/ why it was made for the IA-64.

The merge of Win32 API and WIn64 API into Windows API saw all the IA-64 bit parts of Win64 API be removed.

The reality here you attempt to correct me with the wrong correction. Win32 API never has covered the 64 bit version. Win32 API and Win64 API combined to make WinAPI. The combine saw a lot of things be dropped out of the Win64 API that were mostly there for IA-64 support. Yes the old Win64 API had stuff use 1 source code to make IA-64 and AMD64 applications handling the differences. IA-64 was flop so that stuff could be dropped.

Yes the difference between Win64 and Win32 would have been as big as the differences between Win16 and Win32 if the IA-64 had been successful.

Weasel the Win64 API is a real thing. The WIndows API today that is Win32 and Win64 merged in fact does not include all that was in Win32 api either.

The current windows API is a subset of the Win32 and Win64 API of old.