• 0

Deploy .NET w/o the Framework


Question

Just thought I would post this, as the app/methods employed are pretty interesting for .NET devs. The samples on the page are interesting, as well.

Salamander .NET Linker and Mini-Deployment Tool

Salamander .NET Linker and mini-deployment tool allows you to link .NET assemblies together into a single file, and to deploy your application without installation of the whole Microsoft .NET Framework. The linker selectively links MSIL code putting together only the required classes and methods, and it is capable of linking into the Microsoft .NET framework class libraries. The mini-deployment tool then builds a minimum set of the Microsoft .NET runtime to ship with your application. This usually results in installation size of a few mega bytes, rather than tens of mega bytes, and the installation takes much less time without rebooting machines. The mini-deployed application can be launched directly from a CD, absolutely without copying files or adding registry entries.
The mini-deployment tool puts together the minimum set of CLR runtime files and dependent assemblies that can be simply copied to a single folder on a target machine, and your application runs as if the whole framework is installed. Since the installation is isolated into a single folder, there will be no conflicts with future .NET installation. When linking is used for the dependent assemblies, it will further reduce the file size.
Link to comment
https://www.neowin.net/forum/topic/210209-deploy-net-wo-the-framework/
Share on other sites

Recommended Posts

  • 0
You should read up on what i have said previously on .NET security in this thread. What you are saying makes very little sense...

What you said earlier about .NET security has little applicability to hackers. Yes, .NET is permission-based so that applications cannot access the system. And yes, .NET uses managed code so that memory is not illegally accessed. But all that does, is stop a .NET application from performing malicious actions. A hacker would probably sidestep all that and attack the code parser or bugs in the other framework libraries (which usually have higher privileges such as System.Reflection). That's how it's been done in the past with other VMs. For example, a malformed file could crash the code parser before it even gets to the JIT compiler or poor programming logic in the libraries could allow privilege escalation. How many times has Microsoft had to patch the Microsoft Java VM because there were security holes? Don't forget that the MSJVM is built with similar concepts to .NET.

It is agreed that you shouldnt install things you dont need, but with the increase in applications written on the .NET framework having it installed can make it easier on users. Again installing the .NET framework isnt more of a "Security hole" than installing the OS itself (which .NET is far more safe than).
Making it easier for users has nothing to do with security. Often it is the case that making things easier is usually a comprimise on security. Should Microsoft bundle every single software in the world to make it easier for users? I never said that the .NET Framework was a "security hole" but having it installed just creates more things for you to patch when updates are released. By the way, I hope you've installed SP1 for the .NET Framework because it patches several vulnerabilities.
Huh? Again you show your extreme lack of knowledge in .NET...

MS released .NET as a standard as i already said (if you are technical enough you can read both standards documents here (C# Spec.) and here (CLI Spec.)). Those standards are what Mono is built upon. That is the reason Mono based apps CAN run on the MS .NET Framework and vice versa (provided Mono supports the librarys being loaded as Mono isnt complete yet).

Only a small subset of the .NET Framework is standardized. (I heard that only 10% is standardized but don't quote me on that.) The rest is proprietary and is subject to change or to licensing issues. Microsoft only said that the standardized parts are provided on a royalty-free basis and has said nothing of the non-standardized parts.

The reason why Mono can run .NET apps so successfully is because Mono choose to implement not only the standardized APIs but also those APIs that are proprietary to MS. e.g., System.Windows.Forms . Mono choose to benefit the greater public by implementing those proprietary APIs so that most applications can be run on both Windows and Linux. FYI, System.Windows.Forms in run on Linux using WINE.

Maybe one day we will get true techs speaking on tech related topics. I'm getting very very sick of these self proclaimed techies that know nothing of what they choose to speak on. Heres a nice hint of advice...

If you dont know what your talking about, don't talk about it!

I apologize for making myself sound like an idiot. I had no intention of lying.

  • 0
Only a small subset of the .NET Framework is standardized. (I heard that only 10% is standardized but don't quote me on that.) The rest is proprietary and is subject to change or to licensing issues. Microsoft only said that the standardized parts are provided on a royalty-free basis and has said nothing of the non-standardized parts.

The reason why Mono can run .NET apps so successfully is because Mono choose to implement not only the standardized APIs but also those APIs that are proprietary to MS. e.g., System.Windows.Forms . Mono choose to benefit the greater public by implementing those proprietary APIs so that most applications can be run on both Windows and Linux. FYI, System.Windows.Forms in run on Linux using WINE.

The MSIL code layout is a standard, that's why the people behind mono didn't have to reverse-engineer it

the entire C# language is a standard, same with the compiler.

ms standardised the CLS, which is how the languages can interoperate, by making everything strongly typed and shared.

the way that the framework calls are made (e.g. to System.Xml.XmlSerializer) is the way ms wrote it, it isn't a standard and ms are not protecting it.

The only things Microsoft didn't standardise are Windows only API calls, like the System.Windows.Forms namespace

But, i might be wrong about some of the information, i read about it ages ago.

  • 0
The MSIL code layout is a standard, that's why the people behind mono didn't have to reverse-engineer it

the entire C# language is a standard, same with the compiler.

ms standardised the CLS, which is how the languages can interoperate, by making everything strongly typed and shared.

the way that the framework calls are made (e.g. to System.Xml.XmlSerializer) is the way ms wrote it, it isn't a standard and ms are not protecting it.

The only things Microsoft didn't standardise are Windows only API calls, like the System.Windows.Forms namespace

But, i might be wrong about some of the information, i read about it ages ago.

Exactly. Everythying but the GUI (basically Windows compatibility) is open. Guess what happens when Mono starts making inroads.. you guessed it. A quick call to the lawyer and Mono has a load of DMCA problems on their hands.

  • 0
Exactly. Everythying but the GUI (basically Windows compatibility) is open. Guess what happens when Mono starts making inroads.. you guessed it. A quick call to the lawyer and Mono has a load of DMCA problems on their hands.

Copying an API isn't stealing. Copying the implementation is stealing. Besides, Mono is developing Gtk# for Linux windowing and Cocoa# for Mac. Neither of those libraries has anything to do with Win32.

  • 0
What you said earlier about .NET security has little applicability to hackers. Yes, .NET is permission-based so that applications cannot access the system. And yes, .NET uses managed code so that memory is not illegally accessed. But all that does, is stop a .NET application from performing malicious actions. A hacker would probably sidestep all that and attack the code parser or bugs in the other framework libraries (which usually have higher privileges such as System.Reflection). That's how it's been done in the past with other VMs. For example, a malformed file could crash the code parser before it even gets to the JIT compiler or poor programming logic in the libraries could allow privilege escalation. How many times has Microsoft had to patch the Microsoft Java VM because there were security holes? Don't forget that the MSJVM is built with similar concepts to .NET.

Either you didnt read what i said about .NET security or you have a hard time understanding english. .NET is more secure than any other method avalible (maybe Java is as secure im not sure as I'm not a java expert) because the JIT compiler only compiles code after it passes CAS (Code Access Security).

For those reasons you cant use a .NET application to circumvent .NET. I recommend you read up on .NET CAS before you speak on that subject...

Making it easier for users has nothing to do with security. Often it is the case that making things easier is usually a comprimise on security. Should Microsoft bundle every single software in the world to make it easier for users? I never said that the .NET Framework was a "security hole" but having it installed just creates more things for you to patch when updates are released. By the way, I hope you've installed SP1 for the .NET Framework because it patches several vulnerabilities.
It is agreed that less security means more user friendly and its probably not in MS's best intrest to bundle .NET with windows until Longhorn. That way they dont have to worry about supporting .NET on end-users machines until its a core part of the OS. The reason .NET i mentioned its not a bad idea for users to install .NET is because it dosent produce more security holes. The very nature of .NET makes it safer than the Win32 API. The .NET runtime also wouldnt be activated except by .NET appications.
Only a small subset of the .NET Framework is standardized. (I heard that only 10% is standardized but don't quote me on that.) The rest is proprietary and is subject to change or to licensing issues. Microsoft only said that the standardized parts are provided on a royalty-free basis and has said nothing of the non-standardized parts.

Actually all the core parts of .NET is standardized... Did you even look at the standards? i did link you to them in my last post. The C# language is a standard as well as the CLS (Common Language Specification) this means a JIT compiler can be written that can understand MSIL as well as a language that can produce MSIL.

The reason why Mono can run .NET apps so successfully is because Mono choose to implement not only the standardized APIs but also those APIs that are proprietary to MS. e.g., System.Windows.Forms . Mono choose to benefit the greater public by implementing those proprietary APIs so that most applications can be run on both Windows and Linux. FYI, System.Windows.Forms in run on Linux using WINE.

No the reason why Mono runs .NET so successfully is because its based on the MS .NET standards. That ensures they arent "reverse engineering" and getting hit with suprises along the way. Since MSIL is a standard that the Mono developers can build upon they only have to read MS .NET FCL (Framework Class Library) documentaion on how non-open API's should work. They can then code their own API that will do what the MS API would do without needing to "Reverse Engineer".

Maybe you should read the Mono projects FAQ for some enlightment: Mono FAQ: General Mono FAQ: Tecnical

BTW: Do read the linked documents this time...

  • 0
Either you didnt read what i said about .NET security or you have a hard time understanding english. .NET is more secure than any other method avalible (maybe Java is as secure im not sure as I'm not a java expert) because the JIT compiler only compiles code after it passes CAS (Code Access Security).

[snipped]

You = my hero :p

I think the main problem facing .NET is the general feeling that most developers have for Microsoft. A large, unfeeling company who has complete control over your development. Nothing could be further from the truth.

.NET is here to stay. Microsoft has invensted a LARGE amount of time and money into developing a Framework that would work anywhere, from mainframes, to console applications, to web applications.

When VB 6 applications where first released, no one had the runtimes. Truth be told, a ~6MB download for VB6's runtime is slighly less annoying than .NET's 21MB framework, but the surge of broadband should be enough to offset this one-time "annoyance".

.NET allows developers much greater RAD, simply because they spend less time securing their application, which everyone does, and more time writing what they need. Some can argue "I'd rather develop my own security. Who trusts Microsoft?". However, especially for beginning developers, it's much easier to leave your security to a company who's had years to refine (and learn from their mistakes) their security.

.NET was built with security and RAD in mind. My only gripe is that by nature, compiled code isn't secured, as it exists in easily decompilable MSIL. Obfuscation is a simple and easily available alternative.

Reguardless of what other people may think, Microsoft makes some quality products. The next version of Visual Studio is likely to be a huge hit, especially with the inclusion of intensive testing and debugging features.

The problem is, .NET is a (relatively) new developing platform, and one that I feel will grow fast. There are many features the framework provides that secures your application by default.

One last thing, I heard some comments quite a few pages ago stating that if a problem was found in the Framework, all applications would have to be recompiled. Nothing is further from the truth. A simple upgrade to a newer framework, and all the old applications will still work as advertised, without the security holes.

  • 0
You = my hero :p

I think the main problem facing .NET is the general feeling that most developers have for Microsoft. A large, unfeeling company who has complete control over your development. Nothing could be further from the truth.

[truncated - original post above]

Thanks for the comment :cool:

I'm glad to see someone in this topic have a brain as it started to seem like no one here could read (which is a 2 part process, reading the words and comprehending what you have read). Thanks for the much needed eye opener :D...

Very good post as well as i agree with your points as will anyone who is actually knowledgable in .NET.

  • 0
One last thing, I heard some comments quite a few pages ago stating that if a problem was found in the Framework, all applications would have to be recompiled. Nothing is further from the truth. A simple upgrade to a newer framework, and all the old applications will still work as advertised, without the security holes.

Yeah, that's why 1.1 -> 1.1 SP1 broke my program without my doing anything.

I've done my part trying to back you up frazell (ex pg. 4) but it seems that logical arguments are beyond his ability to comprehend so it's not worth trying. It's like trying to convert a diehard political zealot (guess which camp it is to which I'm referring); they just don't want to hear anything that disagrees with their beliefs, however ignorant (I've yet to hear any arguments as to why exactly Kerry would be worse at protecting the country; after all, under which administration did the terrorist attacks occur in the first place? But I have no intention of starting a futile political "debate" (read: degenerative flamefest) here).

  • 0
Yeah, that's why 1.1 -> 1.1 SP1 broke my program without my doing anything.

I've done my part trying to back you up frazell (ex pg. 4) but it seems that logical arguments are beyond his ability to comprehend so it's not worth trying. It's like trying to convert a diehard political zealot (guess which camp it is to which I'm referring); they just don't want to hear anything that disagrees with their beliefs, however ignorant (I've yet to hear any arguments as to why exactly Kerry would be worse at protecting the country; after all, under which administration did the terrorist attacks occur in the first place? But I have no intention of starting a futile political "debate" (read: degenerative flamefest) here).

I assume you weren't being sarcastic :p

BTW: On your WeatherAlert thread (very nice program BTW), you should mention that the .NET framework automatically allocated more memeory than it needs for security / performance reasons. If your computer needs this memory, it frees it up. The fact that it's using 30MB of memory means that you don't need it, and shouldn't complain :p

  • 0
A simple upgrade to a newer framework, and all the old applications will still work as advertised, without the security holes.

Yeah, that's why 1.1 -> 1.1 SP1 broke my program without my doing anything.

I've done my part trying to back you up frazell (ex pg. 4) but it seems that logical arguments are beyond his ability to comprehend so it's not worth trying. It's like trying to convert a diehard political zealot (guess which camp it is to which I'm referring); they just don't want to hear anything that disagrees with their beliefs, however ignorant (I've yet to hear any arguments as to why exactly Kerry would be worse at protecting the country; after all, under which administration did the terrorist attacks occur in the first place? But I have no intention of starting a futile political "debate" (read: degenerative flamefest) here).

Well, for one thing, your program is not "broken;" ie it still functions. There's a UI bug in the Framework that now affects your program. That's partly your own fault. SP1 was available as a public beta for some time, and you SHOULD have taken the time to test your program with the new bits then so that you could have reported any bugs you found and maybe gotten them fixed before the SP shipped. Instead, you just assumed that everything would work flawlessly through the upgrade and didn't even give the .NET 1.1SP1 scenario a cursory test.

What the poster you quoted said is completely relevant. If Microsoft released a fix for the Framework that fixed your groupbox problem, you wouldn't need to recompile your application to take advantage of that fix.

Although I might agree with your opinion on your presidential election, I don't see how that's really relevant to a discussion about the .NET Framework.

  • 0
Exactly. Everythying but the GUI (basically Windows compatibility) is open. Guess what happens when Mono starts making inroads.. you guessed it. A quick call to the lawyer and Mono has a load of DMCA problems on their hands.

Say you wrote a API set, now i come along and make a implementation of it for Linux or whatever, I'm am not copying anything off you, i am only exposing my code in the same way i you do, if i decompiled your API's and wrote mine off your's, that would be a DCMA thing.

When the mono project implemented the System.Windows.Forms namespace, they didn't decompile the System.Windows.Forms.dll assembly, they wrote their own wrapper based around wine, exposing their own code callable in the same way that ms wrote their's, that why ms don't care, they are not copying there work in any way, just the way you call it.

  • 0

(From the WeatherAlert thread)

I know it does up a lot of memory when it's not minimized  ; that's just how the framework works. C# was easy enough to pick up, but muddling through full-fledged C++ for something like this is sorta overkill (but I may end up doing it anyway ). But I think of it this way: when you're looking at the full weather information, it's probably not going to be when you're in the middle of playing a game or things like that; you'll have it minimized when you're doing intensive stuff, and when it's minimized it takes up very little memory. That and the fact that I have ample RAM. I guess. *shrug*

Um, you're making it into a problem. If you were t be running it with Doom III in the background, it would take VERY VERY little RAM, not the ~15MB that it uses when no other applications are running. A lot people aren't going to like the application just for that reason.

  • 0
Either you didnt read what i said about .NET security or you have a hard time understanding english. .NET is more secure than any other method avalible (maybe Java is as secure im not sure as I'm not a java expert) because the JIT compiler only compiles code after it passes CAS (Code Access Security).

For those reasons you cant use a .NET application to circumvent .NET. I recommend you read up on .NET CAS before you speak on that subject...

I beg your pardon of my ineptitude in English.

In thinking about security, it is necessary to think outside the box. Basking in its supported features does not help in analyzing its unknown deficiencies. The .NET Framework is a huge thing and statistically speaking, it is inevitable that programming errors will be found. They do not necessarily need to be errors where rogue code is executed. It can be errors where checks are improperly checked. The question is whether the .NET Runtime and it's interaction with the OS can contain those errors from being exploited. For example, here's a typical route for a .NET application.

1) The .NET Runtime or the web browser makes a call to an HTTP server to download some .NET code. At this stage, an attacker can exploit bugs (if exists) in the .NET Libraries or the web browser to falsify its originating domain in order to gain higher privileges. For example, the attacker could use cross-site script injection exploits to inject code into the site on another domain. The attacker could also use malformed HTTP headers to falsify the domain.

2) The parser checks that the downloaded file conforms to the IL specification. The parser also checks for code signatures, domains, and other forms of evidence. At this stage, an attacker could exploit bugs (if exists) that allow it to bypass those checks. Signatures are difficult to exploit except perhaps with buffer overflows. .NET supports a XML based signature system which opens it up to XML parser attacks. Domain information can be falsified as in the preceding stage.

3) Then the parser checks that the libraries referenced in the code exist and if necessary, downloads those additional libraries. It also checks for permission to use those libraries. At this stage, an attacker could exploit bugs (if exists) to bypass permission checking. For example, a recent bug in Sun's Java VM allowed code to be initialized in a reserved namespace (java.*) because the classloader forgot to check for slashes in the namespace.

As you can see, even before the code gets loaded into it's managed environment, there are plenty of areas where it is still exploitable. The exploitation may even involve deceiving the CAS.

It is agreed that less security means more user friendly and its probably not in MS's best intrest to bundle .NET with windows until Longhorn. That way they dont have to worry about supporting .NET on end-users machines until its a core part of the OS. The reason .NET i mentioned its not a bad idea for users to install .NET is because it dosent produce more security holes. The very nature of .NET makes it safer than the Win32 API. The .NET runtime also wouldnt be activated except by .NET appications.
That assumes that typical users use enough .NET applications that warrant its existence on the OS.
Actually all the core parts of .NET is standardized... Did you even look at the standards? i did link you to them in my last post. The C# language is a standard as well as the CLS (Common Language Specification) this means a JIT compiler can be written that can understand MSIL as well as a language that can produce MSIL.

Could you point out to me where the System.Windows.Forms namespace is standardized in the ECMA links you sent me. I myself could not find them there. If they are not there but are present in .NET Framework then that implies that not all parts of the Framework are standardized.

No the reason why Mono runs .NET so successfully is because its based on the MS .NET standards. That ensures they arent "reverse engineering" and getting hit with suprises along the way. Since MSIL is a standard that the Mono developers can build upon they only have to read MS .NET FCL (Framework Class Library) documentaion on how non-open API's should work. They can then code their own API that will do what the MS API would do without needing to "Reverse Engineer".
That's fine but I'm arguing that the Microsoft .NET Standards are not the same as the ECMA C#/CLR standards. I'm arguing that Microsoft's Standards are a combination of open standards and proprietary standards. Sure, if Mono followed Microsoft's .NET Standards then they will gain complete interoperability. But if they only followed the ECMA standards, they will not be completely interoperable.

Take, for example, this quote from MSDN:

The System.Windows.Forms namespace contains classes for creating Windows-based applications that take full advantage of the rich user interface features available in the Microsoft Windows operating system.

If it takes full advantage of the rich user interface, then by nature that API will contain code that will only work on Windows (or WINE).

  • 0
Could you point out to me where the System.Windows.Forms namespace is standardized in the ECMA links you sent me. I myself could not find them there. If they are not there but are present in .NET Framework then that implies that not all parts of the Framework are standardized.

That's fine but I'm arguing that the Microsoft .NET Standards are not the same as the ECMA C#/CLR standards. I'm arguing that Microsoft's Standards are a combination of open standards and proprietary standards. Sure, if Mono followed Microsoft's .NET Standards then they will gain complete interoperability. But if they only followed the ECMA standards, they will not be completely interoperable.

I think your confusing the managed api's with the framework, the framework is a system for running and building managed applications, the api's are a different section, the api's don't have to be standardised, because they are in essence a separate section, but ms wont change the layout because if they did, all .net apps would have to be recompiled, and if you notice, ms are good on backwards compatibility (how do you explain the Win16 api's and vm being in longhorn, ms are still supporting use of it) that's why mono will work, ms wont change the api layout, so mono can implement it.

http://msdn.microsoft.com/net/ecma/

Also, i don't get the section your saying about the ms standards and the ecma standards being different , they are the same thing, ecma didn't come up with them, microsoft did.

  • 0

This seemed to have some relevance to at least one side of this ridiculous debate. http://www.eetimes.com/sys/news/showArticl...icleId=47205205

specifically this idea

If programmers are not prepared to widen their horizons to avoid losing jobs to outsourcing, they should consider another line of work
  • 0

Good point

What was the line, those who refuse to evolve will become extinct

.NET is the future, if you spend all your time saying you wont upgrade to it, you will get left behind without experience in it.

I recommend a mod close this thread, it's gone off-topic and most of it isn't even making sense now.

Edited by The_Decryptor
  • 0
I think your confusing the managed api's with the framework, the framework is a system for running and building managed applications, the api's are a different section, the api's don't have to be standardised, because they are in essence a separate section, but ms wont change the layout because if they did, all .net apps would have to be recompiled, and if you notice, ms are good on backwards compatibility (how do you explain the Win16 api's and vm being in longhorn, ms are still supporting use of it) that's why mono will work, ms wont change the api layout, so mono can implement it.

http://msdn.microsoft.com/net/ecma/

Also, i don't get the section your saying about the ms standards and the ecma standards being different , they are the same thing, ecma didn't come up with them, microsoft did.

Here's a quote from the .NET Framework website:

The .NET Framework is composed of the common language runtime and a unified set of class libraries.

And it makes sense from an object orientated perspective because all classes must be derived from a base class and that base class is a member of some library. Even the simplest "Hello world" application will have to use classes from a library (for IOs and Strings). ECMA-334 and ECMA-335 defines those things and Microsoft's .NET Framework implements them. I'm arguing that Microsoft's .NET Framework implements more then those things but also their own proprietary set of libraries which are not standardized with the ECMA. People who then write .NET Applications using Microsoft's set of libraries (de facto standards) will not be compatible with one that implements only the ECMA defined libraries (de jure standards).

  • 0
And it makes sense from an object orientated perspective because all classes must be derived from a base class and that base class is a member of some library. Even the simplest "Hello world" application will have to use classes from a library (for IOs and Strings). ECMA-334 and ECMA-335 defines those things and Microsoft's .NET Framework implements them. I'm arguing that Microsoft's .NET Framework implements more then those things but also their own proprietary set of libraries which are not standardized with the ECMA. People who then write .NET Applications using Microsoft's set of libraries (de facto standards) will not be compatible with one that implements only the ECMA defined libraries (de jure standards).

That would be true if they used Windows Forms currently. I may be wrong, but Mono is trying to keep same API, but have GTK and Cocoa be the underlying technologies.

A quote from the Mono site:

Question 5: Will you implement the .NET Framework SDK class libraries?

Yes, we will be implementing the APIs of the .NET Framework SDK class libraries.

Question 6: Will you offer an ECMA-compliant set of class libraries?

Eventually we will. Our current focus is on inter-operating with the Microsoft SDK, but we will also offer an ECMA compliant subset of the libraries.

Smart, if you ask me. Can MS touch them? Only if they find they're stealing code. An API is a public set of interfaces to program against, key word being interfaces. How those interfaces are implemented(if someone stole MS's implementation) is the only thing MS can go after someone on, otherwise, they'd be killing WINE. This is where DMCA is really going to be tested. Reverse engineering has always been how our technology has evolved. Some companies are trying to use the DMCA to change that.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • State of Decay 2, Blasphemous 2, and more join Xbox Free Play Days by Pulasthi Ariyasinghe The latest Free Play Days offer has just kicked off, giving Xbox players the chance to try out a new selection of games over the weekend. The offerings this time aren't as massive as last weekend, but there are still major releases for Xbox players to jump into. This includes Undead Labs' post-apocalyptic title State of Decay 2, as well as two Team17-published titles. Two of the games being offered this time are available to all Xbox players without needing any kind of Game Pass subscription. In the fully free-to-play section, you can jump into State of Decay 2. The title is both an action survival title and a community builder, letting players choose a map, set up their base, and try to keep the growing zombie threat at bay. Cooperative play is available too. Don't forget that the studio is preparing a third entry for 2027. Next, Blasphemous 2 drops in for Metroidvania and Soulslike fans, where The Penitent One returns for another adventure. The title has tough combat with multiple weapon options, deadly traps to avoid, and platforming sequences requiring a lot of patience and timing. Keep in mind though that the offer does have a 5-hour time limit attached to it. Lastly, Xbox Game Pass Ultimate, Premium, and Essential members can now try out the WWII-set first-person shooter Hell Let Loose. The multiplayer game offers 50 vs 50 combat in massive maps, with infantry, tank, and artillery options available for players. Here are the announced games and the platforms they are available to play on: Hell Let Loose (Xbox Series X|S, PC) State of Decay 2: Juggernaut Edition (Xbox Series X|S, PC) Blasphemous 2 (Xbox Series X|S, Xbox One) To easily find the titles on Xbox consoles, first head to the Store, and then in the sidebar, find the Home section. In there, open the Subscriptions tab. The Free Play Days collection will show up in this area. This week's Free Play Days promotions will end on Sunday, June 11, at 11:59 pm PT.
    • Can we not have paperless office, like we was promised in the 80's
    • I actually laughed out loud in real life at the heading on this—whatever Microsoft is drinking, I want some of it.
    • Euro-Office must default to ODF to be considered "genuinely European", LibreOffice argues by David Uzondu Euro-Office is a web-based collaborative office suite that positions itself as a "European sovereign alternative" to American tech companies, backed by a coalition of developers including Nextcloud, IONOS, Abilian, BTactic, OpenProject, and, more recently, Tuta. The project officially went live a couple of days ago, but not before drawing heavy fire from LibreOffice developers, who called the marketing claim that Euro-Office represents the "first open-source office suite developed in Europe" a deceptive historical inaccuracy because projects like OpenOffice and LibreOffice existed decades earlier. Now that the project has launched, LibreOffice is back with another complaint, arguing that Euro-Office cannot consider itself "genuinely European" while it pushes proprietary Microsoft defaults on users. Euro-Office had promised to improve the OpenDocument Format (ODF) back in April, but the current release still plagues users with several technical failures. For instance, the suite lacks an admin setting to enforce ODF, and mobile editors completely block ODF saves, forcing files into Microsoft's OOXML formats. Some configurations force files into read-only mode, while editing frequently corrupts document formatting or erases data. LibreOffice thinks that merely supporting a format as an afterthought does not make you a sovereign alternative, as file formats are the battleground where" digital sovereignty is won or lost." The road to the first stable release of Euro-Office has been quite bumpy due to an aggressive public fallout with OnlyOffice, from which the coalition originally forked the project. OnlyOffice struck back by accusing the coalition of violating copyright terms under its AGPLv3 branding requirements by stripping the original branding anyway and forking the code. Getting Euro-Office up and running is a bit wonky (at least for non-technical users), as there is no direct installer to grab off the web. The easiest way we learnt is by using Docker. First, pull the official Euro-Office image from the GitHub Container Registry: docker pull ghcr.io/euro-office/documentserver:latest Then, run the container with active ports and a secure JWT token, enabling the test environment: docker run -i -t -d -p 8080:80 --restart=always -e EXAMPLE_ENABLED=true -e JWT_SECRET=my_secure_jwt_secret ghcr.io/euro-office/documentserver:latest And finally, open a web browser and go to the following address: http://localhost:8080 If you are running this on a remote server, replace localhost with your server's IP address. You will see the Euro-Office test page, where you can create new text documents, spreadsheets, or presentations directly in the browser. Image via Euro-Office Nextcloud promises that proper standalone desktop versions and mobile apps will arrive in a future release.
  • Recent Achievements

    • Week One Done
      FBSPL earned a badge
      Week One Done
    • One Year In
      Jim Dugan earned a badge
      One Year In
    • One Month Later
      Tommi118 earned a badge
      One Month Later
    • One Month Later
      sjbousquet earned a badge
      One Month Later
    • Week One Done
      sjbousquet earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      486
    2. 2
      PsYcHoKiLLa
      197
    3. 3
      +Edouard
      155
    4. 4
      Steven P.
      83
    5. 5
      ATLien_0
      69
  • Tell a friend

    Love Neowin? Tell a friend!