473,326 Members | 2,196 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

C runtime library for Unix

I would like to port PDPCLIB:

http://sourceforge.net/projects/pdos/

my public domain C runtime library for DOS, OS/2,
Win32, MVS to Unix now.

I am a bit perplexed as to how to do this. Unix/Posix
systems provide open() with which I can implement
fopen(). But then Posix is also required to define fopen(),
so this is not the level at which I need to implement it.

Although I don't think the CRT should be polluting the
namespace by using open() in the first place.

If the lower level is platform-dependent, then the platform
I wish to target is Linux.

Can someone get me started?

Thanks. Paul.
Nov 17 '06 #1
21 3037
Paul Edwards wrote:
I would like to port PDPCLIB:

http://sourceforge.net/projects/pdos/

my public domain C runtime library for DOS, OS/2,
Win32, MVS to Unix now.

I am a bit perplexed as to how to do this. Unix/Posix
systems provide open() with which I can implement
fopen(). But then Posix is also required to define fopen(),
so this is not the level at which I need to implement it.

Although I don't think the CRT should be polluting the
namespace by using open() in the first place.

If the lower level is platform-dependent, then the platform
I wish to target is Linux.

Can someone get me started?
As a system library, you'll need to only rely on the APIs exported by
the OS. Linux aims towards POSIX compliance and thus implements many
APIs defined by POSIX. The system C library often also provides POSIX
interface.

In general you should try to do as much as possible within standard C
and write specific functions when they're called for. If you want the
library to port to most UNIXes, it's structure and compilation will get
more involved. If it's specifically for Linux, then it'll be much
simpler.

At a minimum you'll need to refer to the C standard, the POSIX
standards and the man 2 pages for the OS API. The tricky part will be
satisfying the OS without sacrificing too much portability.

Post Linux API related questions to one of the Linux groups. Details
within standard C portions can be discussed here or in comp.std.c, (but
I doubt that those areas would be much of a problem for you).

The Linux newsgroups will probably help you best. Also browse the
sources of C libraries like dietlibc etc.

Nov 17 '06 #2
"santosh" <sa*********@gmail.comwrote in message news:11**********************@e3g2000cwe.googlegro ups.com...
Also browse the sources of C libraries like dietlibc etc.
Thanks. I found that, and their fopen() calls __libc_open()
which in turn calls __syscall_open().

The __syscall_open() is presumably what the OS exports,
and what I need to use to avoid polluting the user's namespace
by a direct call to open().

I haven't found where __syscall_open() is defined yet,
but I found a sys_open() in syscalls.h. Maybe that's the
proper one to use.

BFN. Paul.
Nov 17 '06 #3
Paul Edwards skrev:

[...]
I haven't found where __syscall_open() is defined yet,
but I found a sys_open() in syscalls.h. Maybe
that's the proper one to use.
sys_open()
sys_read()
sys_write()
sys_close()

BUT, why not look up the Linux kernel documentation or
ask in a forum where Linux is on-topic?

comp.os.linux.misc
comp.os.linux.development.system
comp.os.linux.development.apps
etc.

<gd&r>

--
Tor <torust AT online DOT no>

Nov 17 '06 #4


Paul Edwards wrote On 11/17/06 15:20,:
"santosh" <sa*********@gmail.comwrote in message news:11**********************@e3g2000cwe.googlegro ups.com...
>>Also browse the sources of C libraries like dietlibc etc.


Thanks. I found that, and their fopen() calls __libc_open()
which in turn calls __syscall_open().

The __syscall_open() is presumably what the OS exports,
and what I need to use to avoid polluting the user's namespace
by a direct call to open().

I haven't found where __syscall_open() is defined yet,
but I found a sys_open() in syscalls.h. Maybe that's the
proper one to use.
Why is it better to pollute the user's namespace
with sys_open() than with open()?

--
Er*********@sun.com

Nov 17 '06 #5
Paul Edwards wrote:
"santosh" <sa*********@gmail.comwrote in message news:11**********************@e3g2000cwe.googlegro ups.com...
Also browse the sources of C libraries like dietlibc etc.

Thanks. I found that, and their fopen() calls __libc_open()
which in turn calls __syscall_open().

The __syscall_open() is presumably what the OS exports,
and what I need to use to avoid polluting the user's namespace
by a direct call to open().

I haven't found where __syscall_open() is defined yet,
but I found a sys_open() in syscalls.h. Maybe that's the
proper one to use.
No. This is still a feature of the existing C library. If you want your
CRT to be independant of other libraries, you must directly call the
kernel by means of assembler, (either INT, SYSCALL, SYSENTER etc). The
API exported by the kernel is available in the 'asm/unistd.h' header
for UNIX like kernels. For each defined syscall, refer to it's man 2
page for the official documentation, but they're often not good enough
to enable you to write robust code, (especially for newer system
calls). As the ultimate reference, the kernel's source may have to
consulted.

To enable the rest of your library to be portable, you'll probably want
to create wrappers around system calls, just like existing sys_open()
sys_write() etc.

Nov 18 '06 #6
"Eric Sosman" <Er*********@sun.comwrote in message news:1163805399.935710@news1nwk...
The __syscall_open() is presumably what the OS exports,
and what I need to use to avoid polluting the user's namespace
by a direct call to open().

I haven't found where __syscall_open() is defined yet,
but I found a sys_open() in syscalls.h. Maybe that's the
proper one to use.

Why is it better to pollute the user's namespace
with sys_open() than with open()?
Technically it isn't, but since no-one actually uses sys_open(),
I didn't think anyone would notice.

I have the same problem with Win32. It is polluting the user's
namespace with CreateFile(). I don't know how to get around
that. I wonder what other C compilers do?

BFN. Paul.
Nov 18 '06 #7
Paul Edwards said:
"Eric Sosman" <Er*********@sun.comwrote in message
news:1163805399.935710@news1nwk...
>>
Why is it better to pollute the user's namespace
with sys_open() than with open()?

Technically it isn't, but since no-one actually uses sys_open(),
I didn't think anyone would notice.

I have the same problem with Win32. It is polluting the user's
namespace with CreateFile(). I don't know how to get around
that. I wonder what other C compilers do?
Don't worry about it. Since no-one actually uses CreateFile() - except as a
Win32 API call - I don't think anyone will notice.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
Nov 18 '06 #8
Eric Sosman skrev:
Paul Edwards wrote On 11/17/06 15:20,:
[...]
The __syscall_open() is presumably what the OS exports,
and what I need to use to avoid polluting the user's namespace
by a direct call to open().

Why is it better to pollute the user's namespace
with sys_open() than with open()?
I don't get it. Why does the standard library pollute user's
namespace?

Internally, the library will have e.g. <open.c>, which calls the
OS functions. So those OS calls shouldn't be visable to the
library caller... so is it a link problem we talk about here?

--
Tor <torust AT online DOT no>

Nov 18 '06 #9
"Tor Rustad" <to********@hotmail.comwrote in message news:11*********************@m73g2000cwd.googlegro ups.com...
Eric Sosman skrev:
Paul Edwards wrote On 11/17/06 15:20,:

[...]
The __syscall_open() is presumably what the OS exports,
and what I need to use to avoid polluting the user's namespace
by a direct call to open().
Why is it better to pollute the user's namespace
with sys_open() than with open()?

I don't get it. Why does the standard library pollute user's
namespace?

Internally, the library will have e.g. <open.c>, which calls the
OS functions. So those OS calls shouldn't be visable to the
library caller... so is it a link problem we talk about here?
Yes, the problem will occur at link time. The C library is
not meant to be dependent on functions which are in the
user's namespace. The C library is allowed to use names
such as __open() or _Open() (on a case-sensitive system),
but not open().

BFN. Paul.
Nov 18 '06 #10
Paul Edwards wrote:
"Eric Sosman" <Er*********@sun.comwrote in message news:1163805399.935710@news1nwk...
>>>The __syscall_open() is presumably what the OS exports,
and what I need to use to avoid polluting the user's namespace
by a direct call to open().

I haven't found where __syscall_open() is defined yet,
but I found a sys_open() in syscalls.h. Maybe that's the
proper one to use.

Why is it better to pollute the user's namespace
with sys_open() than with open()?


Technically it isn't, but since no-one actually uses sys_open(),
I didn't think anyone would notice.
They might be *more* likely to notice than if you'd just
used open(). Programs written with portability in mind are
quite likely to avoid making native O/S calls directly, but
to route them through "wrapper" functions instead. On many
systems the wrappers will simply call the native interface
without further ado, but they provide a convenient place to
insert special handling for a system that requires it or can
take advantage of it. For example, a wrapper for open() might
just take its three arguments and call open() on most systems,
but on Frobozz Unix there's extra code to set a special mode
bits when opening anything under the "/var" directory -- for
some sort of esoteric FUX-specific reason you and I don't
understand.

Now: The wrapper can't be called open(), obviously. As
a developer of this portable program, what name are you likely
to choose? Actual examples I've seen include OSopen() and
OsOpen(), but it wouldn't surprise me in the least to find that
someone had decided to form wrapper names by prefixing sys_ to
everything ...
I have the same problem with Win32. It is polluting the user's
namespace with CreateFile(). I don't know how to get around
that. I wonder what other C compilers do?
Special games with linkers, if they bother at all. There'll
be some sort of magic that allows the user to write and use an
open() function while library denizens like fopen() can still
somehow call the system's open(). There'll be "weak symbols"
and possibly a lot of renaming going on -- or, sometimes, they'll
just say "Tough: You bought our system, you bought our names."
It's a jungle out there.

--
Eric Sosman
es*****@acm-dot-org.invalid
Nov 18 '06 #11
"Paul Edwards" <ke******@nosppaam.w3.towrites:
"Tor Rustad" <to********@hotmail.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...
>Eric Sosman skrev:
Paul Edwards wrote On 11/17/06 15:20,:

[...]
The __syscall_open() is presumably what the OS exports,
and what I need to use to avoid polluting the user's namespace
by a direct call to open().

Why is it better to pollute the user's namespace
with sys_open() than with open()?

I don't get it. Why does the standard library pollute user's
namespace?

Internally, the library will have e.g. <open.c>, which calls the
OS functions. So those OS calls shouldn't be visable to the
library caller... so is it a link problem we talk about here?

Yes, the problem will occur at link time. The C library is
not meant to be dependent on functions which are in the
user's namespace. The C library is allowed to use names
such as __open() or _Open() (on a case-sensitive system),
but not open().
I just tried a small test program that defines an external function
called "open". It worked with no problem. The systems I tried it on
also have a system function called "open"; you have to include a
non-standard header to make it visible. There was problem linking the
program. I don't know (or much care) how the system does this; it
just works.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 18 '06 #12
Keith Thompson wrote:
"Paul Edwards" <ke******@nosppaam.w3.towrites:
"Tor Rustad" <to********@hotmail.comwrote in message
news:11*********************@m73g2000cwd.googlegro ups.com...
Eric Sosman skrev:
Paul Edwards wrote On 11/17/06 15:20,:

[...]

The __syscall_open() is presumably what the OS exports,
and what I need to use to avoid polluting the user's namespace
by a direct call to open().

Why is it better to pollute the user's namespace
with sys_open() than with open()?

I don't get it. Why does the standard library pollute user's
namespace?

Internally, the library will have e.g. <open.c>, which calls the
OS functions. So those OS calls shouldn't be visable to the
library caller... so is it a link problem we talk about here?
Yes, the problem will occur at link time. The C library is
not meant to be dependent on functions which are in the
user's namespace. The C library is allowed to use names
such as __open() or _Open() (on a case-sensitive system),
but not open().

I just tried a small test program that defines an external function
called "open". It worked with no problem. The systems I tried it on
also have a system function called "open"; you have to include a
non-standard header to make it visible. There was problem linking the
program. I don't know (or much care) how the system does this; it
just works.
Do you mean there was NO problem linking ?

Nov 18 '06 #13
"Spiros Bousbouras" <sp****@gmail.comwrites:
Keith Thompson wrote:
[...]
>I just tried a small test program that defines an external function
called "open". It worked with no problem. The systems I tried it on
also have a system function called "open"; you have to include a
non-standard header to make it visible. There was problem linking the
program. I don't know (or much care) how the system does this; it
just works.

Do you mean there was NO problem linking ?
Yes.

% cat foo.h
#ifndef FOO_H
#define FOO_H
void open(void);
#endif

% cat foo.c
#include <stdio.h>
#include "foo.h"
void open(void)
{
printf("In open()\n");
}

% cat main.c
#include "foo.h"

int main(void)
{
open();
return 0;
}
% gcc foo.c main.c -o main
% ./main
In open()

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 18 '06 #14
Keith Thompson wrote:
>
.... snip ...
>
I just tried a small test program that defines an external function
called "open". It worked with no problem. The systems I tried it
on also have a system function called "open"; you have to include a
non-standard header to make it visible. There was problem linking
the program. I don't know (or much care) how the system does this;
it just works.
This will normally be because the run time library is searched
last, and only for items that are so far undefined. This is not
mandated by the standard, but is in practice the methodology. The
success is also affected by how finely the library is sub-divided,
for example the code block for malloc will usually include both
free and realloc, so they can only be replaced as a complete triad.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Nov 18 '06 #15
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>>
... snip ...
>>
I just tried a small test program that defines an external function
called "open". It worked with no problem. The systems I tried it
on also have a system function called "open"; you have to include a
non-standard header to make it visible. There was problem linking
the program. I don't know (or much care) how the system does this;
it just works.

This will normally be because the run time library is searched
last, and only for items that are so far undefined. This is not
mandated by the standard, but is in practice the methodology. The
success is also affected by how finely the library is sub-divided,
for example the code block for malloc will usually include both
free and realloc, so they can only be replaced as a complete triad.
And the result of this is that a C program can use any identifier it
likes as long as it's not reserved by the standard, even if it's one
like "open" (or "sys_open", or whatever) that might be used by the
operating system.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 18 '06 #16
Paul Edwards skrev:
"Tor Rustad" <to********@hotmail.comwrote in message
Eric Sosman skrev:
>
Why is it better to pollute the user's namespace
with sys_open() than with open()?
I don't get it. Why does the standard library pollute user's
namespace?

Internally, the library will have e.g. <open.c>, which calls the
OS functions. So those OS calls shouldn't be visable to the
library caller... so is it a link problem we talk about here?

Yes, the problem will occur at link time. The C library is
not meant to be dependent on functions which are in the
user's namespace. The C library is allowed to use names
such as __open() or _Open() (on a case-sensitive system),
but not open().
I still don't get it...

On Linux you go from user space to kernel space via interrupt
0x80, using inline assembler... ref. <asm/unistd.hand
_syscallN() macros... right?

On Win32 you load kernel32.dll and call the functions via
functions pointers... right?

So exactly how do the linker see any function names which
is invading the user name space?

What am I missing???

--
Tor

Nov 18 '06 #17
"Tor Rustad" <to********@hotmail.comwrote in message news:11**********************@e3g2000cwe.googlegro ups.com...
Paul Edwards skrev:
"Tor Rustad" <to********@hotmail.comwrote in message
Eric Sosman skrev:

Why is it better to pollute the user's namespace
with sys_open() than with open()?
>
I don't get it. Why does the standard library pollute user's
namespace?
>
Internally, the library will have e.g. <open.c>, which calls the
OS functions. So those OS calls shouldn't be visable to the
library caller... so is it a link problem we talk about here?
Yes, the problem will occur at link time. The C library is
not meant to be dependent on functions which are in the
user's namespace. The C library is allowed to use names
such as __open() or _Open() (on a case-sensitive system),
but not open().

I still don't get it...

On Linux you go from user space to kernel space via interrupt
0x80, using inline assembler... ref. <asm/unistd.hand
_syscallN() macros... right?
Well I didn't know that until you told me just now.
On Win32 you load kernel32.dll and call the functions via
functions pointers... right?
Well, not the way I'm doing it. I'm using the published
interface, which means I have coded CreateFile() in my
implementation of fopen(), which means I am polluting
the namespace.
So exactly how do the linker see any function names which
is invading the user name space?

What am I missing???
You're missing the fact that I thought it was a good idea to
use the OS's published interface, at least for Win32 and
OS/2. I didn't have this problem in DOS because the only
interface they provided was assembler interrupts. And
now I am looking into Unix and wondering what I should
use as the "official interface".

BFN. Paul.
Nov 19 '06 #18
"Keith Thompson" <ks***@mib.orgwrote in message news:ln************@nuthaus.mib.org...
I just tried a small test program that defines an external function
called "open". It worked with no problem. The systems I tried it on
also have a system function called "open";
Your test is inadequate because you wouldn't see the
problem unless you did an fopen() and suddenly your
code got executed by the C library.

BFN. Paul.
Nov 19 '06 #19
Paul Edwards skrev:
"Tor Rustad" <to********@hotmail.comwrote in message
Eric Sosman skrev:
>
Why is it better to pollute the user's namespace
with sys_open() than with open()?
[...]
On Linux you go from user space to kernel space via interrupt
0x80, using inline assembler... ref. <asm/unistd.hand
_syscallN() macros... right?

Well I didn't know that until you told me just now.
No problem.
On Win32 you load kernel32.dll and call the functions via
functions pointers... right?

Well, not the way I'm doing it. I'm using the published
interface, which means I have coded CreateFile() in my
implementation of fopen(), which means I am polluting
the namespace.
With the C compilers I have used at least, unless using
function pointers... a dynamicly linked Win32 function
was prefixed with:

__declspec(dllimport)

which translate e.g. CreateFile(...) into

__imp__CreateFile(...)

i.e. no polluting of user's name space at link time. I have
never used gcc on Win32... so if this is really a problem
in that environment, you can solve it by using another
C compiler.
So exactly how do the linker see any function names which
is invading the user name space?

What am I missing???

You're missing the fact that I thought it was a good idea to
use the OS's published interface, at least for Win32 and
OS/2. I didn't have this problem in DOS because the only
interface they provided was assembler interrupts.
Methinks, I'm not the one missing something here... ;-)

--
Tor

Nov 20 '06 #20
"Paul Edwards" <ke******@nosppaam.w3.towrites:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>I just tried a small test program that defines an external function
called "open". It worked with no problem. The systems I tried it on
also have a system function called "open";

Your test is inadequate because you wouldn't see the
problem unless you did an fopen() and suddenly your
code got executed by the C library.
Ok, I just tried that, and it worked fine, to my complete lack of
surprise. fopen() opened the file correctly, and strace shows calls
to the system's open() function; the program also called my own open()
function.

You didn't really expect a major implementation to get this wrong, did
you?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 20 '06 #21
Paul Edwards wrote:
"Tor Rustad" <to********@hotmail.comwrote in message
<snip>
On Linux you go from user space to kernel space via interrupt
0x80, using inline assembler... ref. <asm/unistd.hand
_syscallN() macros... right?

Well I didn't know that until you told me just now.
Any other way will cause your CRT to be dependant on another library in
the system, not the way I think that you want it.
On Win32 you load kernel32.dll and call the functions via
functions pointers... right?

Well, not the way I'm doing it. I'm using the published
interface, which means I have coded CreateFile() in my
implementation of fopen(), which means I am polluting
the namespace.
By 'coded' you do mean calling CreateFile() defined in kernel32.dll,
don't you. If so that won't pollute the namespace more than other C
libraries will do.
So exactly how do the linker see any function names which
is invading the user name space?

What am I missing???

You're missing the fact that I thought it was a good idea to
use the OS's published interface, at least for Win32 and
OS/2.
That's how it ought to be done. You're not polluting the namespace, the
OS is, and that's a restriction we've got to live with.
And
now I am looking into Unix and wondering what I should
use as the "official interface".
The system call interface exported by the kernel. For the case of Linux
under x86, it's through INT 0x80. Consult the kernel's source and
documentation for details.

Nov 20 '06 #22

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: JW | last post by:
Hi, I don't seem to get any results from the following use of Runtime.getRuntime().exec(cmd) using Java 1.4 on Redhat linux. Suppose that in the same directory as my java file below, I have...
3
by: K.S.Liang | last post by:
Hi all, 1> If there are more than one dynamic linking libraries in the file system, how do I know which one is loaded into system? Any C library or system call can tell me which *.so or *.sl is...
5
by: markus | last post by:
Hi, I have a question that deals with the standard c library VS (Unix) system calls. The question is: which header files (and functions) are part of the C library and which header files (and...
7
by: marek | last post by:
Dear colleagues, for one project, I need to link Turbo (or Borland) Pascal with (Turbo) C code. I would strongly like to avoid rewriting (my) C routines to Pascal (other part of project is under...
6
by: ritesh | last post by:
Hi, I have been reading some text on C and C++ (i.e advanced books). One of the books mentioned that C++ requires a runtime support whereas C does not - what the author was trying to say was...
36
by: lovecreatesbeauty | last post by:
In the C programming language, I/O operation functions are declared in stdio.h, for example, fopen(), fclose(), fwrite(), fread(), fseek() ... But another set of I/O functions are also defined in...
18
by: John Friedland | last post by:
My problem: I need to call (from C code) an arbitrary C library function, but I don't know until runtime what the function name is, how many parameters are required, and what the parameters are. I...
2
by: sealo | last post by:
Hello, How does the C# App search the library in the runtime? Say, I build a C# App A, which use B.dll, and B.dll use the C.dll. I specify the B.dll and C.dll path in the IDE, and build was...
20
by: J de Boyne Pollard | last post by:
MThe library functions which are included to allow process Mlaunch, forking, and termination, imply that it is both Mpossible and desirable for a process to fork itself. This is Ma fundamental...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.