GNAT Ada - DLL - MSVC - debugging

GNAT Ada - DLL - MSVC - debugging

[Alderson, Paul A.]

Hello,

I am using the Gnat Ada compiler to produce an Ada DLL that is used by the
Microsoft Visual C++.
Currently everything is working, but I have no debugging information
available.  I have searched the web for a possible solution, but have found
no working solutions.
The reason I need to use Ada in a DLL in the C++ environment is because I am
attempting to save a large Ada development effort by adding a new GUI for
it.  Other Ada GUI's and compilers have been less than impressive.  This
solution seems to be working good, but it is difficult to debug.  If you
know of a good example of accessing debug information from MSVC using an Ada
DLL I would appreciate hearing about it.

Thanks
Paul Alderson

Re: GNAT Ada - DLL - MSVC - debugging

[David Marceau]

"Alderson, Paul A." wrote:
> 
> Hello,
> 
> I am using the Gnat Ada compiler to produce an Ada DLL that is used by the
> Microsoft Visual C++.
> Currently everything is working, but I have no debugging information
> available.  I have searched the web for a possible solution, but have found
> no working solutions.
> The reason I need to use Ada in a DLL in the C++ environment is because I am
> attempting to save a large Ada development effort by adding a new GUI for
> it.  Other Ada GUI's and compilers have been less than impressive.  This
Which Ada GUI's and compilers have you looked at?
Could you clarify how you arrived at your decision to go with MSVC++?
Which criteria did you use and how did you weigh them?
Is there someone pushing you politically to use MSVC/MS-windows or any
other tool for that matter?
Have you considered using Linux(or other UNIXES)/gnat/gtkada?
Have you consideted using Linux(or other UNIXES)/gnat/motif?
Using these alternatives, you can gnatmake -g and debug linux
dlls(shared libraries .so) 
with and gdb locally or remotely.

If you have seen/tried these, could you clarify why they aren't "working
solutions"?
> solution seems to be working good, but it is difficult to debug.  If you
> know of a good example of accessing debug information from MSVC using an Ada
> DLL I would appreciate hearing about it.
> 
> Thanks
> Paul Alderson

IMHO If you want to save your "LARGE ADA DEVELOPMENT EFFORT", continue
building your gui with ADA.
IMHO The flash file format(.swf) is a wonderful gui architecture.
Some beautiful examples:
http://www.simtlc.org/simtlcmain.htm
http://www.polaris-nl.com/sendacard.html
http://www.joecartoon.com/pages/nannahooter/

IMHO my dream multi-platform state-of-the-art gui:
1)The web browser itself and the web browser flash player plug-in should
be re-written in ada.
2)The ming flash file generation api for c/php/perl
http://sourceforge.net/projects/ming
  or swift api http://www.swift-tools.com/ or some other similar api...
 should be re-written in ada.
3)Start using an ada-based ming flash file generator for building the
gui.
4)In the back-end serving up all these files would obviously be AWS
http://libre.act-europe.fr/aws/

I hope this helps.

Sant� bonheur,
David Marceau

Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Simon Clubley]

In article <3D062F7D.406B8709@sympatico.ca>, David Marceau <davidmarceau@sympatico.ca> writes:
> 
> IMHO my dream multi-platform state-of-the-art gui:
> 1)The web browser itself and the web browser flash player plug-in should
> be re-written in ada.

I have been reading comp.lang.ada for about a year, and during that time
the wish for a web browser to be written in Ada has been made a number of
times.

So, my question is, why write a whole new web browser in Ada ?

Some advantages are obvious; an Ada browser shouldn't have problems with
buffer overflows.

However, I don't see how an Ada based browser would help with other
errors like cross-site scripting which I understand are mainly logic
errors.

Also, how much of the web browser would you write in Ada ? Just the core
of the browser or everything ?

To expand on that question:
	Would you write new Ada widgets to display JPEG/GIF/etc images,
	including the decoding/decompression of the image ?

	Would you write a Java Virtual Machine implementation in Ada ?

	How about FTP/Telnet/secure sockets, etc ?

What method would an Ada browser use to handle the requirement to
dynamically support plug-in modules and to execute the code within
that plug-in ? What would be the advantages of that method ?

And finally, would the work involved in writing an Ada browser be justified
by Ada's advantages ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       
Microsoft: The Lada of the computing world.

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[David Marceau]

Simon Clubley wrote:
> 
> In article <3D062F7D.406B8709@sympatico.ca>, David Marceau <davidmarceau@sympatico.ca> writes:
> >
> > IMHO my dream multi-platform state-of-the-art gui:
> > 1)The web browser itself and the web browser flash player plug-in should
> > be re-written in ada.
> 
> I have been reading comp.lang.ada for about a year, and during that time
> the wish for a web browser to be written in Ada has been made a number of
> times.
> 
> So, my question is, why write a whole new web browser in Ada ?
So the browser would be more reliable, more secure and more easily
maintained/reused.
Note how I didn't say it would be faster than assembler or c.

> 
> Some advantages are obvious; an Ada browser shouldn't have problems with
> buffer overflows.
Buffer overflows have been seen as security issues in os's.  
Ada helps to minimize this.  Unless you are deliberately using pointers
in your software,
Ada has a much stronger chance at not doing any buffer overflow.
Using pointers in Ada is much safer than in c/C++ 
because pointers in ada are harder to use(there are more steps involved
to use them).
This is by design(it's a feature).  

> 
> However, I don't see how an Ada based browser would help with other
> errors like cross-site scripting which I understand are mainly logic
> errors.
What do you mean by cross-site scripting?

> 
> Also, how much of the web browser would you write in Ada ? Just the core
> of the browser or everything ?
Everything.  A software(like a chain) is only as strong as its weakest
link.

> 
> To expand on that question:
>         Would you write new Ada widgets to display JPEG/GIF/etc images,
>         including the decoding/decompression of the image ?
Yes. For long-term multi-platform maintenance and reuse reasons. 
Nothing beats ada here IMHO.  Not even java.

> 
>         Would you write a Java Virtual Machine implementation in Ada ?
In my opinion it is a waste of time because assuming you have access to
the source, you could recompile on any platform quite easily.
The recompiled ada would be much faster than a JVM running java byte
code.  JAVA and jvm is hype IMHO.

> 
>         How about FTP/Telnet/secure sockets, etc ?
Sockets. Don't have to Adasockets
Secure sockets. Don't have to Adasockets
Http downloads/uploads binary files. Don't have to AWS.
FTP seems to be redundant now. No.
Telnet yes.  Great for debugging.
gdb yes.
ssh/ssl.   Yes and by far the most important for security reasons.

> 
> What method would an Ada browser use to handle the requirement to
> dynamically support plug-in modules and to execute the code within
> that plug-in ? What would be the advantages of that method ?
Dynamic run-time plug-ins are a security issue.
Making an architecture that permits dynamic loaded plug-ins that can
access the same piece of memory in a process is a hackers paradise.
(i.e. .so's/.dll's)
That's why having source is better.  You can decide to save disk
space(using .dll's/.so's) or not(using static .a's).
For security reasons, I prefer to think source and building the .a
myself is best.
Back to plug-in architecture I like AWS http://libre.act-europe.fr/aws/ 
because for each plug-in created, it is run as a separate process and
talking to the other process via a protocol 
hence protecting the original program from being tampered with via
memory. 
That doesn't mean your code will remain hack-proof:
-some engineers have devised cool electromagnetic ray guns
reading/changing bits in your computers's memory hence changing your
code.  There is nothing ada can do here.
-some other engineers are pros at sniffing protcols and tweaking bits
here and there.  The least it can do is protocol-jam however there is
potential for more damage.  Ada at least reduces the risk of this
happening.
-some other pros can go into your office duplicate and swipe your hard
drive.  Change stuff then swipe it back in.  There is nothing ada can do
here.

The above is not sci-fi.  It exists.  Hence e-commerce confidence going
doing the tubes.
Case in point check out all the hackers making money off of duplicating
satellite-tv/pay-tv smart-cards.  
I've been offered many-a-time to buy one.
Recently here in Montreal, Canada a couple of pros stole credit card
making machines and Provincial Medical Card making machines.
They made a mint off of making fake Medical ID's with which they used do
get Credit card's with.

The possibilities of people hacking into your machine are there 
but the motivation to do so is only there if there are others who
perceive your machine has something of value worth hacking into.
> 
> And finally, would the work involved in writing an Ada browser be justified
> by Ada's advantages ?
To reiterate it again.  Writing an ada browser
would be justified by just its multi-platform long-term maintenance and
reuse alone.  
However it is even more justified for its security and reliability
strengths.  
If you feel strongly about writing code that will surpass your lifetime,
write it in ada.
It will have a better chance at not getting scrapped.

Sant� bonheur,
David Marceau

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Darren New]

David Marceau wrote:
> >         Would you write a Java Virtual Machine implementation in Ada ?
> In my opinion it is a waste of time because assuming you have access to
> the source, you could recompile on any platform quite easily.
> The recompiled ada would be much faster than a JVM running java byte
> code.  JAVA and jvm is hype IMHO.

Errr, except for the web sites that have Java on them, yes? I mean, how are
you going to run a java applet off a web site if you don't have a JVM in
your browser?

> >         How about FTP/Telnet/secure sockets, etc ?
> Sockets. Don't have to Adasockets
> Secure sockets. Don't have to Adasockets
> Http downloads/uploads binary files. Don't have to AWS.
> FTP seems to be redundant now. No.

Um, ... no, it's not. 

> Telnet yes.  Great for debugging.
> gdb yes.
> ssh/ssl.   Yes and by far the most important for security reasons.

You missed smtp and nntp.
 
> > What method would an Ada browser use to handle the requirement to
> > dynamically support plug-in modules and to execute the code within
> > that plug-in ? What would be the advantages of that method ?
> Dynamic run-time plug-ins are a security issue.

That's the point. The question is how Ada would make run-time plug-ins
safer, and the answer is that it wouldn't.

If you're not going to support the modern stuff, there's no need to rewrite
in Ada at all. Just install Mosaic.

> Back to plug-in architecture I like AWS http://libre.act-europe.fr/aws/
> because for each plug-in created, it is run as a separate process and
> talking to the other process via a protocol
> hence protecting the original program from being tampered with via
> memory.

That doesn't make it secure, tho. That just makes it secure from buffer
overruns. Nothing keeps that other process from breaking into your machine
in other ways.

It also means that every plug-in you create use has to be rewritten from
scratch as well. Are you also going to rewrite Flash etc? Sounds like a
rather big job.

> The above is not sci-fi.  It exists.  Hence e-commerce confidence going
> doing the tubes.

This is news to me. But I think we're getting way off-topic.

> If you feel strongly about writing code that will surpass your lifetime,
> write it in ada.

If you think FTP is now obsolete, what makes you think HTTP won't be just as
obsolete before you die? HTML has been around what, 15 years? And if it
wasn't so entrenched, it would be completely replaced by XML already. Java
will likely suffer a similar fate at the hands of .NET. So why would one
worry about the decades-long maintainability of a client for a server that
likely won't be around in 5 years? :-)

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[David Marceau]

Darren New wrote:
> 
> David Marceau wrote:
> > >         Would you write a Java Virtual Machine implementation in Ada ?
> > In my opinion it is a waste of time because assuming you have access to
> > the source, you could recompile on any platform quite easily.
> > The recompiled ada would be much faster than a JVM running java byte
> > code.  JAVA and jvm is hype IMHO.
> 
> Errr, except for the web sites that have Java on them, yes? I mean, how are
> you going to run a java applet off a web site if you don't have a JVM in
> your browser?
That's my point.  I would prefer not to push java byte code across the
net.
I would prefer pushing flash file format which may have some script 
dependencies that ressemble java (i.e actionscript) however there is
nothing stopping another flash player 
from having another script language(i.e. ada itself).

> 
> > >         How about FTP/Telnet/secure sockets, etc ?
> > Sockets. Don't have to Adasockets
> > Secure sockets. Don't have to Adasockets
> > Http downloads/uploads binary files. Don't have to AWS.
> > FTP seems to be redundant now. No.
> 
> Um, ... no, it's not.
I'm human :)

> 
> > Telnet yes.  Great for debugging.
> > gdb yes.
> > ssh/ssl.   Yes and by far the most important for security reasons.
> 
> You missed smtp and nntp.
I'm human :)
> 
> > > What method would an Ada browser use to handle the requirement to
> > > dynamically support plug-in modules and to execute the code within
> > > that plug-in ? What would be the advantages of that method ?
> > Dynamic run-time plug-ins are a security issue.
> 
> That's the point. The question is how Ada would make run-time plug-ins
> safer, and the answer is that it wouldn't.
I will attempt to clarify why I believe ada is safer for creating
dynamic run-time plugins.

Firstly there are two types of dynamic run-time plug-ins:
1)in-process(dll COM objects as Microsoft calls them)
	As you know they may be gui or non-gui plugins.
	If one instantiates an untrusted third party in-process plug-in, 
	we can expose the original executing process to unwanting hacking 
	since they share the same machine and user privileges as the original
executing process.
2)out-of-process(EXE COM objects as Microsoft calls them)  plug-ins.
	As you know they may be gui or non-gui plug-ins.
	If one instantiates an untrusted third party out-of-process plug-in,
	the original executing process' memory remains less vulnerable to
outside attacks for two reasons.
	The out-of-process plug-in doesn't necessarily have to run on the same
machine as the original executing process.
	The out-of-process plug-in doesn't necessarily have to run with the
same user privileges.

Secondly, if you examine the AWS approach, you will note I am talking
out-of-process plugins.
I am explicitly declaring the AWS approach as a sound approach for the
above reason of separate machine and separate user privileges.
> That's the point. The question is how Ada would make run-time plug-ins
> safer, and the answer is that it wouldn't.
Ada by design makes safer executables than c/c++/java.  Thus is will
make safer out-of-process plugins gui and non-gui ones.
In a web browser(ada compiled or not) you don't necessarily have to
design it to invoke its plugins with the same user privileges.
That's what would make an ada-based browser with ada-based plug-in safer
to run and use.
If you don't agree with me then please clarify this or perhaps I will
consider you as a comp.lang.ada flaming MicroSerf.

Again feel free to check out a clear example with excellent
documentation
AWS plug-in architecture AWS http://libre.act-europe.fr/aws/ 

Sant� bonheur,
David Marceau
He who lies on the ground shall never fall off. Sun Tzu

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Darren New]

David Marceau wrote:
> > That's the point. The question is how Ada would make run-time plug-ins
> > safer, and the answer is that it wouldn't.
> I will attempt to clarify why I believe ada is safer for creating
> dynamic run-time plugins.

I think we're talking at cross purposes. Unless you're going to reimplement
*every* plug-in in Ada, the plug-ins you don't reimplement will have the
same security problems. 

That is, sure, you can implement a Flash player or a ReadVideo player in Ada
and perhaps fix some security bugs by doing so. But making your web browser
secure and still having it invoke RealVideo's player isn't going to be any
safer.
 
> Firstly there are two types of dynamic run-time plug-ins:
> 1)in-process(dll COM objects as Microsoft calls them)
>         As you know they may be gui or non-gui plugins.
>         If one instantiates an untrusted third party in-process plug-in,
>         we can expose the original executing process to unwanting hacking
>         since they share the same machine and user privileges as the original
> executing process.

I don't know of any way to change this on UNIX unless your web browser is
setuid to root, and that's just asking for trouble. That is, how does one
invoke a plug-in that is "safe" as a separate UNIX process, if you don't
start with root privs?

>         The out-of-process plug-in doesn't necessarily have to run on the same
> machine as the original executing process.
>         The out-of-process plug-in doesn't necessarily have to run with the
> same user privileges.

Well, yah, under Windows, it does. Especially under Windows 9x and
derivatives thereof.
 
> > That's the point. The question is how Ada would make run-time plug-ins
> > safer, and the answer is that it wouldn't.
> Ada by design makes safer executables than c/c++/java.

I'll grant you that's true of C and C++, but not Java.

>  Thus is will
> make safer out-of-process plugins gui and non-gui ones.

Doesn't follow. Especially if your out-of-process plugins are not in Ada.

I won't argue that rewriting all the network code in Ada would increase
security. I just don't think it's likely to happen any time soon, due to
non-technical reasons.

> In a web browser(ada compiled or not) you don't necessarily have to
> design it to invoke its plugins with the same user privileges.

I think the security of most common OSes would prevent you from doing
otherwise. 

> That's what would make an ada-based browser with ada-based plug-in safer
> to run and use.
> If you don't agree with me then please clarify this or perhaps I will
> consider you as a comp.lang.ada flaming MicroSerf.

No, if you rewrite everything in Ada with the primary concern being to
prevent plug-ins from doing nasty things, you'll get better security. Using
existing plug-ins with an ada-based browser probably won't help much.
Rewriting all existing plug-ins when a majority of people use single-user
OSes to browse the web doesn't help.
 
-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[David Marceau]

> I think we're talking at cross purposes. Unless you're going to reimplement
> *every* plug-in in Ada, the plug-ins you don't reimplement will have the
> same security problems.
That is exactly the intent.  Change the architecture of the main
application the web browser,
and change the architecture of the subsystems the Flashplayer and
whatever else plugins matter to you.

This implied re-writing the web browser in ada.
This implied re-writing the flash player in ada. 

The way the system would work.
1)user invokes the web browser
2)user invokes some flash file by opening it.
3)the web browser detects the type for the file to open
4)the web browser then invokes into another process a
decoration-less/decorated window placed within/outside the web browser
window.
5)the flash plug-in loads the desired user file via the protocol between
the two processes.  
Note how the plug-in accesses its resources.  Via the protocol back to
the web browser.  
Note the web browser commands the file the plug-in is to use.  
Note the plug-in asks for URL'S from the web browser. it can't open them
itself.
Anything else the plug-in tries to do forget it.  
To draw, the plug-in asks the web browser api.  The window device
context never directly gets into the hands of a plug-in.
To get input/output from other devices(i.e. mouse), the plug-in would
ask the web browser api.  The device itself never gets into the hands of
the plug-in.
In other words the plug-in would request a
drawing/filewriting/filereading/mousereading service from the web
browser.
The web browser with its multiple tasks would then actually do the
drawing/filewriting/filereading/mousereading after doing some security
checks.
The web browser owns the mouse and whatever else devices.  The plug-in
owns nothing. Doesn't matter whether it's a flash player or a video
player ...

> 
> That is, sure, you can implement a Flash player or a ReadVideo player in Ada
> and perhaps fix some security bugs by doing so. But making your web browser
> secure and still having it invoke RealVideo's player isn't going to be any
> safer.
I beg to differ since I have from the beginning implied re-writing
everything browser and all plug-ins.
IMHO It would be safer more maintainable and more platform-independant
reusable.
Note how I didn't say faster.

One more thing someone implied re-writing a jvm in ada.
I will clarify this.  The intent is not to run java-byte-code in the
so-called ada-web-browser.
The intent is to purely run ada code in the ada-web-browser and
preferrably straight from source one builds himself.
Yes the plug-in mechanism should provide something for downloading all
the source for a new plug-in and recompile on the machine.
Yes this implies gnat-ada-web-browser-plug-in-compiler which is I'm
guessing something that would verify that the plug-in source code only
with's in 
calls from the ada-web-browser-plugin-api package and nothing else.
Operating System specific calls would not get compiled in.  How to do
this?  I don't know.  Maybe something like j2me(java language subset for
cell phones and palm pilots) code converter/preverifier? It may be like
a jvm but I don't think it is a jvm.  The intention is to run the
original and unique ada-run-time-environment which gets linked into the
plug-in.  Maybe the ada-rte could be considered an avm :)  Maybe
removing os-specific calls and adding the ada-web-browser-plugin-api to
the ada-rte would more like an ADA Virtual MACHINE if there would be
such a thing.
I am just dreaming.  
When embedding stuff in html using why not provide url's to cvs source
code server.
Most of the unix world is doing this outside of their web browser for
getting source all over the world anyways.
I'm dreaming.  I'm human.  As you can see I'm venting my frustration
with the status-quo so I apologize to anyone I have offended.
How did I get to wanting a better browser?
In windows internet explorer, I went to some web sites heavy with
javascript i.e. www.act.com (the contact manager s/w) and it crapped out
my windows os.
I needed to reboot.  
On my linux box running netscape, I do the same thing.  I go to
www.act.com.  It craps outs netscape, but not my linux box.  I just
xkill on netscape and just restart it up and everything's fine.  At
least in linux it's just annoying.  In windows however it was
intolerable.  
IMHO Seeing this kind of bug appear again and again after a couple of
years, I believe this stuff shouldn't happen and 
the jvm/javascript engines along with the current web browser
implementations are the source of these problems.  
That's how I got to dreaming of this Ada-Web-Browser and
Ada-Web-Browser-Plugin idea :)

Sant� bonheur,
David Marceau

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[BraveNewWhirl]

.fr/aws/ 
> 
> Sant� bonheur,
> David Marceau
> He who lies on the ground shall never fall off. Sun Tzu

he who makes up stupid - allegedly Sun Tzu sayings - shall be forever deemed dumb.

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[David Marceau]

BraveNewWhirl wrote:
> 
> .fr/aws/
> >
> > Sant� bonheur,
> > David Marceau
> > He who lies on the ground shall never fall off. Sun Tzu
> 
> he who makes up stupid - allegedly Sun Tzu sayings - shall be forever deemed dumb.
I never deemed myself to being anything but human.
I'm human like yourself.  We all make brain farts just like what you
just did.
Mr. BraveNewWhirl, if you don't anything constructive to add to this
comp.lang.ada discussion
you 1000-flea-infested-camel go dump your crap somewhere else. 
:)

Sant� bonheur,
David Marceau

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[BraveNewWhirl]

> > he who makes up stupid - allegedly Sun Tzu sayings - shall be forever deemed dumb.
> I never deemed myself to being anything but human.
> I'm human like yourself.  We all make brain farts just like what you
> just did.
> Mr. BraveNewWhirl, if you don't anything constructive to add to this
> comp.lang.ada discussion
> you 1000-flea-infested-camel go dump your crap somewhere else. 
> :)
> 
> Sant� bonheur,
> David Marceau

Youah criticize mah camel youah criticize me. Az yew bee a tek weenie
ah donna care nohow. So pizz off in return.

Your gud health this gud hour(English version)
Dave

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Randy Brukardt]

Darren New wrote in message <3D076F21.E0CB708E@san.rr.com>...
>David Marceau wrote:
>> >         Would you write a Java Virtual Machine implementation in
Ada ?
>> In my opinion it is a waste of time because assuming you have access
to
>> the source, you could recompile on any platform quite easily.
>> The recompiled ada would be much faster than a JVM running java byte
>> code.  JAVA and jvm is hype IMHO.
>
>Errr, except for the web sites that have Java on them, yes? I mean, how
are
>you going to run a java applet off a web site if you don't have a JVM
in
>your browser?


Why would you want to do that? It's unsafe and time consuming; I have
all of that stuff disabled (and Java script) in every web browser I use.
Gets rid of a lot of pop-up ads and other nonsense.

If you really care about security, etc., you won't run plugins at all.
If you do run them now, then of course an Ada solution won't buy you
anything (you've already given up on any real security). Keep using what
you are using now.

               Randy.

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Darren New]

Randy Brukardt wrote:
> Why would you want to do that?

Heck, why would you want HTML at all? Just use plain ASCII.

> It's unsafe and time consuming; I have
> all of that stuff disabled (and Java script) in every web browser I use.
> Gets rid of a lot of pop-up ads and other nonsense.

Well, yeah, OK, if you write a web browser that doesn't invoke any code
outside the web browser itself, then sure, you'll be more safe, especially
if you check all your array bounds and such.
 
> If you really care about security, etc., you won't run plugins at all.
> If you do run them now, then of course an Ada solution won't buy you
> anything 

That's pretty much what I'm trying to say, yes.

Then I questioned whether anyone wants a web browser that by design can not
see many of the sites being designed nowadays. If so, like you say, just
turn all that junk off. Or go back to using Lynx.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **

     My brain needs a "back" button so I can
         remember where I left my coffee mug.

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Larry Kilgallen]

In article <ugfa6fla9p1j9a@corp.supernews.com>, "Randy Brukardt" <randy@rrsoftware.com> writes:

> If you really care about security, etc., you won't run plugins at all.

I consider myself rather careful about security, but I run the Adobe
Acrobat plugin without concern.  Of course I did not copy it over a
network, it came via the post office.

Plugin is a communication technique, quite unrelated to issues of how
the software was obtained and with what vendor guarantees.

OT: Adobe Acrobat Plugin

[Frank J. Lhota]

> I consider myself rather careful about security, but I run the Adobe
> Acrobat plugin without concern.

The Acrobat plug-in has caused me all sorts of grief. I generally try to
download PDF files before opening them, because the plug-in seems to have
problems unloading itself, and frequently hangs IE / Win9x in the process.
Yes, I've tried uninstalling and reinstalling it, and I'm not the only one
complaining about this.

If anyone here knows of a fix, other than rewriting the plug-in in Ada,
please let me know.

Re: OT: Adobe Acrobat Plugin

[Larry Kilgallen]

In article <sj2O8.37511$gs4.5803@nwrddc02.gnilink.net>, "Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:
>> I consider myself rather careful about security, but I run the Adobe
>> Acrobat plugin without concern.
> 
> The Acrobat plug-in has caused me all sorts of grief. I generally try to
> download PDF files before opening them, because the plug-in seems to have
> problems unloading itself, and frequently hangs IE / Win9x in the process.
> Yes, I've tried uninstalling and reinstalling it, and I'm not the only one
> complaining about this.

I have never had that problem.

> If anyone here knows of a fix, other than rewriting the plug-in in Ada,
> please let me know.

Since you insist...

		Get a Mac.

:-)

Re: OT: Adobe Acrobat Plugin

[Warren W. Gay VE3WWG]

Frank J. Lhota wrote:

>>I consider myself rather careful about security, but I run the Adobe
>>Acrobat plugin without concern.
>>
> 
> The Acrobat plug-in has caused me all sorts of grief. I generally try to
> download PDF files before opening them, because the plug-in seems to have
> problems unloading itself, and frequently hangs IE / Win9x in the process.
> Yes, I've tried uninstalling and reinstalling it, and I'm not the only one
> complaining about this.
> 
> If anyone here knows of a fix, other than rewriting the plug-in in Ada,
> please let me know.


Moving beyond Win9x will help. ;-)

Warren.

Re: OT: Adobe Acrobat Plugin

[Ted Dennison]

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> wrote in message news:<sj2O8.37511$gs4.5803@nwrddc02.gnilink.net>...
> The Acrobat plug-in has caused me all sorts of grief. I generally try to
> download PDF files before opening them, because the plug-in seems to have
> problems unloading itself, and frequently hangs IE / Win9x in the process.
> Yes, I've tried uninstalling and reinstalling it, and I'm not the only one
> complaining about this.
> 
> If anyone here knows of a fix, other than rewriting the plug-in in Ada,
> please let me know.

You could try Mozilla. They at least should not have an unfixed crash
bug like this any more (and if they do, in theory *you* could fix it).

-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  (temporarily down)

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Simon Clubley]

In article <3D0761FF.38554417@sympatico.ca>, David Marceau <davidmarceau@sympatico.ca> writes:
> Simon Clubley wrote:
>> 
>> So, my question is, why write a whole new web browser in Ada ?
> So the browser would be more reliable, more secure and more easily
> maintained/reused.
> Note how I didn't say it would be faster than assembler or c.
> 

I agree about it not needing to be faster than the _same_ program written
in C. I would even accept it been a little slower. However, I would like
to think that a properly designed Ada browser would need less resources
than some of today's browsers.

>> 
>> Some advantages are obvious; an Ada browser shouldn't have problems with
>> buffer overflows.
> Buffer overflows have been seen as security issues in os's.  

In this case, the buffer overflow is not in the operating system, but
in the browser. The idea is that an attacker can construct a malformed
response to a request from the browser that causes the browser's stack to
be overwritten because of a buffer overflow. Buffer overflow attacks have
been usually carried out against web servers, but browsers can be vulnerable.
See for example:

http://www.microsoft.com/technet/security/bulletin/MS02-027.asp

> Ada helps to minimize this.  Unless you are deliberately using pointers
> in your software,
> Ada has a much stronger chance at not doing any buffer overflow.

Agreed.

>> 
>> However, I don't see how an Ada based browser would help with other
>> errors like cross-site scripting which I understand are mainly logic
>> errors.
> What do you mean by cross-site scripting?
> 

Cross-site scripting is where an attacker can get a script to execute
within a more trusted local zone within the browser. This is normally an
attack used with the help of a web server, but a web browser itself can be
targetted.

A cross-site scripting tutorial that I found while typing this response is at:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q252985

and here's an example of it targetting IE itself:

http://www.microsoft.com/technet/security/bulletin/MS02-023.asp

Another variant is a frame based scripting attack, see:

http://www.microsoft.com/technet/security/bulletin/MS02-009.asp

You may argue that the cross-site scripting attacks are not the kind of
thing that Ada could be reasonably expected to stop. However, in that case,
the fact that the browser is written in Ada would probably make no difference.

Regardless of the above, I would argue that a frame based attack _is_ a
logic error, and I don't see how an Ada browser would stop that kind of
logic error from occuring just because it's written in Ada.

>> 
>>         Would you write a Java Virtual Machine implementation in Ada ?
> In my opinion it is a waste of time because assuming you have access to
> the source, you could recompile on any platform quite easily.
> The recompiled ada would be much faster than a JVM running java byte
> code.  JAVA and jvm is hype IMHO.
> 

You may have misunderstood me here. I am talking about the Ada web browser
needing to run a Java applet located on the site that the user is visiting.
In order to do this, the browser needs to have a JVM built into it. The
question is, do you use an existing JVM, or do you write a new JVM in Ada ?

>> 
>>         How about FTP/Telnet/secure sockets, etc ?
> Sockets. Don't have to Adasockets
> Secure sockets. Don't have to Adasockets
> Http downloads/uploads binary files. Don't have to AWS.
> FTP seems to be redundant now. No.
> Telnet yes.  Great for debugging.
> gdb yes.
> ssh/ssl.   Yes and by far the most important for security reasons.
> 

I don't see how gdb fits in.

FTP is not redundant. The question is, would it be worth it to re-implement
things like Telnet and FTP in Ada ?

BTW, I didn't realise that Adasockets had SSL. I will have to have a look...

>> 
>> What method would an Ada browser use to handle the requirement to
>> dynamically support plug-in modules and to execute the code within
>> that plug-in ? What would be the advantages of that method ?
> Dynamic run-time plug-ins are a security issue.
> Making an architecture that permits dynamic loaded plug-ins that can
> access the same piece of memory in a process is a hackers paradise.
> (i.e. .so's/.dll's)
> That's why having source is better.  You can decide to save disk
> space(using .dll's/.so's) or not(using static .a's).
> For security reasons, I prefer to think source and building the .a
> myself is best.

Here, you seem to be suggesting that if a user wants to run a new plug-in
that a third party has developed, or for a protocol that may have not have
existed when the browser was created, then the user should download
the source code and recompile the web browser.

If so, such an approach would make sure that an Ada web browser would never
be in general use (IMHO), unless it offered major advantages to the end user.

Assuming that dynamic plug-ins are required, is there anything that Ada
can teach us about a more secure way to implement the architecture ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP       
Microsoft: The Lada of the computing world.

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Preben Randhol]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote on 13/06/2002 (00:39) :
> I agree about it not needing to be faster than the _same_ program written
> in C. I would even accept it been a little slower. However, I would like
> to think that a properly designed Ada browser would need less resources
> than some of today's browsers.

HTML is completely screwed up. If you build a browser following the
guidelines and DTDs then 70% or perhaps more of the web sites won't be
displayed in the way they was intended. The reason is browsers have
never followed the standard and HTML is very weakly typed (like closing
tags are not necessary always etc..) So the problem becomes that the
browser is left to try to repair the mangled web pages and display them
without crashing. Therefore XHTML was made in order for handhelds and
others to be able to process homepages with their limited CPU power.

Another problem is that most users want to look at a page as fast as
they can. They don't want to wait for the whole file and all pictures
etc to be loaded before the file is displayed. So then you have to try
to do all the processing right away as it loads and this is not so easy
with HTML.

What I would like to see is a XHTML widget (using GtkAda). I mean that
the widget will only displays XHTML. Then it can also be used for other
purposes like Help dialogs etc... Then I would have a HTML -> XHTML
converter seperate from this. 

-- 
Preben Randhol         �For me, Ada95 puts back the joy in programming.�

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Jeffrey Carter]

Simon Clubley wrote:
> 
> So, my question is, why write a whole new web browser in Ada ?

I would like a browser that is more reliable that the existing ones,
which crash regularly. Engineering a browser in Ada is likely to produce
a more reliable application.

I would like a browser/mail reader/news reader that is more secure than
the existing ones. Engineering it in Ada would be very helpful in
achieving that.

I would like a browser that gives the user control over what the browser
does, not the web page author. The page may request downloading a huge
graphic from ads.ripoff.com, but the user decides whether it does or
not. Cookie management built in. Cache management. The ability to go
back using the cache, not reloading the page. And so on. Writing a
browser from scratch is one way to achieve this. If you're going to do
that, then you might as well make it reliable and secure by doing it in
Ada.

Finally, if there did exist an open-source browser that was reliable,
secure, and gave the user control of the process, I suspect it would
become fairly popular. People would look at the source to see why it's
so much more reliable/secure/whatever than other browsers, and see that
it was in Ada. They might suspect that Ada had something to do with its
good features. More people might decide to use Ada in the future as a
result.

-- 
Jeff Carter
"You empty-headed animal-food-trough wiper."
Monty Python & the Holy Grail

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Hyman Rosen]

Jeffrey Carter wrote:
> Finally, if there did exist an open-source browser that was reliable,
> secure, and gave the user control of the process, I suspect it would
> become fairly popular. People would look at the source to see why it's
> so much more reliable/secure/whatever than other browsers, and see that
> it was in Ada. They might suspect that Ada had something to do with its
> good features. More people might decide to use Ada in the future as a
> result.

The closest thing we have to this now is Mozilla, which is in C++.

It will be interesting to see how well GPS turns out.

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Ted Dennison]

Jeffrey Carter <jrcarter@acm.org> wrote in message news:<3D07A6FE.C6BF8CB0@acm.org>...
> I would like a browser that is more reliable that the existing ones,
> which crash regularly. Engineering a browser in Ada is likely to produce
> a more reliable application.

You've had Mozilla 1.0 crash on you? I hasn't done that on me yet in
over a week of use. That's pretty darn good for a big program (written
in any language).

> I would like a browser/mail reader/news reader that is more secure than
> the existing ones. Engineering it in Ada would be very helpful in
> achieving that.

I've yet to hear of a security exploit in the Mozilla mail reader
(that isn't caused by embedded JavaScript anyway, and you can turn
that off).

> I would like a browser that gives the user control over what the browser
> does, not the web page author. The page may request downloading a huge
> graphic from ads.ripoff.com, but the user decides whether it does or
> not. Cookie management built in. Cache management. The ability to go
> back using the cache, not reloading the page. And so on. Writing a
> browser from scratch is one way to achieve this. If you're going to do

Downloading Mozilla is too. It gives you all that. For instance, you
can forbid loading of images from a set of websites that you specify,
turn them all off, or require your interactive permission for any
image to load. You can look at and delete your cookies at will,
disable them entirely, disable them only in mail and news, require
interactive permission from you before storing them, etc.


-- 
T.E.D. 
Home     -  mailto:dennison@telepath.com (Yahoo: Ted_Dennison)
Homepage -  (temporarily down)

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Ed Falis]

On 13 Jun 2002 08:50:16 -0700
dennison@telepath.com (Ted Dennison) wrote:

> You've had Mozilla 1.0 crash on you? I hasn't done that on me yet in
> over a week of use. That's pretty darn good for a big program (written
> in any language).

Hasn't run yet on my Debian installation since I put it up a couple of
days ago. Starts and ends without a message or a window appearing.
Probably doesn't like my old settings. Blech.

- Ed

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Ted Dennison]

Ed Falis wrote:
> Hasn't run yet on my Debian installation since I put it up a couple of
> days ago. Starts and ends without a message or a window appearing.
> Probably doesn't like my old settings. Blech.

The instructions for Windoze strongly suggest uninstalling any old 
versions before installing 1.0. The one time I didn't do that, I 
regretted it.

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[Preben Randhol]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

Jeffrey Carter <jrcarter@acm.org> wrote on 13/06/2002 (00:41) :
> 
> I would like a browser/mail reader/news reader that is more secure than
> the existing ones. Engineering it in Ada would be very helpful in
> achieving that.

Why on earth do you want to put all these things into single
application? I would rather have two optimised applications that can
talk to eachother then one single application. One reason is that each
project would be smaller. The other is that when I use a web browser I
don't want to be forced to also have its mail reader installed as I
might want to use some other program or visa versa. At the moment I use
Galeon (a web browser only) which uses the Mozilla redering engine.

-- 
Preben Randhol         �For me, Ada95 puts back the joy in programming.�

Re: Why write an Ada web browser ?, was: Re: GNAT Ada - DLL - MSVC

[David Marceau]

Preben Randhol wrote:
> 
> Jeffrey Carter <jrcarter@acm.org> wrote on 13/06/2002 (00:41) :
> >
> > I would like a browser/mail reader/news reader that is more secure than
> > the existing ones. Engineering it in Ada would be very helpful in
> > achieving that.
> 
> Why on earth do you want to put all these things into single
> application? I would rather have two optimised applications that can
> talk to eachother then one single application. One reason is that each
> project would be smaller. The other is that when I use a web browser I
> don't want to be forced to also have its mail reader installed as I
> might want to use some other program or visa versa. At the moment I use
> Galeon (a web browser only) which uses the Mozilla redering engine.
> 
> --
> Preben Randhol         �For me, Ada95 puts back the joy in programming.�
I apologize for not being clear.  I meant different applications: 
ada-web-browser, ada-mail-reader, an ada-news-reader.
That said the underlying infrastructure. i.e. sockets, ssl,
widgets(gtkada like) it's understood could be shared among them.

Concerning your reference to Mozilla, IMHO this dream ada-web-browser is
not just a re-write of Mozilla in Ada; 
it's an overhaul of the architecture with different priorities in the
requirements.
Some algorithms could be inspired from Mozilla however 
the ada-web-browser architecture must ensure security, reliability and
long-term maintenance 
are the top-priority requirements for every service in every api.
IMHO as a consequence of in-process XP-COM being insecure, if any XP-COM
is used 
in the ada-web-browser-architecture at all, it should be out-of-process.
I've explained why out-of-process is better in a previous CLA email.

What are the first steps in order to encourage this further?
I would recommend having a good understanding of Mozilla core though
before embarking into this.
Deciding which gui with ada is a good question.
I would propose whatever is written should be isolated from the gui
anyways in order to switch gui sdks for different reasons.
I could name a few good reasons for this: 
1)embedded system single purpose gui target and 
2)Win32 and X-Window targets
Note how I intentionally left JVM out of this.  
The infrastructure built on top of target 1) and 2) will deal with
secure out-of-process plug-ins compiled for the target in-mind.
I like the ada mentality of dare I say "write once, compile everywhere
once" :)  But who's kidding who.  Reality is there are many versions of
JVM for every machine/OS(i.e. phones(j2me), smartcards(javacard),
pcs(java).  There are many versions of java/JNI for every OS.  
There are many versions of gnat for every OS.  There are many versions
of gcc for every OS.  There's a lot of compiling going on using any
language.

I would have peace of mind running an ada-compiled embedded system that 
could download out-of-process plugins and and run them as another
process with less privileges on the phone/handheld/javacard/pc....
Among the plug-ins could be an ada-web-browser.

But remember this is all a foggy dream :)

Sant� bonheur,
David Marceau

Re: GNAT Ada - DLL - MSVC - debugging

[Stephen Leake]

"Alderson, Paul A." <Paul.Alderson@avistainc.com> writes:

> If you
> know of a good example of accessing debug information from MSVC using an Ada
> DLL I would appreciate hearing about it.

I've done this kind of application, but with Borland C++.

The short answer is "MSVC++ does not understand the GNAT debugging
info in the DLL". So what you are asking for (using the MSVC debugger
to step thru the Ada DLL) is not possible.

I used Ada.Text_IO.Put_Line in my DLL when I really needed to see what
was going on. Before that, I wrote really thorough unit tests for the
Ada code; Ada test drivers let me use the GNAT debugger.

You might try compiling the C++ code with the Gnu C++ compiler.
Depending on how much Microsoft-specific stuff you've got, you'll have
more or less success. That would give you uniform debug info. 

There ought to be a way to get the Gnu debugger to "attach" to the Ada
DLL, but I don't know how to do that, or if it is indeed possible.

-- 
-- Stephe

Re: GNAT Ada - DLL - MSVC - debugging

[Pascal Obry]

Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:

> There ought to be a way to get the Gnu debugger to "attach" to the Ada
> DLL, but I don't know how to do that, or if it is indeed possible.

It is possible and this is hidden in the... well you know the secret
document :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: GNAT Ada - DLL - MSVC - debugging

[Stephen Leake]

Pascal Obry <p.obry@wanadoo.fr> writes:

> Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov> writes:
> 
> > There ought to be a way to get the Gnu debugger to "attach" to the Ada
> > DLL, but I don't know how to do that, or if it is indeed possible.
> 
> It is possible and this is hidden in the... well you know the secret
> document :)

Cool. It wasn't there when I was doing this (gnat 3.13). I really need
to re-read the whole thing with each new release :).

-- 
-- Stephe

Re: GNAT Ada - DLL - MSVC - debugging

[SteveD]

"Alderson, Paul A." <Paul.Alderson@avistainc.com> wrote in message
news:mailman.1023801422.8774.comp.lang.ada@ada.eu.org...
> Hello,
>
> I am using the Gnat Ada compiler to produce an Ada DLL that is used by the
> Microsoft Visual C++.
> Currently everything is working, but I have no debugging information
> available.  I have searched the web for a possible solution, but have
found
> no working solutions.

You may have better luck with the ObjectAda compiler since it generates
CodeView debug information.  I know that you can use the MSVC++ debugger
with code generated by ObjectAda, I don't know how this works across DLL's.

SteveD

> The reason I need to use Ada in a DLL in the C++ environment is because I
am
> attempting to save a large Ada development effort by adding a new GUI for
> it.  Other Ada GUI's and compilers have been less than impressive.  This
> solution seems to be working good, but it is difficult to debug.  If you
> know of a good example of accessing debug information from MSVC using an
Ada
> DLL I would appreciate hearing about it.
>
> Thanks
> Paul Alderson