Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #71667 > unrolled thread

pure c on smartphones (and other devices)

Back to article view | Back to comp.lang.c

Contents

  pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-03 08:32 -0700
    pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 09:19 -0700
      Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-03 09:58 -0700
        Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 10:20 -0700
          Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-03 10:34 -0700
            Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 10:40 -0700
              Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-03 11:30 -0700
                Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-03 11:43 -0700
        Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 10:24 -0700
          Re: pure c on smartphones (and other devices) Johann Klammer <klammerj@NOSPAM.a1.net> - 2015-10-03 20:18 +0200
            Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-03 11:23 -0700
    Re: pure c on smartphones (and other devices) Aleksandar Kuktin <akuktin@gmail.com> - 2015-10-04 12:31 +0000
      Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-04 05:45 -0700
        Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-04 05:53 -0700
          Re: pure c on smartphones (and other devices) supercat@casperkitty.com - 2015-10-05 10:52 -0700
            Re: pure c on smartphones (and other devices) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 22:18 +0000
              Re: pure c on smartphones (and other devices) supercat@casperkitty.com - 2015-10-05 16:16 -0700
                Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-06 00:27 +0100
                  Re: pure c on smartphones (and other devices) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-06 10:50 +0100
                    Re: pure c on smartphones (and other devices) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 10:47 +0000
                    Re: pure c on smartphones (and other devices) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-06 12:31 +0100
                    Re: pure c on smartphones (and other devices) supercat@casperkitty.com - 2015-10-06 09:18 -0700
                      Re: pure c on smartphones (and other devices) Rosario19 <Ros@invalid.invalid> - 2015-10-06 18:30 +0200
                        Re: pure c on smartphones (and other devices) supercat@casperkitty.com - 2015-10-06 10:14 -0700
                      Re: pure c on smartphones (and other devices) Waldek Hebisch <antispam@math.uni.wroc.pl> - 2015-10-09 18:32 +0000
                        Re: pure c on smartphones (and other devices) supercat@casperkitty.com - 2015-10-09 13:02 -0700
                Re: pure c on smartphones (and other devices) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 03:25 +0000
        Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-04 06:27 -0700
          Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-04 06:58 -0700
      Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-04 06:01 -0700
        Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-04 15:33 +0100
          Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-04 07:58 -0700
            Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-04 08:13 -0700
          Re: pure c on smartphones (and other devices) Keith Thompson <kst-u@mib.org> - 2015-10-04 15:42 -0700
            Re: pure c on smartphones (and other devices) David Brown <david.brown@hesbynett.no> - 2015-10-05 09:03 +0200
              Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-05 11:24 +0100
                Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-05 11:27 +0100
              Re: pure c on smartphones (and other devices) Keith Thompson <kst-u@mib.org> - 2015-10-05 09:29 -0700
              Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-06 03:31 -0700
                Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-06 12:29 +0100
                  Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-06 07:18 -0700
                    Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-06 18:33 +0100
                      Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-06 11:07 -0700
                        Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-07 12:53 +0100
                          Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-07 06:33 -0700
                            Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-07 18:21 +0100
                              Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-07 19:10 -0700
    Re: pure c on smartphones (and other devices) Ayan <selfjam@gmail.com> - 2015-10-07 13:41 -0400
      Re: pure c on smartphones (and other devices) fir <profesor.fir@gmail.com> - 2015-10-07 14:01 -0700
        Re: pure c on smartphones (and other devices) Ayan <selfjam@gmail.com> - 2015-10-07 23:09 -0400
          Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 02:26 -0700
          Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-08 11:01 +0100
            Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 03:29 -0700
              Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-08 12:19 +0100
                Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 05:42 -0700
                  Re: pure c on smartphones (and other devices) Bartc <bc@freeuk.com> - 2015-10-08 14:41 +0100
                    Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 06:55 -0700
                      Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-08 08:53 -0700
                        Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 09:21 -0700
                          Re: pure c on smartphones (and other devices) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-08 09:46 -0700
                            Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 10:07 -0700
                              Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-11 23:58 -0700
                          Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-09 04:41 -0700
                Re: pure c on smartphones (and other devices) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-08 05:59 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#72038

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Bartc <bc@freeuk.com> writes:
>
>> On 06/10/2015 00:16, supercat@casperkitty.com wrote:
>>> On Monday, October 5, 2015 at 5:18:52 PM UTC-5, glen herrmannsfeldt wrote:
>>>> Java char is 16 bits, so you are halfway there.
>>>
>>> That doesn't help if one wants to be compatible with code that expects C's
>>> char type to be 8 bits, unless perhaps one decides to have code which
>>> writes a "*char" perform a read-modify-write on an element of a "char[]" or
>>> "short[]" while having operations on 32-bit types act on a pair of elements
>>> in a "char[]" or "short[]".
>>
>> Java's data types include signed 8, 16, 32 and 64-bit integers. And an
>> unsigned 16-bit char.
>>
>> Presumably the JVM supports these, and wouldn't be too hard for C to
>> target. Harder are unsigned values (of 8, 32 and 64 bits).
>
> But it does not support pointers.  You would either have to model C's
> address space as a giant array of bytes, or you would have to make all
> objects into arrays of length one.

Correction: not all objects necessarily, but all objects that are not
already arrays whose address might be taken.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#72057

On Tuesday, October 6, 2015 at 4:51:09 AM UTC-5, Ben Bacarisse wrote:
> But it does not support pointers.  You would either have to model C's
> address space as a giant array of bytes, or you would have to make all
> objects into arrays of length one.

I think the most practical approach would probably be to have a global array
int[][] Memory, and have every pointer within the C language be a combination
of an index into that array and an offset into that sub-array.  If one didn't
have to support code that wanted to use smaller types, that might work out
pretty well.  If one wants to support 8-bit "char", then achieving reasonable
performance would require that a compiler be able to recognize cases where
things were accessed as "char" purely for purposes of getting around the
prohibitions against type punning.  On many systems, if a program needs to
copy the bits of an "int32_t" to a "float", such an operation may be
performed more quickly via:

    ((char*)&floatval)[0]=((char*)&intval)[0];
    ((char*)&floatval)[1]=((char*)&intval)[1];
    ((char*)&floatval)[2]=((char*)&intval)[2];
    ((char*)&floatval)[3]=((char*)&intval)[3];

than via memcpy(), but a straightforward translation to a system where the
underlying data type was int32_t and char accesses were done by decomposing
and reconstituting values could end up being dozens of times slower than
would be the straightforward translation of "(int32_t*)&floatval = intval;".

[toc] | [prev] | [next] | [standalone]

#72060

On Tue, 6 Oct 2015 09:18:33 -0700 (PDT), supercat wrote:

>    ((char*)&floatval)[0]=((char*)&intval)[0];
>    ((char*)&floatval)[1]=((char*)&intval)[1];
>    ((char*)&floatval)[2]=((char*)&intval)[2];
>    ((char*)&floatval)[3]=((char*)&intval)[3];

i don't like all these cast
for me it is better
#define  i8  char
#define  u32 unsigned
#define  F   for

u32  i;
i8  *fl=(i8*)&floatval, *in=(i8*)&intval;
F(i=0; i<4; ++i)
       fl[i]=in[i];

[toc] | [prev] | [next] | [standalone]

#72066

On Tuesday, October 6, 2015 at 11:30:46 AM UTC-5, Rosario19 wrote:
> u32  i;
> i8  *fl=(i8*)&floatval, *in=(i8*)&intval;
> F(i=0; i<4; ++i)
>        fl[i]=in[i];

That would likely be slower than memcpy.  On something like the 8088,
if both variables are local, each assignment would be two three-byte
instructions; the total would be 24 byte in eight instructions.  For
tiny, small, or medium memory model, the memcpy() might end up being
both smaller and faster if the compiler can render it as a compiler
intrinsic, but for compact, large, or huge memory model performance
of memcpy() would be much worse unless the compiler can optimize its
behavior for the case where it's accessing variables on the stack--
something I would not expect the compiler to do.

[toc] | [prev] | [next] | [standalone]

#72295

supercat@casperkitty.com wrote:
> prohibitions against type punning.  On many systems, if a program needs to
> copy the bits of an "int32_t" to a "float", such an operation may be
> performed more quickly via:
> 
>     ((char*)&floatval)[0]=((char*)&intval)[0];
>     ((char*)&floatval)[1]=((char*)&intval)[1];
>     ((char*)&floatval)[2]=((char*)&intval)[2];
>     ((char*)&floatval)[3]=((char*)&intval)[3];
> 
> than via memcpy(),

Only when using crappy compiler.  On x86_64 using gcc 4.9.2 in the
following program memcpy() translates into single mchine instruction:

#include <string.h>

int conv(float f)
{
    int res;
    memcpy(&res, &f, 4);
    return res;
}

translation:

conv:
.LFB14:
        .cfi_startproc
        movd    %xmm0, %eax
        ret
        .cfi_endprocOD

In general seeing memcpy() compiler can choose best way to
copy.  Single byte access rarely is the best way and it is
hard for the compiler too see what is intended.  Using
gcc-4.9.2 your code does not work at all.  More
precisely replacing memcpy() by your sequence in the 'conv'
routine produces code returning always 0.  Actually, using
gcc-4.3.0 I get the same non-working result.  So the
type punning versions is broken for several years.
In gcc-4.3.0 memcpy leads to two machine instructions
which is suboptimal but still much better than byte-by-byte
copy.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#72316

On Friday, October 9, 2015 at 1:32:24 PM UTC-5, Waldek Hebisch wrote:
> Only when using crappy compiler.  On x86_64 using gcc 4.9.2 in the
> following program memcpy() translates into single mchine instruction:

In cases where it isn't necessary to access things as discrete bytes, code
which does so is going to be pretty nasty and inefficient compared with
code that uses larger types.

On the other hand, if one has an "int32_t __packed *ip" and a
"float __packed *fp" and needs to copy one to the other using code for e.g.
the Cortex-M0, code using manual byte copies would require eight instructions
once the two addresses were in registers (e.g. r4 and r5).  A memcpy which
was optimized for size rather than speed, however, might use something like:

    movs r1,#3
lp
    ldrb r0,[r4,r1]
    strb r0,[r5,r1]
    subs r1,r1,#1
    bcs  lp

which would be much slower, but would take only five instructions (10 bytes)
rather than eight (16 bytes).

[toc] | [prev] | [next] | [standalone]

#72023

supercat@casperkitty.com wrote:
> On Monday, October 5, 2015 at 5:18:52 PM UTC-5, glen herrmannsfeldt wrote:
>> Java char is 16 bits, so you are halfway there.
 
> That doesn't help if one wants to be compatible with code that expects C's
> char type to be 8 bits, unless perhaps one decides to have code which
> writes a "*char" perform a read-modify-write on an element of a "char[]" or
> "short[]" while having operations on 32-bit types act on a pair of elements
> in a "char[]" or "short[]".

Well, Java has byte for a signed 8 bit type. Use that if needed.
There are some complications with reading files, and I am not sure
how it went by now.

In C, char is often used when one wants an 8 bit type, even though
it isn't related to actual characters.
 
> It's too bad Java didn't provide functions to access individual 
> pieces of the longer primitives within an array.  
> I don't think there are any platforms where that would have 
> been expensive, and endian-ness issues could be resolved by 
> having separate big-endian and little-endian methods.  

In all the cases that matter, Java claims big-endian. 

But Java does provide ways to get the bits out of larger
types, as does C, with & and >>. 

Also, Java isn't intended to be used in low-level systems
programming that C is, at least sometimes, used for.

I haven't thought about this for a while, but there might be
Java methods to copy bytes from larger arrays to byte[].

> On a little-endian machine, the little-endian method would 
> read item "index" from a byte array overlapped on the original, 
> and a big-endian method would read item "index^3" from 
> that same array.  On a big-endian machine, simply swap which 
> method does what.

That doesn't sound like Java. 
 
> A function to copy one unaligned range of bytes to another would be cheaper
> with one assumed endian-ness than the other, but not outrageously so.  The
> JVM could almost certainly handle such things much more efficiently than can
> user code written in Java without such a feature.

That is about what Java does. Everything assumes big endian, so
it might be slower on little endian hosts. There is, for example,
serialization which converts an object to an array of bytes.

In the usual case, you don't look at the bytes, but on the other
end deserialize back to the original object. 

-- glen

[toc] | [prev] | [next] | [standalone]

#71804

On Sunday, October 4, 2015 at 8:45:27 AM UTC-4, fir wrote:
> W dniu niedziela, 4 października 2015 14:31:41 UTC+2 użytkownik Aleksandar Kuktin napisał:
> > On Sat, 03 Oct 2015 08:32:20 -0700, fir wrote:
> > 
> > > I once tried one day to setup android coding environment but was
> > > 'dispelled' by that (to big to 'messy' javalike sh*t, xml-s, meaningfull
> > > folder names etc )
> > > 
> > > I long for real pure c coding on devices - which is like you produce
> > > binary able to execute run it and here you go..
> > > 
> > > have someone knows something on this things (pure c on devices) I got no
> > > biger (or even smaller) picture on this things,
> > 
> > This is absolutely perfectly doable, although getting a GUI handle may be 
> > problematic.
> > 
> > The easiest way, and the one I did, is to use Android's kernel and ship 
> > your own userland. Basically, setup a cross-compiler on a seed host 
> > (desktop), compile the minimal userland, copy that userland onto the 
> > phone and let it recompile itself into a complete feature-full computing 
> > environment.
> > 
> > For this, you'll need a terminal (either find some Terminal app or ssh) 
> > and probably root. Shop around for a rootkit, they're easy to find. :)
> > 
> > Take a look at CLFS for pointers: http://www.linuxfromscratch.org/
> 
> my personal trouble is i dont know nothing about linux.. but good to know such solution is avaliable, it sound that if i would be coding on linux i would take this route..
> other trouble is to get the gui api or at least raw screen acces/blitter etc..
> seem to be longer story though each such a longer story has probably its own hackish shortcuts..

Linux has a steep learning curve in some areas, and a lesser one in other
areas.  I wrote an article years ago entitled, "How to Leave Redmond, WA
in 24 Hours" that the editor butchered somewhat:

     http://www.tgdaily.com/trendwatch-features/32967-tg-daily-special-leaving-redmond-wa-in-24-hours

It explained making the migration from Windows to Ubuntu.  It's out-of-date
being now 8 years old, but the general concepts are the same.  You'll have
to figure out which apps to replace your Windows apps, and you'll need to
learn how to use the command line.

Linux is a very powerful UNIX-like implementation.  Everything's a file,
so you can use standard C read() and write(), or fread() and fwrite() on
things, etc.  This includes devices, settings, raw hard disks, data files,
everything.

There's lots of help now on Linux forums, Ubuntu forums, and places like
Stack Overflow.  And you can always email some of us for help if you get
stuck.  We're also often on chat I'm sure.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#71807

W dniu niedziela, 4 października 2015 15:28:03 UTC+2 użytkownik Rick C. Hodgin napisał:
> On Sunday, October 4, 2015 at 8:45:27 AM UTC-4, fir wrote:
> > W dniu niedziela, 4 października 2015 14:31:41 UTC+2 użytkownik Aleksandar Kuktin napisał:
> > > On Sat, 03 Oct 2015 08:32:20 -0700, fir wrote:
> > > 
> > > > I once tried one day to setup android coding environment but was
> > > > 'dispelled' by that (to big to 'messy' javalike sh*t, xml-s, meaningfull
> > > > folder names etc )
> > > > 
> > > > I long for real pure c coding on devices - which is like you produce
> > > > binary able to execute run it and here you go..
> > > > 
> > > > have someone knows something on this things (pure c on devices) I got no
> > > > biger (or even smaller) picture on this things,
> > > 
> > > This is absolutely perfectly doable, although getting a GUI handle may be 
> > > problematic.
> > > 
> > > The easiest way, and the one I did, is to use Android's kernel and ship 
> > > your own userland. Basically, setup a cross-compiler on a seed host 
> > > (desktop), compile the minimal userland, copy that userland onto the 
> > > phone and let it recompile itself into a complete feature-full computing 
> > > environment.
> > > 
> > > For this, you'll need a terminal (either find some Terminal app or ssh) 
> > > and probably root. Shop around for a rootkit, they're easy to find. :)
> > > 
> > > Take a look at CLFS for pointers: http://www.linuxfromscratch.org/
> > 
> > my personal trouble is i dont know nothing about linux.. but good to know such solution is avaliable, it sound that if i would be coding on linux i would take this route..
> > other trouble is to get the gui api or at least raw screen acces/blitter etc..
> > seem to be longer story though each such a longer story has probably its own hackish shortcuts..
> 
> Linux has a steep learning curve in some areas, and a lesser one in other
> areas.  I wrote an article years ago entitled, "How to Leave Redmond, WA
> in 24 Hours" that the editor butchered somewhat:
> 
>      http://www.tgdaily.com/trendwatch-features/32967-tg-daily-special-leaving-redmond-wa-in-24-hours
> 
> It explained making the migration from Windows to Ubuntu.  It's out-of-date
> being now 8 years old, but the general concepts are the same.  You'll have
> to figure out which apps to replace your Windows apps, and you'll need to
> learn how to use the command line.
> 
> Linux is a very powerful UNIX-like implementation.  Everything's a file,
> so you can use standard C read() and write(), or fread() and fwrite() on
> things, etc.  This includes devices, settings, raw hard disks, data files,
> everything.
> 
> There's lots of help now on Linux forums, Ubuntu forums, and places like
> Stack Overflow.  And you can always email some of us for help if you get
> stuck.  We're also often on chat I'm sure.
> 
I could get essential insight of android internals*, but spending a years on learning linux is out of question 

[toc] | [prev] | [next] | [standalone]

#71802

W dniu niedziela, 4 października 2015 14:31:41 UTC+2 użytkownik Aleksandar Kuktin napisał:
> On Sat, 03 Oct 2015 08:32:20 -0700, fir wrote:
> 
> > I once tried one day to setup android coding environment but was
> > 'dispelled' by that (to big to 'messy' javalike sh*t, xml-s, meaningfull
> > folder names etc )
> > 
> > I long for real pure c coding on devices - which is like you produce
> > binary able to execute run it and here you go..
> > 
> > have someone knows something on this things (pure c on devices) I got no
> > biger (or even smaller) picture on this things,
> 
> This is absolutely perfectly doable, although getting a GUI handle may be 
> problematic.
> 
> The easiest way, and the one I did, is to use Android's kernel and ship 
> your own userland. Basically, setup a cross-compiler on a seed host 
> (desktop), compile the minimal userland, copy that userland onto the 
> phone and let it recompile itself into a complete feature-full computing 
> environment.
> 
> For this, you'll need a terminal (either find some Terminal app or ssh) 
> and probably root. Shop around for a rootkit, they're easy to find. :)
> 
> Take a look at CLFS for pointers: http://www.linuxfromscratch.org/

ps maybe if you get a moment you could explain in short how it looks on linux
is this like on windows where you have strict kernel (ntoskrnl.exe ) and the core winapi (kernel32.dll, user32.dll gdi32.dll) which is also a kernel but operates in user mode and provides less metal-core functionalities than ntoskrnl.exe

this userland you mean is some analogon to kernel32.dll, user32.dll gdi32.dll ? are thiose dynami libraries that are present on normal linux but are not included in android so you can compile from source and throw it in or what?

[toc] | [prev] | [next] | [standalone]

#71810

On 04/10/2015 14:01, fir wrote:
> W dniu niedziela, 4 października 2015 14:31:41 UTC+2 użytkownik Aleksandar Kuktin napisał:
>> On Sat, 03 Oct 2015 08:32:20 -0700, fir wrote:

> ps maybe if you get a moment you could explain in short how it looks on linux
> is this like on windows where you have strict kernel (ntoskrnl.exe ) and the core winapi (kernel32.dll, user32.dll gdi32.dll) which is also a kernel but operates in user mode and provides less metal-core functionalities than ntoskrnl.exe
>
> this userland you mean is some analogon to kernel32.dll, user32.dll gdi32.dll ? are thiose dynami libraries that are present on normal linux but are not included in android so you can compile from source and throw it in or what?

I run Linux within my Windows system, that makes it easier to 
experiment. Also Linux can access the Windows file system (so I can use 
my own editor within Windows then switch to Linux to compile).

This is done using Oracle VM Virtual Box and using that to install 
Ubuntu. It was quite complicated and took a while to get going but now 
it's fairly stable.

32-bit Ubuntu runs within a 1024x768-pixel window within normal 64-bit 
Windows. It can run its own version of Firefox.

Linux itself is a nightmare if you're not familiar with it, and I don't 
use it often enough to remember the commands. Its file system is 
appalling (I tried looking for libX11.so* anywhere in the system, but it 
couldn't find it. But it must exist as the code below worked).

Basic Linux runs in a console or terminal. Graphics I believe is based 
on 'X11'. The rough equivalent of 'gdi32.dll' might be 'libX11.so.6". 
The equivalent of LoadLibrary("gdi32.dll") might be:

  #include <dlfcn.h>

  void* p;
  p = dlopen("libX11.so.6",RTLD_LAZY);

But I agree, if you want to do low-level coding on an Android device, 
you don't necessarily want to get involved in Linux too (and the million 
things you need to know, or it is just assumed that you know already; 
you can spend a lifetime sorting out problem after problem).

It might still be preferable to writing Java though (I've also 
downloaded that huge Android SDK; I couldn't make head or tail or it. 
Perhaps you need to be 16 years old to understand it and not be thinking 
about why it's 100 times bigger and more complicated than such a thing 
ought to be.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#71815

W dniu niedziela, 4 października 2015 16:33:55 UTC+2 użytkownik Bart napisał:
> On 04/10/2015 14:01, fir wrote:
> > W dniu niedziela, 4 października 2015 14:31:41 UTC+2 użytkownik Aleksandar Kuktin napisał:
> >> On Sat, 03 Oct 2015 08:32:20 -0700, fir wrote:
> 
> > ps maybe if you get a moment you could explain in short how it looks on linux
> > is this like on windows where you have strict kernel (ntoskrnl.exe ) and the core winapi (kernel32.dll, user32.dll gdi32.dll) which is also a kernel but operates in user mode and provides less metal-core functionalities than ntoskrnl.exe
> >
> > this userland you mean is some analogon to kernel32.dll, user32.dll gdi32.dll ? are thiose dynami libraries that are present on normal linux but are not included in android so you can compile from source and throw it in or what?
> 
> I run Linux within my Windows system, that makes it easier to 
> experiment. Also Linux can access the Windows file system (so I can use 
> my own editor within Windows then switch to Linux to compile).
> 
> This is done using Oracle VM Virtual Box and using that to install 
> Ubuntu. It was quite complicated and took a while to get going but now 
> it's fairly stable.
> 
> 32-bit Ubuntu runs within a 1024x768-pixel window within normal 64-bit 
> Windows. It can run its own version of Firefox.
> 
> Linux itself is a nightmare if you're not familiar with it, and I don't 
> use it often enough to remember the commands. Its file system is 
> appalling (I tried looking for libX11.so* anywhere in the system, but it 
> couldn't find it. But it must exist as the code below worked).
> 
> Basic Linux runs in a console or terminal. Graphics I believe is based 
> on 'X11'. The rough equivalent of 'gdi32.dll' might be 'libX11.so.6". 
> The equivalent of LoadLibrary("gdi32.dll") might be:
> 
>   #include <dlfcn.h>
> 
>   void* p;
>   p = dlopen("libX11.so.6",RTLD_LAZY);
> 
well thats fine,, this min (mean) that on linux both strightforward c coding and strightforward c gui coding is not a problem,, question is how it looks on android where both or at least one is (or may be) a problem

doeas maybe someone know what differs linux and android here.. are asm executables disallowed to run or native gui api acces is disallowed and everything runs inside 'dalvik' or what?



> But I agree, if you want to do low-level coding on an Android device, 
> you don't necessarily want to get involved in Linux too (and the million 
> things you need to know, or it is just assumed that you know already; 
> you can spend a lifetime sorting out problem after problem).
> 
> It might still be preferable to writing Java though (I've also 
> downloaded that huge Android SDK; I couldn't make head or tail or it. 
> Perhaps you need to be 16 years old to understand it and not be thinking 
> about why it's 100 times bigger and more complicated than such a thing 
> ought to be.)
> 
> -- 
> Bartc

[toc] | [prev] | [next] | [standalone]

#71817

On Sunday, October 4, 2015 at 10:58:20 AM UTC-4, fir wrote:
> > Basic Linux runs in a console or terminal. Graphics I believe is based 
> > on 'X11'. The rough equivalent of 'gdi32.dll' might be 'libX11.so.6". 
> > The equivalent of LoadLibrary("gdi32.dll") might be:
> > 
> >   #include <dlfcn.h>
> > 
> >   void* p;
> >   p = dlopen("libX11.so.6",RTLD_LAZY);
> > 
> well thats fine,, this min (mean) that on linux both strightforward c coding and strightforward c gui coding is not a problem,, question is how it looks on android where both or at least one is (or may be) a problem
> 
> doeas maybe someone know what differs linux and android here.. are asm executables disallowed to run or native gui api acces is disallowed and everything runs inside 'dalvik' or what?

It might be easier to write a stub program in Java which then uses
JNI or JNA to access your C or assembly code from inside Java.  In
that way your code works politely with other apps on the phone, has
the standard interface features, and yet also has your features.

Here is a method of setting it up I wrote for a native Windows app
back in 2011:

     https://github.com/RickCHodgin/opbm/tree/master/java/opbm
     https://github.com/RickCHodgin/opbm/tree/master/java/benchmark
     https://github.com/RickCHodgin/opbm/tree/master/vs2010

If you load the project (into NetBeans 7.x I believe from 2011),
then you'll see how the JNI code initializes itself at startup.
Then by looking at the C/C++ code in the Visual Studio 2010 project,
you'll see how it handles passed parameters from Java.

This JNI interface was very nice for allowing Java to do some of
the UI work, and then accessing raw C/C++ code to do the compute
operations for the benchmark.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#71880

Bartc <bc@freeuk.com> writes:
[...]
> Linux itself is a nightmare if you're not familiar with it, and I don't 
> use it often enough to remember the commands. Its file system is 
> appalling (I tried looking for libX11.so* anywhere in the system, but it 
> couldn't find it. But it must exist as the code below worked).

<OT>

On my system, there are libX11.so* files under /usr/lib/i386-linux-gnu
and /usr/lib/x86_64-linux-gnu.  The two directories are needed to
support generating both 32-bit and 64-bit code.

I found this out using the command
    find /usr/lib -name 'libX11.so*'

The compiler (actually the linker) knows where to find the libraries.
Compiling with "gcc -v" should tell you where it finds the files it
uses.

</OT>

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#71947

On 05/10/15 00:42, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
> [...]
>> Linux itself is a nightmare if you're not familiar with it, and I don't 
>> use it often enough to remember the commands. Its file system is 
>> appalling (I tried looking for libX11.so* anywhere in the system, but it 
>> couldn't find it. But it must exist as the code below worked).
> 

Details can vary a little from distro to distro - some might have it
under /usr/lib64/libX11.so, for example.  But I think most people who
are interested in where their libraries are, and who know what an ".so"
library is in the first place, would have little difficulty in looking
for their user-level libraries in /usr/lib or similar directories.
Failing that, "locate libX11.so" is a good choice for finding files.
And for people who don't like command lines, most file managers on Linux
will also have search facilities.

And of course a few minutes with google would also lead you to find the
file.


My 70-year old mother in law has never had trouble with Linux.  My kids
have used it since they could wiggle a mouse.  Linux is not hard - at
least, not hard compared to other OS's, and not hard until you are
trying to do hard things with it.  Your trouble here, Bart, is that you
have long experience with Windows and are stuck in a rut.  You think the
"Windows way" is the /only/ right way, because it is the only way you
know.  Until you accept that Linux is not Windows, nor any sort of a
copy of Windows, you will always find Linux difficult.  Some things are
much the same in Linux and Windows, some things are better or easier in
Linux, some things are better or easier in Windows, and some things are
just /different/.

If you don't want to learn anything about Linux, and you don't want to
use it, that's fine.  But you should then refrain from commenting on it,
and parading your ignorance so proudly.  (Of course, I recommend that
you /do/ learn about it, and use it, as well as Windows - it would widen
your outlook and give you access to far more toys.  But c.l.c. is not
the place to discuss it in detail.)

> <OT>
> 
> On my system, there are libX11.so* files under /usr/lib/i386-linux-gnu
> and /usr/lib/x86_64-linux-gnu.  The two directories are needed to
> support generating both 32-bit and 64-bit code.
> 
> I found this out using the command
>     find /usr/lib -name 'libX11.so*'
> 
> The compiler (actually the linker) knows where to find the libraries.
> Compiling with "gcc -v" should tell you where it finds the files it
> uses.
> 

gcc only knows where to find static libraries - dynamic libraries are
located by the OS on link-loading, rather than by gcc.  "cat
/etc/ld.so.conf" (or a similar file) will show your standard dynamic
library directories.

> </OT>
> 

[toc] | [prev] | [next] | [standalone]

#71961

On 05/10/2015 08:03, David Brown wrote:
> On 05/10/15 00:42, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>> [...]
>>> Linux itself is a nightmare if you're not familiar with it, and I don't
>>> use it often enough to remember the commands.

> But I think most people who
> are interested in where their libraries are, and who know what an ".so"
> library is in the first place, would have little difficulty

I'm interested in where they are, and I know what a .so file is, but it 
didn't help. (ls -R didn't work; the GUI file-manager just went on 
searching for several minutes until I cancelled it.)

To start with, I didn't even know that the file I wanted was called 
libX11.so, or whether such a file actually existed. See, it's not so simple!

(I have a language project that relies on shared libraries to do things 
such as graphics. I vaguely knew about X Windows and that Linux shared 
libraries ended in ".so". If a .so file for X didn't exist, I would have 
to create one by wrapping C around a statically linked version, not an 
appealing prospect.)

> My 70-year old mother in law has never had trouble with Linux.

Perhaps your mother wasn't trying to implement her own language, 
compiler, interpreter, runtime, graphics and GUI libraries, editor, IDE 
and other tools on Linux.

> Your trouble here, Bart, is that you
> have long experience with Windows and are stuck in a rut.  You think the
> "Windows way" is the /only/ right way,

Before I used Windows I'd had nearly nearly 20 years experience of 
assorted OSes, none of which had GUI interfaces. The last 10 was with 
msdos though. None of these, including Windows, try to get in my way as 
much as Linux does.

But if Windows is a rut, then Linux is a considerably wider and deeper one.

> If you don't want to learn anything about Linux, and you don't want to
> use it, that's fine.

I didn't say that, I said I didn't use it often enough to remember what 
I did to solve certain problems, and have to solve them again. I will 
use it eventually but on my terms, ie. I can do things my way not Linux' 
way.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#71962

On 05/10/2015 11:24, Bartc wrote:
> On 05/10/2015 08:03, David Brown wrote:

>> My 70-year old mother in law has never had trouble with Linux.
>
> Perhaps your mother wasn't trying to implement her own .... on  Linux.

Sorry I meant your mother-in-law.

[toc] | [prev] | [next] | [standalone]

#71982

David Brown <david.brown@hesbynett.no> writes:
> On 05/10/15 00:42, Keith Thompson wrote:
[...]
>> On my system, there are libX11.so* files under /usr/lib/i386-linux-gnu
>> and /usr/lib/x86_64-linux-gnu.  The two directories are needed to
>> support generating both 32-bit and 64-bit code.
>> 
>> I found this out using the command
>>     find /usr/lib -name 'libX11.so*'
>> 
>> The compiler (actually the linker) knows where to find the libraries.
>> Compiling with "gcc -v" should tell you where it finds the files it
>> uses.
>
> gcc only knows where to find static libraries - dynamic libraries are
> located by the OS on link-loading, rather than by gcc.  "cat
> /etc/ld.so.conf" (or a similar file) will show your standard dynamic
> library directories.

Right.  To be perhaps a bit clearer, static libraries are located by the
linker (which is invoked by the "gcc" command), and dynamic libraries
are located when the command is executed.  And there are ways to
override the configuration specified in /etc/ld.so.conf.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#72035

On Monday, October 5, 2015 at 8:04:10 AM UTC+1, David Brown wrote:
> On 05/10/15 00:42, Keith Thompson wrote:

> My 70-year old mother in law has never had trouble with Linux.  My kids
> have used it since they could wiggle a mouse.  Linux is not hard - at
> least, not hard compared to other OS's, and not hard until you are
> trying to do hard things with it.  Your trouble here, Bart, is that you
> have long experience with Windows and are stuck in a rut.  You think the
> "Windows way" is the /only/ right way, because it is the only way you
> know.  Until you accept that Linux is not Windows, nor any sort of a
> copy of Windows, you will always find Linux difficult.  Some things are
> much the same in Linux and Windows, some things are better or easier in
> Linux, some things are better or easier in Windows, and some things are
> just /different/.
> 
X is harder to code for than Windows GDI. Since I've got Baby X working on both
systems I think I'm well qualified to comment on that.
But both systems have points of difficulty, some of it due to legacy systems
needing to support very constrained systems (so you have a window own the
clipboard rather than putting stuff on it, to save memory, for example, of
course that's a total grief to support).
Once you've got the basic services working, then there's no difference, however.
Most programs have what I call the algorithmic core, which should be written
in pure, portable ANSI C, then what I call the glue code, which is the usual 
failure point of the system because it gets hacked about in response to changing
user requirements, and then the services - code for buttons, colour pickers, and
the like. The services section (e.g. Baby X) is where the differences lie. 

[toc] | [prev] | [next] | [standalone]

#72037

On 06/10/2015 11:31, Malcolm McLean wrote:
> On Monday, October 5, 2015 at 8:04:10 AM UTC+1, David Brown wrote:

>> Your trouble here, Bart, is that you
>> have long experience with Windows and are stuck in a rut.  You think the
>> "Windows way" is the /only/ right way, because it is the only way you
>> know.

(I already mentioned about my previous OSes, but the first graphics work 
I did was in 1979. Both colour raster graphics, and vector graphics 
using 4010 terminals. When did Windows appear again?)

> X is harder to code for than Windows GDI. Since I've got Baby X working on both
> systems I think I'm well qualified to comment on that.
> But both systems have points of difficulty, some of it due to legacy systems
> needing to support very constrained systems (so you have a window own the
> clipboard rather than putting stuff on it, to save memory, for example, of
> course that's a total grief to support).
> Once you've got the basic services working, then there's no difference, however.
> Most programs have what I call the algorithmic core, which should be written
> in pure, portable ANSI C, then what I call the glue code, which is the usual
> failure point of the system because it gets hacked about in response to changing
> user requirements, and then the services - code for buttons, colour pickers, and
> the like. The services section (e.g. Baby X) is where the differences lie.
>

Here I would have to disagree; I want to eliminate the C side of it as 
far as I can, and only use it where necessary.

I believe in using interpreted, dynamic code as much as possible 
(especially for anything involved in GUIs where are you waiting for user 
input most of the time).

The interfaces are also far simpler; BabyX is reasonably straightforward 
but scripting code can make it simpler still.

The way I have it is like this: suppose 'G' is the graphics/GUI API used 
by the scripting language, and 'H' is the native graphics API provided 
by the platform (ie. GDI or X Windows). 'H' will generally be vastly 
bigger and more complex than 'G'.

There will then be 3 layers of coding:

* Modules talking only to 'G' (most of the application) or implementing 
parts of 'G' that do not depend on 'H'. All this code is portable.

* Module(s) which implement core parts of 'G' and talk to 'H'

* Interface modules to 'H'.

It is these last two layers, still using interpreted bytecode, that have 
to talk to the platform's graphics API by dynamically accessing the 
shared libraries (.dll or .so). And which need to be different between 
Windows and Linux.

Where does C come into it? Well, hopefully as little as possible! There 
is the interpreter, not written in C, but for a target that my compiler 
doesn't support (anything not 64-bit Windows at the minute), then it 
will need to generate C source code and rely on a C compiler (a messy 
dependency that I can't easily get around).

But all the machine interfaces are also defined in C terms (MS says it's 
C++, but GDI uses C). I still make use of the C runtime library. Example 
code will be in C (if it's C++, then forget it). Such as your BabyX 
which I will probably pinch a few ideas from. And auxiliary programs 
such as Jpeg decoders (although I've now ported your Jpeg decoder to my 
compiled language).

(This is all why I don't always have much patience when trying to make 
use of libraries which exist as C source code, but requiring far more 
messing about with than simply compiling and linking.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web