how many lines you coded in your life? if you give an answer try to be real
(and not count data and duplicates)
i myself estimated 200-300k hovever after thinking i think it may be closer to 200k (my newer projects take about 130k or something more but i also got some older i coand count now.. i would say for sure it was no less than 170k but how many above this thios one i can count/memorize now)

are you able to estimate?

On 23/07/2023 18:29, fir wrote:
> how many lines you coded in your life? if you give an answer try to be real
> (and not count data and duplicates)
> i myself estimated 200-300k hovever after thinking i think it may be closer to 200k (my newer projects take about 130k or something more but i also got some older i coand count now.. i would say for sure it was no less than 170k but how many above this thios one i can count/memorize now)
>
> are you able to estimate?

A million lines? I've no idea. But a lot of it wouldn't be fresh code,
but overhauling some existing project.

But I also started longer ago. Some early programs would have been 100%
assembly code, which have a bigger line count.

All currently active projects are about 200Kloc counting latest
versions, across all languages.

niedziela, 23 lipca 2023 o 19:44:56 UTC+2 Bart napisał(a):
> On 23/07/2023 18:29, fir wrote:
> > how many lines you coded in your life? if you give an answer try to be real
> > (and not count data and duplicates)
> > i myself estimated 200-300k hovever after thinking i think it may be closer to 200k (my newer projects take about 130k or something more but i also got some older i coand count now.. i would say for sure it was no less than 170k but how many above this thios one i can count/memorize now)
> >
> > are you able to estimate?
> A million lines? I've no idea. But a lot of it wouldn't be fresh code,
> but overhauling some existing project.
>
> But I also started longer ago. Some early programs would have been 100%
> assembly code, which have a bigger line count.
>
> All currently active projects are about 200Kloc counting latest
> versions, across all languages.

you shouldnt count duplicates.. i guess programers who code long and often are about milion and maybe more...btw i checked my folder and copied all c files in one folder it showed 6 MB of .c filess all mine and no data - there may be some percent of duplicates of oleder and more new versions of some files i attached but still there are not all code only the more new yhen it convince me my estimation was right something between 200k and 300k - all c and 2k lines of python , few lines of assembly and javascript (code itself is not specially interesting so the world would not lost to much if it would get lost etc, though i wopuld be pity - but some ideas (the one i often talked are interesting).. i know i probably should finish my compiler furia but thats damn consumption of time.. but probbaly will need to do that but not yet now

Am 23.07.2023 um 19:29 schrieb fir:
> how many lines you coded in your life? if you give an answer try to be real
> (and not count data and duplicates)
> i myself estimated 200-300k hovever after thinking i think it may be closer to 200k (my newer projects take about 130k or something more but i also got some older i coand count now.. i would say for sure it was no less than 170k but how many above this thios one i can count/memorize now)

For sure in assembly, because that's easier to learn than C. ;-)

niedziela, 23 lipca 2023 o 20:32:50 UTC+2 Bonita Montero napisał(a):
> Am 23.07.2023 um 19:29 schrieb fir:
> > how many lines you coded in your life? if you give an answer try to be real
> > (and not count data and duplicates)
> > i myself estimated 200-300k hovever after thinking i think it may be closer to 200k (my newer projects take about 130k or something more but i also got some older i coand count now.. i would say for sure it was no less than 170k but how many above this thios one i can count/memorize now)
> For sure in assembly, because that's easier to learn than C. ;-)

i dont get the joke at all..btw it seems that to resolve such problemst there is need of some file manager for code, something like total commander program but where you got only code files and its relatives..something like code 'treasury'/or 'code vault' (but in a form resembling total commander)

Am 23.07.2023 um 20:51 schrieb fir:
> niedziela, 23 lipca 2023 o 20:32:50 UTC+2 Bonita Montero napisał(a):
>> Am 23.07.2023 um 19:29 schrieb fir:
>>> how many lines you coded in your life? if you give an answer try to be real
>>> (and not count data and duplicates)
>>> i myself estimated 200-300k hovever after thinking i think it may be closer to 200k (my newer projects take about 130k or something more but i also got some older i coand count now.. i would say for sure it was no less than 170k but how many above this thios one i can count/memorize now)
>> For sure in assembly, because that's easier to learn than C. ;-)
>
> i dont get the joke at all..

You missed the joke.
It's the same distance with C and C++. Assembly is even more easier
to learn, but writing real softwar is much harder. The relationship
keeps the same with C and C++ but at a higher level for both languages.

On 7/23/2023 10:29 AM, fir wrote:
> how many lines you coded in your life? if you give an answer try to be real

God damn. Millions? Maybe more? Good question.

> (and not count data and duplicates)
> i myself estimated 200-300k hovever after thinking i think it may be closer to 200k (my newer projects take about 130k or something more but i also got some older i coand count now.. i would say for sure it was no less than 170k but how many above this thios one i can count/memorize now)
>
> are you able to estimate?

On 23/07/2023 19:32, Bonita Montero wrote:
> For sure in assembly, because that's easier to learn than C. 😉

Yes, but which assembler?

I've used perhaps a dozen. Perhaps because it depends on things like
whether a '286 counts as different to an 8086.

I have no clue how many lines of code I've written. Not even the vaguest
idea.

Andy

niedziela, 23 lipca 2023 o 21:48:30 UTC+2 Vir Campestris napisał(a):
> On 23/07/2023 19:32, Bonita Montero wrote:
> > For sure in assembly, because that's easier to learn than C. 😉
>
> Yes, but which assembler?
>
> I've used perhaps a dozen. Perhaps because it depends on things like
> whether a '286 counts as different to an 8086.
>
> I have no clue how many lines of code I've written. Not even the vaguest
> idea.
>
cound your average lines written in month then count the monyhs (but take all the holes in coding in consideration) but do the counting properly - not rise up... the lines i count by taking kilobytes written and dividing by 20 as average length of a line

On 23/07/2023 21:48, Vir Campestris wrote:
> On 23/07/2023 19:32, Bonita Montero wrote:
>> For sure in assembly, because that's easier to learn than C. 😉
>
> Yes, but which assembler?
>
> I've used perhaps a dozen. Perhaps because it depends on things like
> whether a '286 counts as different to an 8086.
>

I have also used at least a dozen assembly languages - and that is /not/
counting variations such as 8086/80286. (I haven't actually written any
x86 assembly.)

And while some are easy to learn, others are very far from simple -
especially if you want to get efficient results.

> I have no clue how many lines of code I've written. Not even the vaguest
> idea.
>
> Andy
>

poniedziałek, 24 lipca 2023 o 09:02:40 UTC+2 David Brown napisał(a):
> On 23/07/2023 21:48, Vir Campestris wrote:
> > On 23/07/2023 19:32, Bonita Montero wrote:
> >> For sure in assembly, because that's easier to learn than C. 😉
> >
> > Yes, but which assembler?
> >
> > I've used perhaps a dozen. Perhaps because it depends on things like
> > whether a '286 counts as different to an 8086.
> >
> I have also used at least a dozen assembly languages - and that is /not/
> counting variations such as 8086/80286. (I haven't actually written any
> x86 assembly.)
>
> And while some are easy to learn, others are very far from simple -
> especially if you want to get efficient results.
> > I have no clue how many lines of code I've written. Not even the vaguest
> > idea.
> >

code is a tree assembler is good for the 'leafs' but not for the composition of thousands of them (today compiler manages the leafs).. i n fact is better to manage the thin branches (wtwigs) but i
think from some time it has a lack of the bigger branches..
im not sure in quite new part of the language wouldnt be needed
(to ba able to manage those twigs)

one think is the big picture of code in c is not clearly showed,
the second is sometimes someone need to write a big doze
of switches which is tiring and probbaly it would be better to have some pattern for this

poniedziałek, 24 lipca 2023 o 09:27:49 UTC+2 fir napisał(a):
> poniedziałek, 24 lipca 2023 o 09:02:40 UTC+2 David Brown napisał(a):
> > On 23/07/2023 21:48, Vir Campestris wrote:
> > > On 23/07/2023 19:32, Bonita Montero wrote:
> > >> For sure in assembly, because that's easier to learn than C. 😉
> > >
> > > Yes, but which assembler?
> > >
> > > I've used perhaps a dozen. Perhaps because it depends on things like
> > > whether a '286 counts as different to an 8086.
> > >
> > I have also used at least a dozen assembly languages - and that is /not/
> > counting variations such as 8086/80286. (I haven't actually written any
> > x86 assembly.)
> >
> > And while some are easy to learn, others are very far from simple -
> > especially if you want to get efficient results.
> > > I have no clue how many lines of code I've written. Not even the vaguest
> > > idea.
> > >
> code is a tree assembler is good for the 'leafs' but not for the composition of thousands of them (today compiler manages the leafs).. i n fact is better to manage the thin branches (wtwigs) but i
> think from some time it has a lack of the bigger branches..
> im not sure in quite new part of the language wouldnt be needed
> (to ba able to manage those twigs)
>
> one think is the big picture of code in c is not clearly showed,
> the second is sometimes someone need to write a big doze
> of switches which is tiring and probbaly it would be better to have some pattern for this

so i could try to see it c is second assembly on higher level (not mnemonics but on level of functions) and need some second c to be able to get away of the procedures assembly (oop is obviously no way for that..it would be rather need of some kind of discovered predefined patterns or a way of composition of them.. i dont get much idea for that though)

poniedziałek, 24 lipca 2023 o 09:35:23 UTC+2 fir napisał(a):
> poniedziałek, 24 lipca 2023 o 09:27:49 UTC+2 fir napisał(a):
> > poniedziałek, 24 lipca 2023 o 09:02:40 UTC+2 David Brown napisał(a):
> > > On 23/07/2023 21:48, Vir Campestris wrote:
> > > > On 23/07/2023 19:32, Bonita Montero wrote:
> > > >> For sure in assembly, because that's easier to learn than C. 😉
> > > >
> > > > Yes, but which assembler?
> > > >
> > > > I've used perhaps a dozen. Perhaps because it depends on things like
> > > > whether a '286 counts as different to an 8086.
> > > >
> > > I have also used at least a dozen assembly languages - and that is /not/
> > > counting variations such as 8086/80286. (I haven't actually written any
> > > x86 assembly.)
> > >
> > > And while some are easy to learn, others are very far from simple -
> > > especially if you want to get efficient results.
> > > > I have no clue how many lines of code I've written. Not even the vaguest
> > > > idea.
> > > >
> > code is a tree assembler is good for the 'leafs' but not for the composition of thousands of them (today compiler manages the leafs).. i n fact is better to manage the thin branches (wtwigs) but i
> > think from some time it has a lack of the bigger branches..
> > im not sure in quite new part of the language wouldnt be needed
> > (to ba able to manage those twigs)
> >
> > one think is the big picture of code in c is not clearly showed,
> > the second is sometimes someone need to write a big doze
> > of switches which is tiring and probbaly it would be better to have some pattern for this
> so i could try to see it c is second assembly on higher level (not mnemonics but on level of functions) and need some second c to be able to get away of the procedures assembly (oop is obviously no way for that..it would be rather need of some kind of discovered predefined patterns or a way of composition of them.. i dont get much idea for that though)

agent paradigm could be somewhat for that (model of twigs composition), though probably some other also could be found

i eventually could rethink it in a context of my game i now write whan i feel the pain of what i was writing : 'distruibuted' code (code that is distributed on 15 places where ading something mekes big slowdowns of finding that places blindly and jumping among them)

poniedziałek, 24 lipca 2023 o 09:45:43 UTC+2 fir napisał(a):
> poniedziałek, 24 lipca 2023 o 09:35:23 UTC+2 fir napisał(a):
> > poniedziałek, 24 lipca 2023 o 09:27:49 UTC+2 fir napisał(a):
> > > poniedziałek, 24 lipca 2023 o 09:02:40 UTC+2 David Brown napisał(a):
> > > > On 23/07/2023 21:48, Vir Campestris wrote:
> > > > > On 23/07/2023 19:32, Bonita Montero wrote:
> > > > >> For sure in assembly, because that's easier to learn than C. 😉
> > > > >
> > > > > Yes, but which assembler?
> > > > >
> > > > > I've used perhaps a dozen. Perhaps because it depends on things like
> > > > > whether a '286 counts as different to an 8086.
> > > > >
> > > > I have also used at least a dozen assembly languages - and that is /not/
> > > > counting variations such as 8086/80286. (I haven't actually written any
> > > > x86 assembly.)
> > > >
> > > > And while some are easy to learn, others are very far from simple -
> > > > especially if you want to get efficient results.
> > > > > I have no clue how many lines of code I've written. Not even the vaguest
> > > > > idea.
> > > > >
> > > code is a tree assembler is good for the 'leafs' but not for the composition of thousands of them (today compiler manages the leafs).. i n fact is better to manage the thin branches (wtwigs) but i
> > > think from some time it has a lack of the bigger branches..
> > > im not sure in quite new part of the language wouldnt be needed
> > > (to ba able to manage those twigs)
> > >
> > > one think is the big picture of code in c is not clearly showed,
> > > the second is sometimes someone need to write a big doze
> > > of switches which is tiring and probbaly it would be better to have some pattern for this
> > so i could try to see it c is second assembly on higher level (not mnemonics but on level of functions) and need some second c to be able to get away of the procedures assembly (oop is obviously no way for that..it would be rather need of some kind of discovered predefined patterns or a way of composition of them.. i dont get much idea for that though)
> agent paradigm could be somewhat for that (model of twigs composition), though probably some other also could be found
>
> i eventually could rethink it in a context of my game i now write whan i feel the pain of what i was writing : 'distruibuted' code (code that is distributed on 15 places where ading something mekes big slowdowns of finding that places blindly and jumping among them)

writing a game i noticed for example this problem:

in game you generally got a window that shows a fragment of space and a lot of agents of various types:
- ai-driven ships of variuos tipes
- your ship
- asteroids of varius types
- bases of varius types
- portals
- bulets/rockets

there is a problem if put it in separate arrays or in common
in fact i think it is better to put this in common, (the reason is the
putting it in common my be good for thsi code distruibution problem,
i mean separate arrays make more branchhes (in some way, at leest it seems so) thus gives more problem with code distribution and code jumping) but there are 2 problems in my case:
1) player ship has much more fields then rest
2) bullts may be many as i use some for particle efects for
explosions - they are short living but my temporary rise the sise of an array - becouse code for collision has square complexity it is unfortunate to make say 2000x2000 iteration loop

the rest i put in third array so i got 3: player ship, agents and bullets
(more strict i got 4 as i put portals in separate but it was a mistake i guess but to tired to revrite - though i also maybe not sure as protals
are spreaded on worlds, as i not mention those agents/bullets i got in each world separate, in code i switch pointers to current)

funny is the player ship indeed make big separate branch - contained in few separate .c files , where it this code for this branch is partially same as in agents, becouse player ship colides with things where agents colide too - so now im not sure if this was not a mistake
i probably should put player ship as agent and only give additional structure player_specific this posibly could reduce branch

as to bullets it is probebly less problem to keep it in separate, though it makes soem aditional branching, but the cost of increasing this agents array size is to big i guess

(i know btw what i said is not on topic of new high-level composition but this is on old composition yet)

today new thing come to my mind: maybe i should use two dimensional array (array of arrays, i mena not to two dimensional but two indexed agent[n][i]) - this way i could separate subtypes as n
(speeding some iterations)
but not making maybe outburst of branching to much

some could comment if also fights with this 1-container or more- containers problem

On 24/07/2023 08:02, David Brown wrote:
> On 23/07/2023 21:48, Vir Campestris wrote:
>> On 23/07/2023 19:32, Bonita Montero wrote:
>>> For sure in assembly, because that's easier to learn than C. 😉
>>
>> Yes, but which assembler?
>>
>> I've used perhaps a dozen. Perhaps because it depends on things like
>> whether a '286 counts as different to an 8086.
>>
>
> I have also used at least a dozen assembly languages - and that is /not/
> counting variations such as 8086/80286. (I haven't actually written any
> x86 assembly.)

If you haven't used x86, then the variations don't matter?

I can list not quite a dozen varieties, if I include ones where I've
only written a few lines, but I count the x86 versions separately:

+ pdp10
digico m16v
pdp11 (used once to get some driver working)
6800 (the only big-endian machine I've used!)
*+ z80
*+ 8088/6
* 80188/6
* 8035 or 8051
*+ 80386
*+ x64
arm32

* means I either wrote a standalone assembler, or an inline one for a
HLL, or both. That doesn't rule out using someone else's assembler at
some point.

+ means I've used it as a compiler target

(80188/6 is an enhanced version of 8088/6 with integrated peripherals
that have dedicated instructions.)

80386 has a different set of address modes from 8086, and non-segmented
memory in non-real mode.

x64 has extra GP registers, SIMD etc. My syntax for it differs from
standard.

(I don't include the ones I've coded only on paper, to see how they
might work as compiler targets.)

niedziela, 23 lipca 2023 o 21:19:06 UTC+2 Bonita Montero napisał(a):
> Am 23.07.2023 um 20:51 schrieb fir:
> > niedziela, 23 lipca 2023 o 20:32:50 UTC+2 Bonita Montero napisał(a):
> >> Am 23.07.2023 um 19:29 schrieb fir:
> >>> how many lines you coded in your life? if you give an answer try to be real
> >>> (and not count data and duplicates)
> >>> i myself estimated 200-300k hovever after thinking i think it may be closer to 200k (my newer projects take about 130k or something more but i also got some older i coand count now.. i would say for sure it was no less than 170k but how many above this thios one i can count/memorize now)
> >> For sure in assembly, because that's easier to learn than C. ;-)
> >
> > i dont get the joke at all..
> You missed the joke.
> It's the same distance with C and C++. Assembly is even more easier
> to learn, but writing real softwar is much harder. The relationship
> keeps the same with C and C++ but at a higher level for both languages.

i wrote my own assembler (org-asm) you my check it

https://fastupload.io/CYnB7m6CLilssjs/file

it compiles 3 examples...the attached dll is to run second example and thsi ddl is for opening window which my exampel ina ssembly calls to draw mandelbrot set

hovever the resulted exe is simple and has no exception section which may be reason windows defender or other programs can false identify it as malvare it is strictly what you code in asm only

poniedziałek, 24 lipca 2023 o 14:10:54 UTC+2 fir napisał(a):
> i wrote my own assembler (org-asm) you my check it
>
> https://fastupload.io/CYnB7m6CLilssjs/file
>
> it compiles 3 examples...the attached dll is to run second example and thsi ddl is for opening window which my exampel ina ssembly calls to draw mandelbrot set
>
> hovever the resulted exe is simple and has no exception section which may be reason windows defender or other programs can false identify it as malvare it is strictly what you code in asm only

you may se the nice output log from it

+----------------------------------------------------------------------------+
| |
| Organic Assembler (org-asm) by fir, december of 2020 (;ast update V.22) |
| |
| note: this is early version with far from elaborate |
| error messages and not strictly all of the mnemonics implemented, |
| hovever it does the work and i find it nice and usefull |
| |
| right now it is able to assemble win32/x86 exe files (no output as dll |
| yet) with any possible dll imports, so youre basicaly able to assemble |
| any win32 app with it |
| |
+----------------------------------------------------------------------------+
| example use: org-asm input.asm output.exe |
| org-asm program.asm program.exe -no_console |
| |
+----------------------------------------------------------------------------+
| known problems and limits: |
| |
| - use ansi/ascii text as input asm file (if its unicode please open it |
| with notepas and save as ansi) |
| - syntax error reporting are at the moment almost non existant (i will |
| mend it) |
| - there are some hardcoded limits as to numbers of dll to inport (now set |
| to 300) size of code and data sections of exe (ow set to few megabytes) |
| i will remove most of them |
| - not strictly all mnemonics typed |
| - one cant use some character in string literals (like ,/" use "\x2c \x2f |
| \x22" type codes instead (i will mend it) |
| - no dlls can be asembled yet |
| - there are places when expected syntax may be a bit rigid, i will men it |
| |
+----------------------------------------------------------------------------+
------------------------------------------------------------------------------
Opening: input2.asm
------------------------------------------------------------------------------
Basic PE header settings:

attached console window is set off
------------------------------------------------------------------------------
Code selected for assembly :

0 (l. 2) jmp start
1 (l. 42) count_mandelbrot_areafragment_coeficients:
2 (l. 50) mov eax -2
3 (l. 51) cvt si2ss x2 eax
4 (l. 53) mov ss x1 (man.lx)
5 (l. 54) div ss x1 x2
6 (l. 55) add ss x1 (man.ox)
7 (l. 56) mov ss (man.start.x) x1
8 (l. 58) mov ss x1 (man.ly)
9 (l. 59) div ss x1 x2
10 (l. 60) add ss x1 (man.oy)
11 (l. 61) mov ss (man.start.y) x1
12 (l. 63) mov eax ("green.fire.dll"->frame_size_x)
13 (l. 64) mov ebx (eax)
14 (l. 65) cvt si2ss x2 ebx
15 (l. 66) mov ss x1 (man.lx)
16 (l. 67) div ss x1 x2
17 (l. 68) mov ss (man.dx) x1
18 (l. 70) mov eax ("green.fire.dll"->frame_size_y)
19 (l. 71) mov ebx (eax)
20 (l. 72) cvt si2ss x2 ebx
21 (l. 73) mov ss x1 (man.ly)
22 (l. 74) div ss x1 x2
23 (l. 75) mov ss (man.dy) x1
24 (l. 77) ret
25 (l. 81) calc_mandelbtot_for_esi_edi:
26 (l. 90) cvt si2ss x0 esi
27 (l. 91) mov ss x1 (man.dx)
28 (l. 92) mul ss x0 x1
29 (l. 93) add ss x0 (man.start.x)
30 (l. 94) mov ss (c.re) x0
31 (l. 96) cvt si2ss x0 edi
32 (l. 97) mov ss x1 (man.dy)
33 (l. 98) mul ss x0 x1
34 (l. 99) add ss x0 (man.start.y)
35 (l. 100) mov ss (c.im) x0
36 (l. 103) mov ecx 0
37 (l. 104) mov ss x3 (c.re)
38 (l. 105) mov ss x4 (c.im)
39 (l. 106) mov ss x0 x3
40 (l. 107) mov ss x1 x4
41 (l. 108) mov ss x2 (four)
42 (l. 109) mov ss x5 x0
43 (l. 110) iterations:
44 (l. 111) mov ss x6 x1
45 (l. 112) mul ss x5 x5
46 (l. 113) mul ss x6 x6
47 (l. 114) mov ss x7 x5
48 (l. 114) add ss x7 x6
49 (l. 115) comi ss x7 x2
50 (l. 115) jae out
51 (l. 116) sub ss x5 x6
52 (l. 116) add ss x5 x3
53 (l. 117) mul ss x1 x0
54 (l. 117) add ss x1 x1
55 (l. 117) add ss x1 x4
56 (l. 118) mov ss x0 x5
57 (l. 119) inc ecx
58 (l. 119) cmp ecx 256
59 (l. 119) jl iterations
60 (l. 120) mov ecx 0xff0000
61 (l. 120) ret
62 (l. 121) out:
63 (l. 122) push eax
64 (l. 123) mov eax ecx
65 (l. 124) shl eax 8
66 (l. 125) add eax ecx
67 (l. 126) shl eax 8
68 (l. 127) add eax ecx
69 (l. 128) mov ecx eax
70 (l. 129) pop eax
71 (l. 129) ret
72 (l. 164) print_eax:
73 (l. 167) push eax
74 (l. 168) push note_eax
75 (l. 169) call (msvcrt.dll->printf)
76 (l. 170) pop eax
77 (l. 171) pop eax
78 (l. 172) ret
79 (l. 176) ProcessKeyDown:
80 (l. 182) mov eax (esp+4)
81 (l. 183) mov (last_key_pressed) eax
82 (l. 184) mov eax (last_key_pressed)
83 (l. 185) cmp eax (PAGE_UP)
84 (l. 186) jne if_0_end
85 (l. 187) call print_eax
86 (l. 189) if_0_end:
87 (l. 191) ret
88 (l. 195) ProcessRMBDown:
89 (l. 201) mov ss x1 (man.lx)
90 (l. 202) mov ss x2 (man.zoom.out)
91 (l. 203) mul ss x1 x2
92 (l. 204) mov ss (man.lx) x1
93 (l. 206) mov ss x1 (man.ly)
94 (l. 207) mov ss x2 (man.zoom.out)
95 (l. 208) mul ss x1 x2
96 (l. 209) mov ss (man.ly) x1
97 (l. 211) ret
98 (l. 216) ProcessLMBDown:
99 (l. 221) mov eax (esp+4)
100 (l. 221) mov (mouse_down_x) eax
101 (l. 222) call print_eax
102 (l. 224) mov eax (esp+8)
103 (l. 224) mov (mouse_down_y) eax
104 (l. 225) call print_eax
105 (l. 234) mov eax (mouse_down_x)
106 (l. 235) cvt si2ss x1 eax
107 (l. 236) mov eax ("green.fire.dll"->frame_size_x)
108 (l. 237) mov ebx (eax)
109 (l. 239) cvt si2ss x2 ebx
110 (l. 241) div ss x1 x2
111 (l. 242) mul ss x1 (man.lx)
112 (l. 243) add ss x1 (man.ox)
113 (l. 245) mov ss x2 (man.lx)
114 (l. 246) mov eax -2
115 (l. 247) cvt si2ss x3 eax
116 (l. 248) div ss x2 x3
117 (l. 250) add ss x1 x2
118 (l. 251) mov ss (man.ox) x1
119 (l. 255) mov eax (mouse_down_y)
120 (l. 256) cvt si2ss x1 eax
121 (l. 257) mov eax (green.fire.dll->frame_size_y)
122 (l. 258) mov ebx (eax)
123 (l. 260) cvt si2ss x2 ebx
124 (l. 262) div ss x1 x2
125 (l. 263) mul ss x1 (man.ly)
126 (l. 264) add ss x1 (man.oy)
127 (l. 266) mov ss x2 (man.ly)
128 (l. 267) mov eax -2
129 (l. 268) cvt si2ss x3 eax
130 (l. 269) div ss x2 x3
131 (l. 271) add ss x1 x2
132 (l. 272) mov ss (man.oy) x1
133 (l. 277) mov ss x1 (man.lx)
134 (l. 278) mov ss x2 (man.zoom)
135 (l. 279) div ss x1 x2
136 (l. 280) mov ss (man.lx) x1
137 (l. 282) mov ss x1 (man.ly)
138 (l. 283) mov ss x2 (man.zoom)
139 (l. 284) div ss x1 x2
140 (l. 285) mov ss (man.ly) x1
141 (l. 294) ret
142 (l. 298) OnResize:
143 (l. 298) ret
144 (l. 301) ProcessMouseMove:
145 (l. 301) ret
146 (l. 305) RunFrame:
147 (l. 307) push 0x007000
148 (l. 307) call (green.fire.dll->ClearFrameData)
149 (l. 307) pop eax
150 (l. 309) call count_mandelbrot_areafragment_coeficients
151 (l. 311) mov eax (green.fire.dll->frame_bitmap)
152 (l. 311) mov ebp (eax)
153 (l. 312) mov eax (green.fire.dll->frame_size_x)
154 (l. 312) mov ebx (eax)
155 (l. 313) mov eax (green.fire.dll->frame_size_y)
156 (l. 313) mov edx (eax)
157 (l. 315) mov edi 0
158 (l. 316) loop_y:
159 (l. 317) mov esi 0
160 (l. 318) loop_x:
161 (l. 319) push edx
162 (l. 320) mov eax edi
163 (l. 320) mul eax ebx
164 (l. 320) add eax esi
165 (l. 320) shl eax 2
166 (l. 320) add eax ebp
167 (l. 321) pop edx
168 (l. 322) call calc_mandelbtot_for_esi_edi
169 (l. 323) mov (eax) ecx
170 (l. 324) inc esi
171 (l. 324) cmp esi ebx
172 (l. 324) jl loop_x
173 (l. 325) inc edi
174 (l. 325) cmp edi edx
175 (l. 325) jl loop_y
176 (l. 326) ret
177 (l. 337) start:
178 (l. 338) push ProcessMouseMove
179 (l. 338) call (green.fire.dll->RegisterMouseMove)
180 (l. 338) pop eax
181 (l. 339) push ProcessLMBDown
182 (l. 339) call (green.fire.dll->RegisterLeftMouseButtonDown)
183 (l. 339) pop eax
184 (l. 340) push ProcessRMBDown
185 (l. 340) call (green.fire.dll->RegisterRightMouseButtonDown)
186 (l. 340) pop eax
187 (l. 342) push ProcessKeyDown
188 (l. 342) call (green.fire.dll->RegisterKeyDown)
189 (l. 342) pop eax
190 (l. 344) push OnResize
191 (l. 344) call (green.fire.dll->RegisterOnResize)
192 (l. 344) pop eax
193 (l. 345) push RunFrame
194 (l. 345) call (green.fire.dll->RegisterRunFrame)
195 (l. 345) pop eax
196 (l. 347) push 10
197 (l. 347) call (green.fire.dll->SetSleepValue)
198 (l. 347) pop eax
199 (l. 351) push 480
200 (l. 351) push 640
201 (l. 352) push 480
202 (l. 352) push 640
203 (l. 353) push 20
204 (l. 353) push 20
205 (l. 354) push title
206 (l. 354) call (green.fire.dll->SetupWindow3)
207 (l. 355) add esp 20
208 (l. 357) mov eax 0
209 (l. 358) ret
------------------------------------------------------------------------------
Data selected for build :

On 24/07/2023 13:19, fir wrote:
> poniedziałek, 24 lipca 2023 o 14:10:54 UTC+2 fir napisał(a):
>> i wrote my own assembler (org-asm) you my check it
>>
>> https://fastupload.io/CYnB7m6CLilssjs/file
>>
>> it compiles 3 examples...the attached dll is to run second example and thsi ddl is for opening window which my exampel ina ssembly calls to draw mandelbrot set
>>
>> hovever the resulted exe is simple and has no exception section which may be reason windows defender or other programs can false identify it as malvare it is strictly what you code in asm only
>
> you may se the nice output log from it
>
>
> +----------------------------------------------------------------------------+
> | |
> | Organic Assembler (org-asm) by fir, december of 2020 (;ast update V.22) |
^
|
You can't even avoid typos in your own readmes --------------+

Jeez.

> | |
> | note: this is early version with far from elaborate |
> | error messages and not strictly all of the mnemonics implemented, |
> | hovever it does the work and i find it nice and usefull |
> | |
> | right now it is able to assemble win32/x86 exe files (no output as dll |
> | yet) with any possible dll imports, so youre basicaly able to assemble |
> | any win32 app with it |

Also, the shift key is only an inch away. Please learn to spend that
extra fraction of a second.

poniedziałek, 24 lipca 2023 o 14:45:54 UTC+2 Richard Harnden napisał(a):
> On 24/07/2023 13:19, fir wrote:
> > poniedziałek, 24 lipca 2023 o 14:10:54 UTC+2 fir napisał(a):
> >> i wrote my own assembler (org-asm) you my check it
> >>
> >> https://fastupload.io/CYnB7m6CLilssjs/file
> >>
> >> it compiles 3 examples...the attached dll is to run second example and thsi ddl is for opening window which my exampel ina ssembly calls to draw mandelbrot set
> >>
> >> hovever the resulted exe is simple and has no exception section which may be reason windows defender or other programs can false identify it as malvare it is strictly what you code in asm only
> >
> > you may se the nice output log from it
> >
> >
> > +----------------------------------------------------------------------------+
> > | |
> > | Organic Assembler (org-asm) by fir, december of 2020 (;ast update V.22) |
> ^
> |
> You can't even avoid typos in your own readmes --------------+
>
> Jeez.

i dont care that much - note thet logic structure of this log is high,
and that cominicates what is not done i will delete if i do what is not done (hovever presently i not work on this assembler hovever i like it,
it went well)

> > | |
> > | note: this is early version with far from elaborate |
> > | error messages and not strictly all of the mnemonics implemented, |
> > | hovever it does the work and i find it nice and usefull |
> > | |
> > | right now it is able to assemble win32/x86 exe files (no output as dll |
> > | yet) with any possible dll imports, so youre basicaly able to assemble |
> > | any win32 app with it |
> Also, the shift key is only an inch away. Please learn to spend that
> extra fraction of a second.

poniedziałek, 24 lipca 2023 o 14:51:34 UTC+2 fir napisał(a):
> poniedziałek, 24 lipca 2023 o 14:45:54 UTC+2 Richard Harnden napisał(a):
> > On 24/07/2023 13:19, fir wrote:
> > > poniedziałek, 24 lipca 2023 o 14:10:54 UTC+2 fir napisał(a):
> > >> i wrote my own assembler (org-asm) you my check it
> > >>
> > >> https://fastupload.io/CYnB7m6CLilssjs/file
> > >>
> > >> it compiles 3 examples...the attached dll is to run second example and thsi ddl is for opening window which my exampel ina ssembly calls to draw mandelbrot set
> > >>
> > >> hovever the resulted exe is simple and has no exception section which may be reason windows defender or other programs can false identify it as malvare it is strictly what you code in asm only
> > >
> > > you may se the nice output log from it
> > >
> > >
> > > +----------------------------------------------------------------------------+
> > > | |
> > > | Organic Assembler (org-asm) by fir, december of 2020 (;ast update V..22) |
> > ^
> > |
> > You can't even avoid typos in your own readmes --------------+
> >
> > Jeez.
> i dont care that much - note thet logic structure of this log is high,
> and that cominicates what is not done i will delete if i do what is not done (hovever presently i not work on this assembler hovever i like it,
> it went well)
> > > | |
> > > | note: this is early version with far from elaborate |
> > > | error messages and not strictly all of the mnemonics implemented, |
> > > | hovever it does the work and i find it nice and usefull |
> > > | |
> > > | right now it is able to assemble win32/x86 exe files (no output as dll |
> > > | yet) with any possible dll imports, so youre basicaly able to assemble |
> > > | any win32 app with it |
> > Also, the shift key is only an inch away. Please learn to spend that
> > extra fraction of a second.

maybe fractions of seconds of your time had no value but not mine

btw i got no motivation tu upbuild this asembler (mostly needed error communicates, dll output and x64 version) as nobody uses it, it is not in the net though

i would need tu make some www page it to be able to download and make soeme adress to send demands for upgrades...if someone would hacve space on his ww page i would like to use it

poniedziałek, 24 lipca 2023 o 14:51:34 UTC+2 fir napisał(a):
> poniedziałek, 24 lipca 2023 o 14:45:54 UTC+2 Richard Harnden napisał(a):
> > On 24/07/2023 13:19, fir wrote:
> > > poniedziałek, 24 lipca 2023 o 14:10:54 UTC+2 fir napisał(a):
> > >> i wrote my own assembler (org-asm) you my check it
> > >>
> > >> https://fastupload.io/CYnB7m6CLilssjs/file
> > >>
> > >> it compiles 3 examples...the attached dll is to run second example and thsi ddl is for opening window which my exampel ina ssembly calls to draw mandelbrot set
> > >>
> > >> hovever the resulted exe is simple and has no exception section which may be reason windows defender or other programs can false identify it as malvare it is strictly what you code in asm only
> > >
> > > you may se the nice output log from it
> > >
> > >
> > > +----------------------------------------------------------------------------+
> > > | |
> > > | Organic Assembler (org-asm) by fir, december of 2020 (;ast update V..22) |
> > ^
> > |
> > You can't even avoid typos in your own readmes --------------+
> >
> > Jeez.
> i dont care that much - note thet logic structure of this log is high,
> and that cominicates what is not done i will delete if i do what is not done (hovever presently i not work on this assembler hovever i like it,
> it went well)
> > > | |
> > > | note: this is early version with far from elaborate |
> > > | error messages and not strictly all of the mnemonics implemented, |
> > > | hovever it does the work and i find it nice and usefull |
> > > | |
> > > | right now it is able to assemble win32/x86 exe files (no output as dll |
> > > | yet) with any possible dll imports, so youre basicaly able to assemble |
> > > | any win32 app with it |
> > Also, the shift key is only an inch away. Please learn to spend that
> > extra fraction of a second.

i could rather improve the log for example denote the adresses

if end of this code is

203 (l. 353) push 20
204 (l. 353) push 20
205 (l. 354) push title
206 (l. 354) call (green.fire.dll->SetupWindow3)
207 (l. 355) add esp 20
208 (l. 357) mov eax 0
209 (l. 358) ret

and end of binary is
401350 00 00 68 80 02 00 00 68 14 00 00 00 68 14 00 00
401360 00 68 55 30 40 00 ff 15 80 23 40 00 83 c4 14 b8
401370 00 00 00 00 c3

should mark it some way
401350 00 00/68\80 02 00 00/68\14 00 00 00/68\14 00 00
401360 00/68\55 30 40 00/ff 15\80 23 40 00/83 c4\14/b8\
401370 00 00 00 00/c3

or maybe something more readable...im not sure if the code is compatible to flush this without bigger changes

On 24/07/2023 14:44, fir wrote:
> poniedziałek, 24 lipca 2023 o 14:51:34 UTC+2 fir napisał(a):
>> poniedziałek, 24 lipca 2023 o 14:45:54 UTC+2 Richard Harnden napisał(a):
>>> On 24/07/2023 13:19, fir wrote:
>>>> poniedziałek, 24 lipca 2023 o 14:10:54 UTC+2 fir napisał(a):
>>>>> i wrote my own assembler (org-asm) you my check it
>>>>>
>>>>> https://fastupload.io/CYnB7m6CLilssjs/file
>>>>>
>>>>> it compiles 3 examples...the attached dll is to run second example and thsi ddl is for opening window which my exampel ina ssembly calls to draw mandelbrot set
>>>>>
>>>>> hovever the resulted exe is simple and has no exception section which may be reason windows defender or other programs can false identify it as malvare it is strictly what you code in asm only
>>>>
>>>> you may se the nice output log from it
>>>>
>>>>
>>>> +----------------------------------------------------------------------------+
>>>> | |
>>>> | Organic Assembler (org-asm) by fir, december of 2020 (;ast update V.22) |
>>> ^
>>> |
>>> You can't even avoid typos in your own readmes --------------+
>>>
>>> Jeez.
>> i dont care that much - note thet logic structure of this log is high,
>> and that cominicates what is not done i will delete if i do what is not done (hovever presently i not work on this assembler hovever i like it,
>> it went well)
>>>> | |
>>>> | note: this is early version with far from elaborate |
>>>> | error messages and not strictly all of the mnemonics implemented, |
>>>> | hovever it does the work and i find it nice and usefull |
>>>> | |
>>>> | right now it is able to assemble win32/x86 exe files (no output as dll |
>>>> | yet) with any possible dll imports, so youre basicaly able to assemble |
>>>> | any win32 app with it |
>>> Also, the shift key is only an inch away. Please learn to spend that
>>> extra fraction of a second.
>
> maybe fractions of seconds of your time had no value but not mine

So, instead of spending a little time yourself you expect 1000s of
readers to spend their own time?

>
> btw i got no motivation tu upbuild this asembler (mostly needed error communicates, dll output and x64 version) as nobody uses it, it is not in the net though

That's okay because nobody has any motivation to use your assembler.

poniedziałek, 24 lipca 2023 o 16:29:21 UTC+2 fir napisał(a):
> poniedziałek, 24 lipca 2023 o 14:51:34 UTC+2 fir napisał(a):
> > poniedziałek, 24 lipca 2023 o 14:45:54 UTC+2 Richard Harnden napisał(a):
> > > extra fraction of a second.
> i could rather improve the log for example denote the adresses
>
> if end of this code is
> 203 (l. 353) push 20
> 204 (l. 353) push 20
> 205 (l. 354) push title
> 206 (l. 354) call (green.fire.dll->SetupWindow3)
> 207 (l. 355) add esp 20
> 208 (l. 357) mov eax 0
> 209 (l. 358) ret
> and end of binary is
> 401350 00 00 68 80 02 00 00 68 14 00 00 00 68 14 00 00
> 401360 00 68 55 30 40 00 ff 15 80 23 40 00 83 c4 14 b8
> 401370 00 00 00 00 c3
> should mark it some way
> 401350 00 00/68\80 02 00 00/68\14 00 00 00/68\14 00 00
> 401360 00/68\55 30 40 00/ff 15\80 23 40 00/83 c4\14/b8\
> 401370 00 00 00 00/c3
>
> or maybe something more readable...im not sure if the code is compatible to flush this without bigger changes

or maybe something liek that or somethin

401350 00 00(68)80:02:00:00(68)14:00:00:00(68)14:00:00:
401360 00(68)55:30:40:00(ff/15)80:23:40:00(83/c4)14(b8)
401370 00:00:00:00(c3)

i remembered though i flush thsi binary code just as bytes in array so i would need to modify and ad array for tags

poniedziałek, 24 lipca 2023 o 16:36:52 UTC+2 Richard Harnden napisał(a):
> On 24/07/2023 14:44, fir wrote:
> > poniedziałek, 24 lipca 2023 o 14:51:34 UTC+2 fir napisał(a):
> >> poniedziałek, 24 lipca 2023 o 14:45:54 UTC+2 Richard Harnden napisał(a):
> >>> On 24/07/2023 13:19, fir wrote:
> >>>> poniedziałek, 24 lipca 2023 o 14:10:54 UTC+2 fir napisał(a):
> >>>>> i wrote my own assembler (org-asm) you my check it
> >>>>>
> >>>>> https://fastupload.io/CYnB7m6CLilssjs/file
> >>>>>
> >>>>> it compiles 3 examples...the attached dll is to run second example and thsi ddl is for opening window which my exampel ina ssembly calls to draw mandelbrot set
> >>>>>
> >>>>> hovever the resulted exe is simple and has no exception section which may be reason windows defender or other programs can false identify it as malvare it is strictly what you code in asm only
> >>>>
> >>>> you may se the nice output log from it
> >>>>
> >>>>
> >>>> +----------------------------------------------------------------------------+
> >>>> | |
> >>>> | Organic Assembler (org-asm) by fir, december of 2020 (;ast update V.22) |
> >>> ^
> >>> |
> >>> You can't even avoid typos in your own readmes --------------+
> >>>
> >>> Jeez.
> >> i dont care that much - note thet logic structure of this log is high,
> >> and that cominicates what is not done i will delete if i do what is not done (hovever presently i not work on this assembler hovever i like it,
> >> it went well)
> >>>> | |
> >>>> | note: this is early version with far from elaborate |
> >>>> | error messages and not strictly all of the mnemonics implemented, |
> >>>> | hovever it does the work and i find it nice and usefull |
> >>>> | |
> >>>> | right now it is able to assemble win32/x86 exe files (no output as dll |
> >>>> | yet) with any possible dll imports, so youre basicaly able to assemble |
> >>>> | any win32 app with it |
> >>> Also, the shift key is only an inch away. Please learn to spend that
> >>> extra fraction of a second.
> >
> > maybe fractions of seconds of your time had no value but not mine
> So, instead of spending a little time yourself you expect 1000s of
> readers to spend their own time?
> >

they may activate their brain (if they get one)

> > btw i got no motivation tu upbuild this asembler (mostly needed error communicates, dll output and x64 version) as nobody uses it, it is not in the net though
> That's okay because nobody has any motivation to use your assembler.