►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
So
my
name
is
Philip
a
fun
fact
about
me:
I
adopted
a
puppy
this
week,
so
my
girlfriend
is
at
home,
taking
care
of
him.
Thank
you.
Daisy
and
I
work
for
this
company
called
Data
theorem.
We
do
application
security,
I
focus
on
like
static
analysis
of
iOS,
apps
and
you'll
notice,
this
company
logo
in
the
bottom
left
of
all
of
these
slides
and
what
that
means
is
that
I
got
a
free
plane
ticket
to
come
here.
So
thank
you,
data
theorem,
okay,
so
Axel
Lewis.
What
is
this?
A
A
A
So
this
is
the
window
manager
now
I'm
opening
the
file
browser
which
spoiler
alert
is
written
in
Rust
and
just
to
show
off
a
little
bit
I'm.
You
know
going
to
run
doom
and
let
that
load
and
run
around
a
little
bit
show
you
like
dragging
some
windows
around
and
you
know,
resizing
things.
Keyboard
and
mouse
input
all
pretty
standard
stuff,
but
there's
a
lot
that
it
takes
to
get
there.
A
Axel
was
written
in
lots
of
C
way
more
C
than
I
ever
intended
to
write
in
my
life,
but
here
we
are-
and
this
comes
with
you
know,
just
really
horrible
horrible
bugs
and
not
only
you
know,
really
difficult
bugs
in
kernel
space,
but
also
it's
just
an
ill-suited
tool
for
a
lot
of
the
things
that
I
want
to
do.
You
know,
building
desktop
applications.
A
Building
kind
of
you
know
more
high
level
productivity
software,
it's
just
it's
got
It's
just
too
difficult
and
I
was
looking
for
a
different
tool
to
use
so
I
evaluated
a
few
options.
I
looked
at
porting,
Zig,
C,
plus
plus
eventually,
thankfully
I
settled
on
Rust
and
I
ported
lib
C
at
the
end
of
2021..
So
I've
been
writing
a
lot
of
rust
in
Axel
for
about
a
year
now,
and
now
it's
very
much
the
language
of
choice,
for
you
know
any
any
new
code
in
axel.
A
So
this
is
Axel's
kind
of
historical
GUI
toolkit
which
is
written
in
C,
so
you've
got
all
the
kind
of
standard
widgets
that
you
would
expect
in
a
GUI
toolkit.
We've
got
you
know:
sliders
buttons,
sub
views,
pixel
buffers
all
that
sort
of
stuff
that
you
would
find
in
any
GUI
toolkit
and
again,
just
to
give
you
a
sense.
This
is
over
on
the
right.
We've
got
a
screenshot
of
the
logs
viewer
application
and
then
there's
the
code
for
it
over
on
the
left.
A
Of
course,
it's
in
C,
it's
only
about
30
lines.
It's
a
pretty
straightforward
program
and
there's
a
few
things.
I
want
to
point
out
here.
So
the
text
view
where
all
the
you
know
logs
are
drawn
into
it's
a
it's
Global
State
we've
got
this
callback,
that's
called
a
sizer
Sizer
callback,
and
so
the
way
that
this
works
is
anytime,
the
window
is
resized.
This
function
will
be
invoked
with
the
you
know,
size
of
the
parent
window,
and
then
it
returns
a
rectangle
that
the
text
view
should
now
occupy.
A
Of
course,
since
this
text
view
is
just
the
size
of
the
window,
it
just
Returns
the
window
size
that
was
passed
in
and
then
there's
this
message
Handler.
So
we'll
talk
a
little
bit
more
about
this
later
in
the
talk,
but
I
wanted
to
just
briefly
point
it
out
now
yeah
this
will
get
invoked
anytime.
A
message
is
sent
to
this
program.
A
So
there's
a
bunch
of
drawbacks
with
this
C
GUI
toolkit
it
enforces
the
use
of
you,
know:
Global
State,
it's
really
awkward
to
build.
Just
sort
of
you
know,
standard
uis
that
shouldn't
be
really
difficult
to
create.
Everything
is
awkward
and,
of
course
you
know,
the
major
problem
is
no
memory
protection,
not
unique
to
a
GUI
2
toolkit,
just
a
c
problem.
A
So
just
as
a
little
example
of
this
I've
made
a
silly
demo
program,
we've
got
two
views:
blue
one
and
a
red
one,
and
the
blue
view
is
going
to
just
turn
all
of
its
pixels
white
with
a
memsap.
The
problem
is
it's
a
little
bit
overzealous
with
the
memsap
and
you
can
see
there's
nothing
at
all,
stopping
it
from
just
overriding
all
the
other
pixels.
A
In
the
view
below
it,
and
there's
really
nothing
you
can
do
about
this
in
C,
so
I
rewrote
a
toolkit
in
Rust,
so
over
on
the
left
I've
got
a
window
using
the
sea,
GUI
toolkit
and
on
the
right,
a
program
using
the
rusquery
toolkit,
and
if
these
windows
look
pretty
much
the
same,
that's
really
good.
That
means
I've
done
my
job,
because
these
have
totally
different
underlying
implementations,
and
you
know
what
before
I
move
on
here.
Could
we
just?
Can
we
just
take
a
moment
and
check
out
those
Corners?
A
You
know
what
could
we
actually
get
the
action
cam
on
these?
That
would
be
yeah.
Thank
you
awesome.
So
I
spent
so
many
hours
of
my
life
getting
the
pixels
on
these
Corners
just
right
for
that
little
drop
shadow
effect
and
then
I
had
to
do
it
again
in
Rust,
so
not
fun,
but
hopefully
the
end
result
is,
you
know,
looks
nice
and
I
wasn't
kind
of
sure.
A
If
I
was
going
to
show
this,
because
you
know
it's,
no
secret
gooey
toolkits
in
Rust
are
not
an
easy
problem
for
a
number
of
reasons,
so
the
code
is
pretty
gross.
Even
in
Rust,
but
I
did
want
to
point
out.
This
is
the
code
for
that
rust
window
of
course,
and
then
we've
got
that
same
concept
of
a
size
or
callback,
a
closure
that
gets
invoked
whenever
the
window
was
resized
and
you
know
says
what
the
new
size
of
the
view
should
be
cool.
A
So
here's
the
comparison,
here's
some
historical
programs
over
on
the
left
using
the
sea,
GUI
toolkit
and
then
over
on
the
right,
some
newer
programs
written
in
the
rescue
toolkit.
So
on
the
top
there
is
a
file
browser
and
then
on
the
bottom
is
this
IDE
I've
been
working
on
where
you
can
write
x86
assembly
and
then
at
runtime.
It
gets
linked
and
loaded
into
a
you
know
an
executable
program,
the
dock.
You
couldn't
see
it
in
that
screenshot,
but
it's
also
written
in
Rust.
A
One
thing
that
I
think
is
cool
about
the
dock.
Is
it's
just
a
window
like
any
other?
It's
just
a
normal.
You
know
windowed
application,
there's
a
little
bit
of
hacks
in
the
window
manager.
So
it
doesn't.
You
know
it
can't
be
dragged
around
and
it
doesn't
have
the
title
bar
on
it,
but
otherwise
it's
just
a
window.
A
Okay.
So
let's
take
a
look
at
the
virtual
address
space
mappings
of
each
of
these
programs,
so
that
top
program
is
Axel's,
virtual
address
space,
visualizer
and
then
over
on
the
top.
We
have
the
virtual
memory
mappings
for
the
rust
GUI
toolkit
and
on
the
bottom
for
the
C.
Now,
if
we
look
at
the
virtual
memory,
mappings
here
we'll
see
some
pretty
standard
stuff.
You
know
over
on
the
left.
We've
got
the
code
segment
of
each
of
these
programs.
Then
we've
got
the
Heap.
A
The
stack
that
seven
megabytes
is
then
a
frame
buffer
and
there's
a
64
megabyte
space
that
we'll
talk
about
a
little
bit
later,
but
one
thing
that
you'll
notice-
if
you
look
at
this,
it
seems
a
bit
weird
is
the
memory
usage
for
the
C
GUI
toolkit
is
way
higher
than
for
the
rust.
The
Heap
in
the
C1
is
31
megabytes
versus
just
20
kilobytes
for
the
rust
one.
Why
is
that?
Well
in
the
sea
GUI
toolkit
anytime,
you
want
to
have
a
sub
view.
A
A
A
So
what
would
be
nicer
is
If.
Instead
of
you
know,
having
all
these
different
frame
buffers
that
we
then
composite
together
into
a
final
image.
We
could
have
some
kind
of
I,
don't
know
slicing
syntax,
where
you
could
just
get
like
a
reference
to
a
rectangle
of
pixels
that
you're
allowed
to
draw
into,
and
you
wouldn't
be
able
to
draw
outside
of
that
rectangle.
That
would
be
really
cool.
A
A
So
this
is
sort
of
the
bones
of
the
trait
that
I
ended
up
implementing
for
this.
The
idea
is
that
anytime,
a
sub
view
like
recurses
anytime,
it
wants
to
draw
something
else.
You
call
this
get
slice
and
it
returns
a
kind
of
smaller
slice,
and
then
you
can
use
all
of
these
methods
on
what
you
get
back
to.
You
know
gradually
build
up
The
View,
so
it's
really
cool
right.
A
So
we
could
take
a
kind
of
case
study
here
and
imagine
how
this
might
work
so
say:
you've
got
a
driver,
that's
listening
for
events
from
like
a
PS2
keyboard,
that's
plugged
into
the
machine,
and
then
you
know,
of
course,
that
keyboard
driver
is
going
to
eventually
want
to
tell
the
window
manager,
which
you
know
hosts.
All
the
windows
shows
the
desktop
environment
dispatches
input
when
the
user,
like
does
stuff.
Of
course,
the
keyboard
driver
is
going
to
want
to
tell
the
window
manager
hey
the
user
pressed
the
key.
A
You
know
you
should
forward
that
to
a
window
or
otherwise
do
something
with
it
and
the
way
that
it
does.
That
is
with
this
ciscal
axle
message
center
message
send,
so
it
would
send
this
keypress
event
to
the
window
manager.
The
window
manager
would
then
dispatch
it
appropriately,
but
of
course,
when
the
keyboard
driver
sends
this
event
to
the
window
manager,
the
window
manager
might
not
be
ready
to
receive
it.
The
window
manager
might
be
in
the
middle
of
you
know,
drawing
some
other
windows
handling
some
other
input.
A
So
the
way
that
this
works
is
that
for
every
AMC
service,
there's
a
kernel
level
message
queue
that
it
gets
so
here
we've
got
a
view
of
those
cues
in
the
kernel,
one
for
the
keyboard
driver
service,
the
mouse
driver,
The,
Window
Manager,
so
the
window
manager
might
have
some
queue.
I'm
sorry
might
have
some
messages
sitting
in
its
queue
and
then,
when
the
keyboard
driver
sends
that
message,
it'll
just
go
and
sit
in
that
queue.
A
So
this
is
kind
of
the
total
ciscal
body
and
what's
cool
is
that
this
is
actually
the
main
Cisco
surface
of
axillos.
Even
if
you
want
to
do
something
like
setting
up
a
shared
memory
mapping,
you
just
send
a
special
AMC
message
to
the
kernel
and
it'll
know
what
to
do
so.
Of
course,
I've
expressed
this
in
a
kind
of
you
know
rustified
syntax,
but
this
isn't
rust
code.
These
are
Cisco
vectors.
They
have
a
totally
different
calling
convention,
but
this
is
a
rust
conference.
So
I
wanted
to.
A
You
know,
give
a
sense
of
what
the
conventions
were
like
for
this
via
kind
of
rustified
syntax.
And
if
you
look
at
this
you'll
notice,
you
know
where
is
this
going
to
go?
Where
is
it
going
to
sit
in
memory?
Of
course
it
has
to
go
somewhere.
If
we're
saying
you
know,
give
me
a
message:
where
do
we
put
it
sort
of
visualize?
What
happens
here?
A
We
could
kind
of
imagine
the
virtual
address
space
mappings
of
a
process,
but
if
you
tried
to
do
this,
if
you
tried
to
take
the
virtual
address
space
mappings
of
a
process
and
then
lay
them
out,
you
know
left
to
right
into
a
diagram
like
this.
You
run
into
a
pretty
difficult
problem
and
and
putting
together
this
presentation,
I
had
a
lot
of
difficulty
figuring
out
how
you
would
kind
of
Solve
IT,
thankfully
I
finally
figured
it
out.
A
So
the
problem,
of
course,
is
that
if
you
did
try
to
lay
everything
out
from
left
to
right,
it
gets
really
cramped.
So
what
I
did
was
I
turned
it
90
degrees,
so
that's
all
solved,
and
now
we
can
just
list
the
virtual
memory
mappings.
So,
of
course,
at
the
bottom
of
the
address
space
you've
got
the
no
page,
then
you've
got
user
mode
code
directly.
Contiguous
with
that
is
the
stack
I'm.
Sorry,
the
Heap,
then
the
stack
higher
up
you've
got
kernel
mappings
that
are,
you
know,
shared
in
every
process.
A
A
A
A
So
the
kernel
queue
for
the
receiver
is
going
to
have
a
you
know
a
one
placed
into
it.
Then
it's
going
to
send
it
two
same
thing:
okay,
so
looking
at
the
receiver,
this
is
all
the
code
for
that,
of
course,
it's
going
to
set
itself
up
as
an
AMC
service,
and
then
it's
going
to
call
a
weight
twice
to
get
each
of
the
messages
so
the
first
time
it
calls
it.
The
kernel,
as
we
saw,
is
going
to
mem
copy
into
the
AMC
delivery
space.
A
Now
it's
going
to
call
away
again
and
it's
just
going
to
mem
copy
it
again
into
the
AMC
delivery
space,
but
message
one
is
still
in
scope.
The
thing
that
it's
pointing
to
has
just
been
overwritten.
This
is
not
good
and,
to
you
know,
see
exactly
why
this
isn't
good
I.
Have
this
log
line
just
down
at
the
bottom?
It's
printing
out
the
value
of
message,
one
a
second
time
after
we
call
the
wait
again
and
you
can
see
you
know
we
get
the
first
message.
A
A
So
of
course
you
know,
there's
straightforward
ways
to
get
around
this,
except,
for
example,
AMC
message.
Weight
could
just
copy
whatever
it
receives
to
somewhere
on
the
Heap,
but
I
thought
this
was
kind
of
you
know,
kind
of
interesting,
Matt,
I
didn't
know
if
there
was
any
kind
of
nice
way
to
express
in
Rust
that
the
thing
returned
by
this
is
valid.
You
know
until
the
next
call
to
nmc
message
await
and
I
would
be
interested
to
hear
of.
Anyone
has
ideas
on
how
to
express
that.
A
I
also
wrote
some
other
stuff
in
Rust
that
I
thought
I
would
mention
so
I
wrote
a
Game
Boy
emulator
in
Rust.
This
is
the
emulator
running
in
axle
running
Pokemon
Red.
That
was
really
fun.
Rust
is
really
nice.
For
this
sort
of
software,
it's
also
really
nice
for
just
kind
of
holding.
You
know
references
to
various
things
and
when
they
go
out
of
state
scope,
you
can
give
them
back
to
the
OS.
That's
really
cool.
A
Recently
I
wrote
an
ahc
driver,
an
ahci
driver
in
Rust
bit
tough
to
say
so.
What
that
is
is
if
you
want
to
talk
to
a
SATA
controller.
If
you
want
to
talk
to
an
SSD,
you
have
to
use
this
protocol
ahci,
so
I
wrote
a
you
know,
wrote
a
driver
for
that,
and
Russ
is
again
just
so
nice
for
this
sort
of
software.
A
It's
been
a
really
pleasant
experience,
especially
coming
from
so
much
sea
as
I
had
a
look
at
a
few
minutes
ago,
I
wrote
an
x8664
assembler
and
you
know:
Linker
I
wrote
the
nadrd
file
system
in
rust,
or
rather
rewrote
it,
and
I
also
rewrote
the
nrd
generator
in
Rust
and
I
have
more
plans
for
Russ
as
well.
The
window
manager
suffers
from
a
few.
A
You
know
memory,
corruption,
liabilities,
so
it'll
be
nice
to
rewrite
that
in
Rust
as
well.
There's
a
tcpip
stack
that
I
want
to
rewrite.
In
Rust,
it
also
has
you
know,
other
auxiliary
protocols
like
DNS
and
ARP,
so
I
want
to
rip
all
that
out,
rewrite
it
in
Rust,
I
want
to
write
a
GPT
disk
formatter,
so
I
could
get.
You
know
a
proper
file
system
sitting
on
a
hard
drive
and
I
want
to
take
that
x8664
assembler
that
I
mentioned
and
put
a
c
front
end
on
it.
A
B
C
C
Somebody
will
be
able
to
correct
me,
but
it's
like
you
can
know,
parameterize
your
type
with
const
so
like
maybe
with
an
integer
So
like
if
your
function
has
like
zero
as
a
parameter,
then
the
user.
The
space
is
already
taken,
and
you
cannot
override
this,
but
if
you're
free,
you
can
increment
this
and
you
have
like
one
space,
more
I
I'm,
not
sure
how
it
works.
I
did
not
play
much
with
it,
but
maybe
could
be
a
solution
to
your
your
little
problem.
That's
me.
No.