General Development Archive

Honestly, I don't think the Atari 2600 BASIC has ever had a fair review. It's pretty much reviled as a horrible program, a horrible programming environment and practically useless. But I think that's selling it short. Yes, it's bad (and I'll get to that in a bit), but in using it for the past few days, there are some impressive features on a system where the RAM can't hold a full Tweet and half the CPU time is spent Racing The Beam. I'll get the bad out of the way first.

Input comes from the Atari Keypads, dual 12-button keypads. If that weren't bad enough, I'm using my keyboard as an emulated pair of Atari Keypads, where I have to keep this image open at all times.

Okay, here's how this works.

• Direct3D 10 and 11 support.
• The Direct3D command stream.
• The Android graphics driver.
• Improved DirectWrite and Direct2D support.

Swift 4 is now officially released! Swift 4 builds on the strengths of Swift 3, delivering greater robustness and stability, providing source code compatibility with Swift 3, making improvements to the standard library, and adding features like archival and serialization.

You can watch a quick overview of it by watching the WWDC 2017: What's New in Swift presentation, and try out some of the new features in this playground put together by Ole Begemann.

Later this year, on November 21, 2017, D-Bus will see its 15th birthday. An impressive age, only shy of the KDE and GNOME projects, whose collaboration inspired the creation of this independent IPC system. While still relied upon by the most recent KDE and GNOME releases, D-Bus is not free of criticism. Despite its age and mighty advocates, it never gained traction outside of its origins. On the contrary, it has long been criticized as bloated, over-engineered, and orphaned. Though, when looking into those claims, you’re often left with unsubstantiated ranting about the environment D-Bus is used in. If you rather want a glimpse into the deeper issues, the best place to look is the D-Bus bug-tracker, including the assessments of the D-Bus developers themselves. The bugs range from uncontrolled memory usage, over silent dropping of messages, to dead-locks by design, unsolved for up to 7 years. Looking closer, most of them simply cannot be solved without breaking guarantees long given by dbus-daemon(1), the reference implementation. Hence, workarounds have been put in place to keep them under control.

Nevertheless, these issues still bugged us! Which is, why we rethought some of the fundamental concepts behind the shared Message Buses defined by the D-Bus Specification. We developed a new architecture that is designed particularly for the use-cases of modern D-Bus, and it allows us to solve several long standing issues with dbus-daemon(1). With this in mind, we set out to implement an alternative D-Bus Message Bus. Half a year later, we hereby announce the dbus-broker project!

Cooper Harasyn found a Super Mario World save corruption glitch, and we worked together to create a jailbreak that works on real, unmodified cartridges and Super Nintendos.

An SBX container is composed of a collections of blocks with size submultiple/equal to that of a sector, so they can survive any level of fragmentation. Each block has a minimal header that includes a unique file identifier, block sequence number, checksum, version. Additionally, non-critical info/metadata are contained in block 0 (like name, file size, crypto-hash, other attributes, etc.).

If disaster strikes, recovery can be performed simply by scanning a volume/image, reading sector-sized slices and checking block signatures and then CRCs to detect valid SBX blocks. Then the blocks can be grouped by UIDs, sorted by sequence number and reassembled to form the original SeqBox containers.

Modern computer science is dominated by men. But it hasn't always been this way.

A lot of computing pioneers - the people who programmed the first digital computers - were women. And for decades, the number of women studying computer science was growing faster than the number of men. But in 1984, something changed. The percentage of women in computer science flattened, and then plunged, even as the share of women in other technical and professional fields kept rising.

What happened?

This release is the result of the community's work over the past six months, including: use of profile data in ThinLTO, more aggressive dead code elimination, experimental support for coroutines, experimental AVR target, better GNU ld compatibility and significant performance improvements in LLD, as well as improved optimizations, many bug fixes and more.

In this article we'll walk through an example of how to interpret a closed source program, how to analyze its behavior, and how to ultimately alter that behavior to do what we want. These techniques are well known within many circles, but few tutorials exist to help people get started. The context for this example investigation is the linker's subsystem field generation, but the techniques can be applied to other problems that seem interesting.

The POSIX standard for APIs was developed over 25 years ago. We explored how applications in Android, OS X, and Ubuntu Linux use these interfaces today and found that weaknesses or deficiencies in POSIX have led to divergence in how modern applications use the POSIX APIs. In this article, we present our analysis of over a million applications and show how developers have created workarounds to shortcut POSIX and implement functionality missing from POSIX.

This release represents over a year of development effort and around 6,600 individual changes. The main highlights are the support for Microsoft Office 2013, and the 64-bit support on macOS.

It also contains a lot of improvements across the board, as well as support for many new applications and games. See the release notes below for a summary of the major changes.

Software is the umbrella term for computer programs and libraries, the coded logic that makes our machines tick. At the root of all software is the code, the instructions that enable a human to tell a machine what to do. This code is written in one of the hundreds of different programming languages - such as C, Java, or Python - each of which has its own eccentricities and context-dependent advantages.

Yet regardless of the programming language being used, the functionality, logic, and efficiency of the language are always paramount - unless, of course, you're talking about Brainfuck, an esoteric programming language that champions purposefully overcomplicated code.

This text is a practical guide to writing your own x86 operating system. It is designed to give enough help with the technical details while at the same time not reveal too much with samples and code excerpts. We've tried to collect parts of the vast (and often excellent) expanse of material and tutorials available, on the web and otherwise, and add our own insights into the problems we encountered and struggled with.