3 ms·

The entire thing is writted in FASM assembler. So maybe they thought a normal gui toolkit is too heavy weight for asm.

dkersten 9y ago
Sure, that's likely the case and its an impressive piece of software. But.. that doesn't stop it from looking dated. Then again, maybe people used to developing in assembly (ie the target users) don't mind or are used to worse looking tools (eg when I was doing microcontroller development, most tools were pretty bad and dated looking, some newer ones used eclipse/netbeans for better or worse).
- johnfound 9y ago
  Well, as I said several posts above, I am working on a new, assembly language, portable GUI toolkit that to be used for v3.x series of Fresh IDE. Unfortunately it will add another 50..100kB to the code, but the portability has price. :(
  - dkersten 9y ago
    I didn't mean it as a criticism to you or your work and fresh certainly looks decent, more that I found the name ironic given the "classic" look of the GUI. My first comment at least, the second one was commenting on how many low level tools are to look dated and maybe it's the norm. Again, I didn't really mean it as criticism even though I suppose it sounds like it. :/ Could you instead call into an existing portable UI library? Perhaps FLTK or something more lightweight than the popular ones. It just seems to me that creating a new GUI toolkit from scratch is a massive undertaking and I'm unsure what value you will get over spending the time improving fresh itself? I guess there's some appeal to having a self contained assembly system through and through.
    - johnfound 9y ago
      No offenses. :) At first, FLTK, does not look much better than the old Windows widgets. In addition, I strongly want Fresh IDE to be portable to MenuetOS, KolibriOS and other assembly written OSes. As a rule, they all are written with FASM and a good IDE that can be ported for days (not for years) can be great tool for the OS developers. That is why I started the development of special GUI toolkit.
      - iheartmemcache 9y ago
        RE: Portability - Not sure how far you'll be able to get by gcc -S'ing something like nuklear[1] (cross-platform ANSI C89) but it might save you some time. I don't have much HLL asm/demoscene experience personally so I'm not sure what's "impressive" as engineering feats these days but this looks cool. As someone who aspires to see a viable Smalltalk-like runtime self-modifiable introspective debugger at the OS level with a decent layer of POSIX compatibility and the ability to run AVX512 instructions, I like the idea that tools like this are out there. Cheers, mate [1] https://github.com/vurtun/nuklear https://github.com/vurtun/nuklear
        exikyut 9y ago
        > As someone who aspires to see a viable Smalltalk-like runtime self-modifiable introspective debugger at the OS level That's an interesting pile of keywords you've got there. I don't know about Smalltalk (I find Squeak, Pharo, etc utterly incomprehensible - I have no idea what to do with them), but for some time I've been fascinated with the idea of a fundamentally mutable and even self-modifying environment. My favorite optimization would be that, in the case of tight loops with tons of if()s and other types of conditional logic, the language could JIT-_rearrange_ the code to nop the if()s and other logic just before the tight loop was entered - or even better, gather up the parts of code that will be executed and dump all of it somewhere contiguous. C compilers could probably be made to do this too, but that would break things like W^X and also squarely violate lots of expectations as well.
        iheartmemcache 9y ago
        This is sort of implemented in various forms. For a VM, RE: code rearrangement, you're effectively describing dynamic DCE if I understand you correctly, CLR does this (and lots more)[2]. At the low-level programmer level, there's nothing stopping a (weakly) static language like C from adopting that behavior[3] at runtime [i.e. with a completely bit-for-bit identical, statically linked executable which]. At the compiler level, you've got the seminal Turing Award by Ken Thompson that does it at compiler level[4]. At the processor level, you heuristically have branch prediction as a critical part of any pipeline. (I think modern Intel processors as of the Haswell era assign each control flow point a total of 4 bits which just LSL/LSR to count the branch taken/not taken. (Don't quote me on that)). RE: Smalltalk - for me, the power of the platform's mutability was revealed when I started using Cincom. When I was using GNU implementations ~10 years ago, they felt like toys at the time (though I hear things have largely improved). If you've ever used Ruby, a simple analogy would be the whole "you can (ab)use the hell out of things like #Method_Missing to create your own DSLs". This lends of a lot of flexibility to the language (at the expense of performance, typing guarantees). In a Smalltalk environment, you get that sort of extensibility + static typing guarantees + the dynamic ability to recover from faults in a fashion you want. Imagine an environment[5] that has that structured instrinsically + the performance of being able to use all them fancy XMM/YMM registers for numerical analysis + a ring0 SoftICE type debugger. Turtles all the way down, baby. ===== [1] See ISL-TAGE of CBP3 and other, more modern reportings from "Championship Branch Prediction" if it's still being run). [2] https://stackoverflow.com/a/8874314 https://stackoverflow.com/a/8874314 Here's how it's done with the CLR. The JVM is crazy good so I'd imagine the analogue exists there as well. [3] https://en.wikipedia.org/wiki/Polymorphic_code https://en.wikipedia.org/wiki/Polymorphic_code [4] http://wiki.c2.com/?TheKenThompsonHack http://wiki.c2.com/?TheKenThompsonHack [5] Use some micro-kernel OS architecture so process $foo won't alter $critical-driver-talking-to-SATA-devices or modifying malloc. I'd probably co-opt QNXs Neutrino designs since it's tried and true. Plus that sort of architecture has the design benefit of intrinsically safe high-availability integrated into the network stack.
- cardiffspaceman 9y ago
  I'd say it is actually a stylized version of the latest UI conventions: the icon row could be an interpretation of the MS Office 'ribbon'. I can't tell from the screen shots whether or not it has the old Borland C++ IDE green check mark and red X. That would be dated, no question. The Windows 3.1 / Presentation Manager look would be dated.

Sure, that's likely the case and its an impressive piece of software. But.. that doesn't stop it from looking dated. Then again, maybe people used to developing in assembly (ie the target users) don't mind or are used to worse looking tools (eg when I was doing microcontroller development, most tools were pretty bad and dated looking, some newer ones used eclipse/netbeans for better or worse).

johnfound 9y ago
Well, as I said several posts above, I am working on a new, assembly language, portable GUI toolkit that to be used for v3.x series of Fresh IDE. Unfortunately it will add another 50..100kB to the code, but the portability has price. :(
- dkersten 9y ago
  I didn't mean it as a criticism to you or your work and fresh certainly looks decent, more that I found the name ironic given the "classic" look of the GUI. My first comment at least, the second one was commenting on how many low level tools are to look dated and maybe it's the norm. Again, I didn't really mean it as criticism even though I suppose it sounds like it. :/ Could you instead call into an existing portable UI library? Perhaps FLTK or something more lightweight than the popular ones. It just seems to me that creating a new GUI toolkit from scratch is a massive undertaking and I'm unsure what value you will get over spending the time improving fresh itself? I guess there's some appeal to having a self contained assembly system through and through.
  - johnfound 9y ago
    No offenses. :) At first, FLTK, does not look much better than the old Windows widgets. In addition, I strongly want Fresh IDE to be portable to MenuetOS, KolibriOS and other assembly written OSes. As a rule, they all are written with FASM and a good IDE that can be ported for days (not for years) can be great tool for the OS developers. That is why I started the development of special GUI toolkit.
    - iheartmemcache 9y ago
      RE: Portability - Not sure how far you'll be able to get by gcc -S'ing something like nuklear[1] (cross-platform ANSI C89) but it might save you some time. I don't have much HLL asm/demoscene experience personally so I'm not sure what's "impressive" as engineering feats these days but this looks cool. As someone who aspires to see a viable Smalltalk-like runtime self-modifiable introspective debugger at the OS level with a decent layer of POSIX compatibility and the ability to run AVX512 instructions, I like the idea that tools like this are out there. Cheers, mate [1] https://github.com/vurtun/nuklear https://github.com/vurtun/nuklear
      - exikyut 9y ago
        > As someone who aspires to see a viable Smalltalk-like runtime self-modifiable introspective debugger at the OS level That's an interesting pile of keywords you've got there. I don't know about Smalltalk (I find Squeak, Pharo, etc utterly incomprehensible - I have no idea what to do with them), but for some time I've been fascinated with the idea of a fundamentally mutable and even self-modifying environment. My favorite optimization would be that, in the case of tight loops with tons of if()s and other types of conditional logic, the language could JIT-_rearrange_ the code to nop the if()s and other logic just before the tight loop was entered - or even better, gather up the parts of code that will be executed and dump all of it somewhere contiguous. C compilers could probably be made to do this too, but that would break things like W^X and also squarely violate lots of expectations as well.
        iheartmemcache 9y ago
        This is sort of implemented in various forms. For a VM, RE: code rearrangement, you're effectively describing dynamic DCE if I understand you correctly, CLR does this (and lots more)[2]. At the low-level programmer level, there's nothing stopping a (weakly) static language like C from adopting that behavior[3] at runtime [i.e. with a completely bit-for-bit identical, statically linked executable which]. At the compiler level, you've got the seminal Turing Award by Ken Thompson that does it at compiler level[4]. At the processor level, you heuristically have branch prediction as a critical part of any pipeline. (I think modern Intel processors as of the Haswell era assign each control flow point a total of 4 bits which just LSL/LSR to count the branch taken/not taken. (Don't quote me on that)). RE: Smalltalk - for me, the power of the platform's mutability was revealed when I started using Cincom. When I was using GNU implementations ~10 years ago, they felt like toys at the time (though I hear things have largely improved). If you've ever used Ruby, a simple analogy would be the whole "you can (ab)use the hell out of things like #Method_Missing to create your own DSLs". This lends of a lot of flexibility to the language (at the expense of performance, typing guarantees). In a Smalltalk environment, you get that sort of extensibility + static typing guarantees + the dynamic ability to recover from faults in a fashion you want. Imagine an environment[5] that has that structured instrinsically + the performance of being able to use all them fancy XMM/YMM registers for numerical analysis + a ring0 SoftICE type debugger. Turtles all the way down, baby. ===== [1] See ISL-TAGE of CBP3 and other, more modern reportings from "Championship Branch Prediction" if it's still being run). [2] https://stackoverflow.com/a/8874314 https://stackoverflow.com/a/8874314 Here's how it's done with the CLR. The JVM is crazy good so I'd imagine the analogue exists there as well. [3] https://en.wikipedia.org/wiki/Polymorphic_code https://en.wikipedia.org/wiki/Polymorphic_code [4] http://wiki.c2.com/?TheKenThompsonHack http://wiki.c2.com/?TheKenThompsonHack [5] Use some micro-kernel OS architecture so process $foo won't alter $critical-driver-talking-to-SATA-devices or modifying malloc. I'd probably co-opt QNXs Neutrino designs since it's tried and true. Plus that sort of architecture has the design benefit of intrinsically safe high-availability integrated into the network stack.
cardiffspaceman 9y ago
I'd say it is actually a stylized version of the latest UI conventions: the icon row could be an interpretation of the MS Office 'ribbon'. I can't tell from the screen shots whether or not it has the old Borland C++ IDE green check mark and red X. That would be dated, no question. The Windows 3.1 / Presentation Manager look would be dated.