Board.KolibriOS.org

I am developing in fasm inside KolibriOS. Every time I open FASM, it defaults its path to sys with file example.asm. I have to change it every time I restart.

I finally figured out how to save system configuration with rdsave, but fasm default is not saved.

I looked at all .INI files, but can't find fasm's.

Is it hardwired somewhere?

Development in KolibriiOS using FASM is a little bit different: You can all do in TinyPad .
See the video:
https://drive.google.com/file/d/1RKsTbR ... p=sharing

I have used too small screen resolution for debugger.
And in the end I only demonstrate, how to test program with shell (and on clipboard place text my program)
it is testing demonstration with command line arguments.

Valery, thank you for the video.
I would prefer to use CEdit because of black background. I not a fan of IDEs (I use vim and emacs and command shell, and all the linux utilities...). I am sad FASM does not work on the command line... KolibriOS would be much better with a solid text-mode envirnoment, the graphics gizmos are wussies

So is there a way to change the default path of fasm?

Problem is, that there is no environment variables on KolibriOS - no PATH.
Any program default current directory is /SYS. Program can change - but program itself, and original FASM does not do this (on POSIX OS it is not needed).

FASM was ported before shell was written - the only way was to write GUI. And fasm GUI do all, that is needed:
You open shell in working path -> You write working path in fasm GUI
You call fasm <infile> <outfile> -> You write <infile> and <outfile> in fasm GUI
You not close and reopen shell in one session -> You not close and reopen fasm GUI in one session
You can use more than one shell -> You can use more than one fasm GUI
See video:
https://drive.google.com/file/d/1n_McPo ... sp=sharing

Somewhere in or around fasm, EXAMPLE.ASM is stuck into the GUI. I just want to be able to change it.

I understand the workflow, but with a shell I can script commands. With GUI I have to click on a bunch of things to get my file and path, which is fine once, but gets really exhausting every time I reboot.

Does the shell support scripting at all?

Shell support's scripting , but I never tried ...

Valery: I take it you are not a Linux guy...

I am "OsDev cross compiler guy ..." - all made on Linux by cross compiler
(but sometimes check - if this can be done on MS Windows too):
KolibriOS tools not yet able to do all things, that I need
(and , how I understand, - You need).

I (and You) need:
- integrated in OS shell with environment variables (but KolibriOS has only independent command shell - not integrated in OS);
- shell console applications (KolibriOS applications mostly are GUI ones, some have console application look,
but really GUI applications with console imitation, provided by console.obj;
shell allow to build console application integrated with it, but how I know - no application use this API
{And my idea is to change API to more simple IPC style, but I can not do all things at one moment} )
- make utility and over project integration tools (KolibriOS not have any);
...

P.S.
If we compare KolibriOS with GNU/Linux and MS/Windows, than
KolibriOS is more like MS/Windows (as FASM community part).
For example, KolibriOS have no pipe conception at all ...

Valery: Yes!

Even a minimal command-line environment with piping would make everything much, much better. Text utilities are composable and without GUI code are much, much smaller.

At minimum, it would be nice to be able to assemble from the command line, right?

I don't want to complain -- thank you for all the amazing work in KolibriOS!

without GUI code are much, much smaller

This is true on GNU/Linux and MS/Windows,
but GUI application on KolibriOS
have the same size as "console" applications
and much smaller than GNU/Linux and MS/Windows
command line applications.

So I understand and respect the KolibriOS developers choice (command line -> GUI).

P.S.
Any way UI (GUI or command line) code is less than 5% in such applications, as
- FASM
- TCC
- CMM
...
UI interface choice not change applications size in this situation.

I too understand the choice, and respect all the work that went into it. I am a big fan.

But I would say it is an incorrect choice. You can always make a quick GUI for a command-line application without any changes to the application, moving that 5% into a separate and isolated piece of code. But, you _cannot_ make a command-line wrapper around a GUI application without a lot of work...(emulating mouse clicks, stuffing dialog fields, hiding the GUI, etc)

Anyway, I don't want an argument, and it is what it is, and it is fun.

But, you _cannot_ make a command-line wrapper around a GUI application

You are right in this case.

Peace, brother.