UCS-2/UTF-16 decoding in PHP


  • Discourse touched me in a no-no place

    @FrostCat said:

    Actually in the specific case I'm thinking of--this is 1998 or a bit earlier--the users were using unreliable dialup at remote sites; the vendor shipped updates via floppy, which installed the package of controls, as this was deemed a better method than code download in their circumstances.

    Updating wasn't moved online for most users until later. All the ActiveX stuff started out as being a large part of how MSN was delivered. I think. I didn't use IE even back then.


  • Discourse touched me in a no-no place

    @dkf said:

    Alas no. It's run by clever idiots.

    Ah - so it's run by oxymorons?



  • @dkf said:

    And the logical technology required for it supported delivery of UI that way.

    Let's imagine a browser vendor other than Microsoft was presented with this proposal:

    How about you add a feature to your browser that uses the Windows COM API to load a foreign control and give it control of part of the browser window. Everything it does will be done in the identity of your process and there will be no enforcement of any limitations on what the control can do other than the limit of the user's permissions. Don't worry, we'll add a field where the control author can specify if it's evil or not.


  • Discourse touched me in a no-no place

    @dkf said:

    Updating wasn't moved online for most users until later.

    I'm pretty sure ActiveX supported code download right from the beginning ('96 or so, when "ActiveX" became a thing, as opposed to "OLE Controls", even though they're (more or less) the same thing.)


  • Discourse touched me in a no-no place

    @Jaime said:

    How about you add a feature to your browser that uses the Windows COM API to load a foreign control and give it control of part of the browser window.

    Uh, didn't Netscape's npapi do the same thing (except it didn't use COM, obviously?)



  • @FrostCat said:

    Uh, didn't Netscape's npapi do the same thing (except it didn't use COM, obviously?)

    With Netscape's model, the owner of the browser decides what plugins are loaded. With the ActiveX model, the markup decides what gets loaded. Big difference there.


  • Discourse touched me in a no-no place

    @Jaime said:

    With the ActiveX model, the markup decides what gets loaded.

    Last I checked you have to OK an ActiveX control, too.



  • Last time you checked was ninteen years after it was first implemented. That feature hasn't been there for a very long time.

    Also, yes/no authorization for an object that you didn't load isn't all that good of a model. At least if I'm installing a plugin, I can make sure I get it from a reliable source and read about it before hand. With the ActiveX prompt, it just comes up unexpectedly and if I say "no" the site I tried to go to doesn't work. This leads to 99% of people either always saying "yes" or always saying "no". Very few people make an informed desicion in that dialog.



  • @blakeyrat said:

    Yup. The W3C is fucking awful at their job.

    I knew the CDDB used a shitty nonsense format, but this is the first time I've heard someone talk about the shitty nonsense in EXIF. It doesn't surprise me though.

    EXIF isn't entirely terrible as a thing, and some of the weirdness is legacy they can't shift, like the endianness because it's built into the format in general.

    I think it's useful in some cases, e.g. I know photography clubs discuss the settings used and it's kind of neat in those cases, but as a general thing for most people it's a non-issue beyond what model of phone 'takes the best pictures' (because obviously the photographer has nothing to do with it'

    I do like how orientation is actually stored, but really surprised how little software actually gives a shit to rotate it properly.



  • Useful and terrible aren't mutually exclusive.



  • @Arantor said:

    I do like how orientation is actually stored, but really surprised how little software actually gives a shit to rotate it properly.

    I don't. Because I know my camera writes utter garbage there (and suspect it would be rather common at least among the low and mid-range ones). When previewing photos on the camera's display it tries to rotate them, but rotates different ones than it should. So I don't mind the computer software does not respect it since I would have to rotate the photos manually anyway.


  • Banned

    @Arantor said:

    I do like how orientation is actually stored, but really surprised how little software actually gives a shit to rotate it properly.

    My Lumia does rotate appropriately. And I hate it. I mean, on a PC it does make sense, but on a mobile device, something I can easily rotate the mechanical way, not so much - it should always put picture's longer edge at the device's longer edge.



  • Which applies to the camera's display too. It's too tiny when it wastes space by the rotation.



  • @flabdablet said:

    Multi-digit addition, subtraction and multiplication all begin at the little end; only division begins at the big end.

    Comparison, however, does not. And that's quite a big deal you're missing out on - while for all arithmetic operations you need all bytes anyway, for comparison you might just do with the first one and not even bother to read the second in BE.

    @Gaska said:

    Filed under: Rust compiler would error it out for you.

    You've been channelling @ben_lubar quite a lot lately. You seem to have mixed up the languages, though.


  • Banned

    @Maciejasjmj said:

    You've been channelling @ben_lubar quite a lot lately.

    Where do you see "@ben_lubar" in this topic before now?

    @Maciejasjmj said:

    You seem to have mixed up the languages, though.

    Hm? I was speaking of Rust because I think Rust is awesome. It has nothing to do with @ben_lubar thinking Go is awesome (ha, ha).



  • Maybe there's a language gap, but to me, "channeling @ben_lubar" means "acting like @ben_lubar".


  • Java Dev

    I think he thinks him advocating rust is something completely different than you advocating go.



  • @Maciejasjmj said:

    Comparison, however, does not. And that's quite a big deal you're missing out on - while for all arithmetic operations you need all bytes anyway, for comparison you might just do with the first one and not even bother to read the second in BE.

    Regardless of the common sense reading of what should be, the total circuitry for LE operations was simpler.


  • Discourse touched me in a no-no place

    @Jaime said:

    Regardless of the common sense reading of what should be, the total circuitry for LE operations was simpler.

    How does it make any difference at all now that bus widths are larger than 32 bits anyway?



  • Because little-endianness got traction in the early days of computing. Important parts of the early versions of Windows were written in assembler and Microsoft never got over the hump where they could compile on a big endian processor.

    Endianness is no longer a technical decision, it's now a backwards compatibility constraint.


  • Banned

    @ben_lubar said:

    Maybe there's a language gap, but to me, "channeling @ben_lubar" means "acting like @ben_lubar".

    I think there's a language gap in my understanding of English subtleties. Anyway, just because what I'm doing resembles what someone else's doing doesn't mean that I try to act as the said someone else.


  • Discourse touched me in a no-no place

    @Gaska said:

    just because what I'm doing resembles what someone else's doing

    But that's all he meant, by way of a humous-to-some comparison.



  • @Jaime said:

    Endianness is no longer a technical decision, it's now a backwards compatibility constraint.

    For processors with data cache and/or more memory data bus bits than address bits, little-endian data layouts no longer confer a speed advantage. However, not all modern processors have those things. Desktop and server processors certainly do, but there are still a heap of much simpler embedded processors that don't, and making them little-endian just works better.

    On a processor where little-endian layouts don't yield a speed advantage, the choice of big- or little-endian operation is more a matter of aesthetics than anything else. Personally I prefer little-endian addressing because I like numbering my bits according to their arithmetic weight and I like being able to form a bit address by simply tacking the bit number onto the LSB end of the word address.

    The big-endians I know personally are rather less concerned with the elegance of the hardware or the low-level addressing, and simply resent having to shuffle bytes around when looking at hex dumps. Of course I pretend to be polite and tolerant around them but naturally can't help thinking of them as lesser beings.



  • @flabdablet said:

    I like numbering my bits according to their arithmetic weight

    Has this caused you any relationship problems?



  • @FrostCat said:

    But that's all he meant, by way of a humous-to-some comparison.

    In tonight's show, two Poles attempt to communicate in English and fail miserably at it.


  • BINNED

    @Maciejasjmj said:

    In tonight's show, two Poles attempt to communicate in English and fail miserably at it , PHP is still TRWTF, and everybody wears a hat.

    FTFY


Log in to reply