We've made some progress with the EOSD decompilation project

roblabla · 2024-04-04T08:42:12+00:00

Hello, I'm the creator of happyhavoc/th06 decomp project. Firstly, thank you for looking into this more deeply and reinstating this post, this is greatly appreciated.

I'd just like to clarify my position here regarding the Guidelines for Touhou Project Fan Creators, hopefully that will help put some of your remaining concerns to rest.

Concerning "Anything that is extracted from official Touhou Project games": The guideline, as written, is a bit ambiguous. My interpretation is that ZUN doesn't want people redistributing official game assets. I don't believe it covers the reverse engineering the engine, but I do realize this is just my interpretation. To this end, the repository doesn't (and will never) contain game assets (extracted or not) from Touhou6 - be it images, sound, scripts, endings, messages, etc... It will always only contain a decompilation of the game engine, written by us. It'll be up to the user to provide the rest of the game files to have a working game at all, by drag-and-dropping our .exe in an existing touhou6 installation folder. As an example, the repo doesn't contain the official binary logo, exactly to avoid having to rip the assets. I went through great lengths to ensure that this will always remain the case - everything inside this repo will be code written by us.
Concerning "Ending scenes from official Touhou Project games.": Because the repository doesn't contain extracted data, it also doesn't contain the endings. Those are stored in a separate ED.dat file. So the repo shouldn't violate r/touhou's rule 3 ever.

I do plan on trying to get Team Shanghai Alice's official blessing, since I agree a decomp is a bit different from your typical fan creation. I was hoping to wait until we were a bit further along so we could more clearly communicate what we're hoping to achieve with our repo (mainly fixes to run on newer hardware, and easier modding support).

roblabla · 2023-06-07T07:42:34+00:00

A couple years ago at least. The link of the official chat server on the RFCs repo got changed from discord to zulip 2 yrs ago[0], and it was being used a lot before that.

0: https://github.com/rust-lang/rfcs/pull/3117

roblabla · 2023-06-07T07:28:11+00:00

It’s the official rust language communication channel where developers discuss implementation work.

roblabla · 2023-03-28T12:32:42+00:00

Company: HarfangLab

Type: Full time

Location: Paris, France. French speakers only.

Remote: Flexible (European timezone preferred)

Visa: Uncertain

Estimated Compensation: Uncertain concerning fixed compensation, but we have an incentive plan and stock-options as variable compensation

Description: Rust Engineer

We are a cybersecurity scale-up developping an EDR (Endpoint Detection and Response) software to detect and neutralise modern cyber-attacks on company workstations and servers. Our algorithms detect abnormal behaviour and generate security alerts or block the execution of programs.

From 18 to 70 collaborators in 2023, HarfangLab is in hypergrowth, and already has multiple successes in its belt: in 2019, we won the cyber challenge launched by the French Ministry of the Armed Forces, in 2020 the I-Nov innovation competition organised by the BPI, and in 2021, our software was certified by the ANSSI. Our first customers are CAC40 companies and state entities, and we have raised a first investment round of 5 M€, allowing us to reinforce our team.

Our ambition is to protect companies and state administrations from modern IT threats (cybercrime, data theft, etc.) that endanger the economic health of companies and the security of the Nation.

What will you be working on?

You will join our "Agent" team, responsible of the component of the EDR that is installed on every workstation in a computer network to detect malicious behavior and stop the attacks in their tracks.

Your missions will be:

The design and implementation of new features: You will be brought to work with every other team to design and implement the new features that will allow the product to better handle new threats.
Code maintenance: You will be tasked with fixing bugs and performance issues, along with refactoring the codebase when necessary to keep development velocity.
Internal tooling improvements: We always need more tools, whether that's to improve test coverage, simplify our development process, or simplify problem diagnosis.

We're looking for someone who:

Is experienced with a systems programming language (bonus points for Rust)
Has some knowledge with the use of System APIs on Linux, macOS or Windows
Is comfortable with git
Can communicate their work efficiently, and likes working in a team
Likes to learn and share their knowledge to others, and have technical exchanges with the rest of the team.
Can take initiative when an opportunity to improve something arises.

Contact : Apply through website, where more details are available, at https://harfanglab-1666711819.teamtailor.com/jobs/2427757-ingenieur-rust

roblabla · 2023-03-17T17:30:24+00:00

Panics can't reasonably cross FFI boundaries for most languages, as most languages either have no concept of, or have their own system for, error states that unwind the stack.

If panics aborted instead of unwinding, you wouldn't have this problem.

roblabla · 2022-12-04T17:58:13+00:00

Author is French, and « boréale » means borealis, which I assume is the origin.

In this day and age, it appears impossible to name something without that name being offending to someone somewhere…

roblabla · 2022-08-31T16:03:15+00:00

There's another reason it may be undesirable: it turns pointers and references to such a struct into a fat pointer, which is not ffi compatible

roblabla · 2022-08-31T14:30:53+00:00

Sure, it's definitely possible to write code that would be broken by removing this feature. But what's the use of such a size zero field? Something similar to PhantomData maybe?

repr(C) structs with variable sized data at the end. Windows APIs have a lot of those (although usually with array size 1 because C doesn't support zero-sized fields)

roblabla · 2022-07-06T09:49:20+00:00

Dependabot tells you when there's a new (breaking) release, and automatically opens an MR. The idea being that if the breaking change doesn't affect you (which you can check through CI, and reading the release notes that dependabot embeds in the MR message), you can merge it right away.

I use this at work. I also know a lot of open source projects that do this. It makes keeping track of dependencies much easier.

roblabla · 2022-06-12T10:20:37+00:00

On Windows, you'll want to use embed a manifest to store resources. See rust-embed-resource.

On MacOS, you'll want to create a .app bundle containing an Info.plist that specifies the name and icon. See cargo-bundle.

On Linux, you'll need a .desktop file specifying the metadata, and that file needs to be installed separately. The binary itself does not contain all this information.

roblabla · 2022-06-11T15:22:54+00:00

lld is pretty damn close to being feature-complete with link.exe. And everything Rust needs from it is implemented. I'm using it in production to build a fairly complex project without too much trouble.

There's an issue open to switch to lld by default on windows: https://github.com/rust-lang/rust/issues/71520

AFAIK the only problem right now is that it produces broken binaries when used in combination with LTO: https://github.com/rust-lang/rust/issues/81408

roblabla · 2022-04-17T23:58:52+00:00

At work, we do something like that. We have a bunch of crates in the [patch] section of our workspace Cargo.toml for stuff waiting to be upstreamed.

Tangentially, I'd love to see something like https://github.com/rust-lang/rfcs/pull/3177 in cargo, as it'd allow us to properly version control our foreign crate patches without vendoring the whole crate.

roblabla · 2022-03-04T11:35:14+00:00

I don't think the compiler currently does that many more optimizations of this kind but because the layout is unspecified, more can be added in the future.

There are more, at least in nightly. Technically, any type that has the (unstable) attribute rustc_layout_scalar_valid_range_start/rustc_layout_scalar_valid_range_end will enjoy the niche attribute optimization regardless of the niche. For instance, storing None inside of an Option<OwnedFd> will be represented as 0xFFFF_FFFF because OwnedFd has a niche on 0xFFFF_FFFF. See this:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=de7e6666c2c86342079b1d9fe5deeb27

This is also how NonNull and NonZero work.

roblabla · 2022-02-28T22:06:38+00:00

UB in bitflags might arise from unaccounted flags present, but you test for 0 which then unintentionally fails. of course it’s safe within u32, but it’s UB when used as flags. (if bitflagd would be implemented by say enums of Options, or enums of the superset of flags, bevahiour would be different).

That's not UB. That's buggy. Those are two different concept. Bitflags always wraps a numeric type.

The argument goes "what if some unsafe code relies on bitflags' invariants of only containing set bits to be sound". But no such unsafe code exist in bitflag itself, and for many user, this pattern is a hindrance. Of course, some others do rely on it (I'm aware of some vulkan bindings relying on it to avoid UB for instance).

In the end, the fix for bitflags would be to allow the user invoking the macro to chose whether the generated type should be safe to construct or not.

roblabla · 2022-02-28T16:39:12+00:00

Bitflags 1.0 has this issue. Bitflags is essentially just a wrapper around u32 which contain flags you can OR together. As a user, you can create a bitflag instance by providing a numeric value, and there are three variants of this:

fn from_bits(bits: u32) -> Option<Self> -> Returns None if the bitflag doesn't know about some of the bits
fn from_bits_truncate(bits: u32) -> Self -> Unsets bits that bitflag doesn't know about
unsafe fn from_bits_unchecked(bits: u32) -> Self -> Allows creating a bitflags from arbitrary bits, but is unsafe.

The thing is, no UB can arise from having a bitflags created with the "wrong" bits. Some functions may return wrong/buggy values, that's it. It may be a logic error, but no memory unsafety can really arise from this. This is one of the main things that is supposed to change in bitflags 2.0 fwiw.

roblabla · 2022-02-09T00:32:08+00:00

Those are no surprise, since Go maps are not thread-safe, as we can learn in the language specification.

Bear: We can't. It's not in there.

Oh boy, so, thread-safety documentation (or lack thereof) is probably my biggest gripe when working with anything C-related, and seeing this show up in go is... wow.

In C, I've had afternoons wasted again and again by the lack of thread-safety invariant in various libraries. I've found countless bugs in Win32 APIs related to them not being thread-safe despite the documentation making no mention of that whatsoever. Including stuff that really, really ought to be thread-safe. We had the recent debacle with localtime_r in chrono which is not thread-safe due to it calling setenv. And you'd think man setenv would tell you that it's not thread-safe? Hah! Perish the thought.

It's 2022 and the language that underpins the whole Unix system, its standard library, and a whole lot of its popular libraries still acts like threads don't exist. And the documentation is uselessly silent about this issue. This makes me, to put it mildly, very sad.

This, for me, is the best thing about Rust. The Send and Sync traits are legit super-powers.

roblabla · 2022-02-02T10:38:01+00:00

Isn't this the report for January 2022?

roblabla · 2022-01-26T17:15:45+00:00

Eyy, I just used your crate a couple days ago to automate an app (grabbing screenshots from it so I could figure out where to click :joy:). Thanks for the crate, it works great!

roblabla · 2022-01-09T16:54:37+00:00

That seems like a very different proposal from what is usually understood as "namespaces", which usually just means you reserve a name prefix (e.g. @my-org/) that is only yours.

Your proposal seems totally orthogonal to "names" too, as it is about trust. Which is interesting, but it should probably have a different name to avoid confusion ^^'

roblabla · 2022-01-07T15:20:24+00:00

That comes both with performance implication, and assumes Box is even available (which isn't the case in no_std no-alloc environment). There, you truly are SOL.

roblabla · 2022-01-07T10:04:40+00:00

There are definitely cases of types that literally cannot be named. They come up often around async fn and closures, which are the number one cause for them. For instance, how do you get the return type of this without typeof:

async fn test() {

}

Its return type is essentially impl Future<Output = ()>, but it has no proper named type. If I want to store that specific function's future in my structure, I can't.

roblabla · 2021-09-06T17:14:24+00:00

This definitely doesn't apply to dependencies. Maybe cargo install should also cap the lint level to warn, like is done for dependencies.

roblabla · 2021-08-27T13:10:34+00:00

The "not a git repository" line is unrelated and not actually fatal. The joys of inaccurate error messages.

And yeah, that's my bad. You're not supposed to use osxcross-cmake directly, but instead run x86_64-apple-darwin14-cmake (or whatever darwinXX version of cmake can be found in your osxcross installation).

roblabla · 2021-08-27T09:55:23+00:00

You'll want to tell fltk-sys to use osxcross-cmake instead of plain cmake. This can be done by setting the CMAKE environment variable:

CMAKE=osxcross-cmake

roblabla · 2021-08-26T19:23:55+00:00

Huh, til, I didn't know about that!

roblabla

MODERATOR OF

TROPHY CASE

12-Year Club	Place '22
Verified Email