problem with rundll in vb6 trying to open pdf and not saving it

[csvand...@gmail.com]

Hello my friends

I use the following code to open a pdf-file

Shell "RUNDLL32.EXE URL.DLL,FileProtocolHandler " & filename, vbMaximizedFocus

That works fine,but when I want to close it (x-button in the right upper corner)
the program asks me wether or not I want to save it. That's not what I expect.

Any idea??

Thanks in advance

Catharinus van der Werf
plan...@plantech.nl

[CoderX]

Don't use RUNDLL32. It's depreciated technology. There's an API to do
this, but I can't remember it off the top of my head. Ralph'll know. <g>

<csvand...@gmail.com> wrote in message
news:eb07fced-4afd-4970...@googlegroups.com...

[ObiWan]

> I use the following code to open a pdf-file
>
> Shell "RUNDLL32.EXE URL.DLL,FileProtocolHandler " & filename,
> vbMaximizedFocus
>
> That works fine,but when I want to close it (x-button in the right
> upper corner) the program asks me wether or not I want to save it.
> That's not what I expect.
>
> Any idea??

not exactly the kind of solution you'd expect, but... why don't you
have a look at SumatraPDF ?

http://blog.kowalczyk.info/software/sumatrapdf/free-pdf-reader.html

not only it doesn't need a setup (you can just add the files to your
setup) but if you check the CVS repository, there was (and afaict it's
still available) a COM (ActiveX) DLL allowing to embed the viewer in
your application

[Mayayana]

| not exactly the kind of solution you'd expect, but... why don't you
| have a look at SumatraPDF ?
|
| http://blog.kowalczyk.info/software/sumatrapdf/free-pdf-reader.html
|

It's also OSS, far smaller than the monstrously
bloated Acrobat Reader, and with just one
or two code edits one can recompile Sumatra
for a version that ignores restrictions on copying,
etc.

[csvand...@gmail.com]

Op donderdag 10 januari 2013 14:51:48 UTC+1 schreef Mayayana het volgende:

still no answer at my question...

[Mayayana]

| still no answer at my question...

No, I just thought that bit of info. was worth knowing.
But CoderX did sort of answer. Why are you using RunDLL,
a scripting hack, rather than ShellExecute?
The following works fine for me, though I don't know whether
the file-save prompt you see might be a bug in the PDF program
you use.

Private Const SW_SHOWNORMAL = 1
Private Const SW_SHOWMAXIMIZED = 3
Private Const SW_SHOWNA = 8
Private Const SW_SHOWNOACTIVATE = 4
Private Declare Function ShellExecute Lib "shell32.dll" Alias
"ShellExecuteA" (ByVal hWnd As Long, ByVal lpOperation As String, ByVal
lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String,
ByVal nShowCmd As Long) As Long


Private Sub Command1_Click()
Dim LRet As Long
Dim sPath As String
sPath = "C:\windows\desktop\sprague.pdf"
LRet = ShellExecute(0, vbNullString, sPath, vbNullString, vbNullString,
SW_SHOWNORMAL)
If LRet < 32 Then
MsgBox "Error opening PDF file: " & CStr(LRet)
End If
End Sub

Note that I specified SHOWNORMAL. The PDF opened maximized
because I use Sumatra and it keeps track of opened PDFs, opening
them with the window and scroll position the had when last opened.
But generally it seems more respectful to use SHOWNORMAL, since
that's the default for most software.

You can find the "show" constants and the return error codes
if you look up ShellExecute in MSDN.

[csvand...@gmail.com]

Op donderdag 10 januari 2013 15:45:34 UTC+1 schreef Mayayana het volgende:

Just at the same time you speak about 'maybe having a bug', I thought the same. I guess that's the problem: the files I am trying to open with the code, were created with a piece of code I took from the internet and which can have a mistake in it. To try whether that was the problem, I opened a pdf-file that was not created with the piece of code. No problem!!!
So the piece of code should be edited by me. Sorry for taking your time and thanks a lot for the good suggestion and help.

Catharinus

[csvand...@gmail.com]

Op donderdag 10 januari 2013 16:25:02 UTC+1 schreef csvand...@gmail.com het volgende:

I was mistaken, the code gives the same problem. But anyway, the problem lies in that code, not in mine, I am going to fix is.

[Mike Williams]

<csvand...@gmail.com> wrote in message
news:5c4a3580-8e8b-4a9d...@googlegroups.com...

Okay.

[Ulrich Korndoerfer]

Mike Williams schrieb:

Me too :-)

--
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.prosource.de/Downloads/
MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html

[ObiWan]

> | http://blog.kowalczyk.info/software/sumatrapdf/free-pdf-reader.html

> It's also OSS, far smaller than the monstrously
> bloated Acrobat Reader, and with just one
> or two code edits one can recompile Sumatra
> for a version that ignores restrictions on copying,
> etc.

oh and then ...

http://code.google.com/p/sumatrapdf/wiki/DDEcommands

;-)

[csvand...@gmail.com]

Op donderdag 10 januari 2013 18:52:18 UTC+1 schreef ObiWan het volgende:

[csvand...@gmail.com]

Op vrijdag 11 januari 2013 10:22:53 UTC+1 schreef csvand...@gmail.com het volgende:

As I told before, the problem lies in the code I use for creating a pdf-file.
This code is from http://www.codeguru.com/vb/gen/vb_misc/pdf/article.php/c5599/Write-to-a-PDF-File-From-VB.htm, Dinesh Asanka. I can't find the error in his code. Maybe anyone can help.

[ObiWan]

> first one is somewhat more "complex" but will give you much greater
> flexibility; the idea is to install this "port monitor"
>
> http://pages.cs.wisc.edu/~ghost/redmon/index.htm

the "redmon" monitor can do more than just "convert a PS to PDF"; it
will allow you to "intercept" whatever print job is sent to the
"virtual printer" configured to use the redmon port and do with it
whatever you want... and this ranges from converting a spool stream to
a different format (as for this thread) to manipulating the stream
before printing it to a real printer (e.g. add some signatures...) to
setting up a fax/sms machine ... and then some more; heck, I used it in
a past to setup a system which not only printed the spooled documents
to a given "real printer" but also uploaded a (PDF) copy of them to an
FTP server

> http://sourceforge.net/projects/pdfcreator/files/PDFCreator/PDFCreator%201.6.1/
>
> You'll find a bunch of "frm", "cls" and ... yes, that's VB ;-D !!!

and a ".vbg" by the way :)

[Mayayana]

| As I told before, the problem lies in the code I use for creating a
pdf-file.
| This code is from
http://www.codeguru.com/vb/gen/vb_misc/pdf/article.php/c5599/Write-to-a-PDF-File-From-VB.htm,
Dinesh Asanka. I can't find the error in his code. Maybe anyone can help.
|

I wonder if PDFs might have a "dirty" flag in the header. You
could check that out. I know the PDF spec is available. I started
a project some years ago to write a PDF parser. I decided it
was just too complex for me to want to go through with it, but
I did find docs for the format.

Frankly I have to wonder why you want to create PDFs in
the first place. It's a grossly overused format that's really
only good for accurate printing. And I don't see the VB6 code
helping there. I tried the code download to create a PDF from
a TXT file that had one very long line. The PDF code ran that
line right off the page. It seems that all the code is doing is to
dump plain text into a PDF wrapper.
Dinesh Asanka says PDF is desirable
because it's "normally a read-only format", but that approach
is part of the problem with PDF. People in the business world use
it to look official and to produce files that look like old-style
paper letters with the company logo on them, but the inability
to select and copy text -- usually done out of ignorance rather
than for good reason -- eliminates any advantages that digital
documents have over paper.

[csvand...@gmail.com]

Op vrijdag 11 januari 2013 15:16:19 UTC+1 schreef Mayayana het volgende:

Thank you Mayayana,

I hope someone knows how to find that 'dirty flag' in de pdf-document,
at this moment I can't. The reason why I want to create pdf-documents
is exactly because business-people want it and because it is grossly
overused. Why should I try something else if nobody uses it


Catharinus

[Eduardo]

"Arne Saknussemm" <motz001.2...@spamgourmet.com> escribió en el
mensaje

> you aren't guaranteed
> that your generated PDF will be "up to date" with the latest specs

And the problem would be...?

[Eduardo]

"Mayayana" <maya...@invalid.nospam> escribió en el mensaje
news:kcp6qg$ac4$1...@dont-email.me...

> but the inability
> to select and copy text -- usually done out of ignorance rather
> than for good reason -- eliminates any advantages that digital
> documents have over paper.

¿To select and copy text is the only advantage?
I thought the advantages were to be able to send it by email, to store on a
pendrive, to read on a monitor, to have hundreds or thousands of documents
stored in a couple of physical cubic centimeters, etc.

[csvand...@gmail.com]

Op vrijdag 11 januari 2013 15:49:10 UTC+1 schreef Eduardo het volgende:

So can anybody help me???

[Eduardo]

<csvand...@gmail.com> escribió en el mensaje
news:5fa5c449-2ac8-4eab...@googlegroups.com...

> I hope someone knows how to find that 'dirty flag' in de pdf-document,
> at this moment I can't. The reason why I want to create pdf-documents
> is exactly because business-people want it and because it is grossly
> overused. Why should I try something else if nobody uses it

Agree.

Here there are some other more "elaborated" PDF writers:

http://www.luigimicco.altervista.org/doku.php/en/download

An here there is another one (It seems to be the best one), but it's in
Spanish:
http://opdf.foroactivo.com/t3-descarga-de-la-libreria
(you need to register to be able to download it)

I still never used any of them, but I remember that I tested the one of the
first link (the free version) and it worked much better than the one you are
using now (I also had tested that).

[csvand...@gmail.com]

Op vrijdag 11 januari 2013 16:01:28 UTC+1 schreef Eduardo het volgende:

I tested the one from Luigimicco, but I saw that I couldn't easily make more than one page.

[Mayayana]

| > but the inability
| > to select and copy text -- usually done out of ignorance rather
| > than for good reason -- eliminates any advantages that digital
| > documents have over paper.
|

| ?To select and copy text is the only advantage?

| I thought the advantages were to be able to send it by email, to store on
a
| pendrive, to read on a monitor, to have hundreds or thousands of documents
| stored in a couple of physical cubic centimeters, etc.
|

Yes, but for me as the receiver the usablliy is the big
thing. I can download US IRS tax forms as PDFs but I
can't fill them in. That defeats the purpose for me. I'd just
as soon pick them up at the library or post office and save
on printer ink. Likewise with a business doc. I might find
it handy to copy/paste some of the content, but if I'm
just going to print it out I'd prefer they send me paper.

[Mayayana]

| The reason why I want to create pdf-documents
| is exactly because business-people want it and because it is grossly
| overused. Why should I try something else if nobody uses it
|

Well, I guess that's a good point. :)
I wonder about the feasibility, though. Business
people sending PDFs (or .DOCs) do it in large part
to make their files look more official. I would think
that you're going to need far more complex PDF
code for that -- so that you can let people insert
their logo, footer, etc. In other words, for business
people you'll need something like MS Word or Acrobat,
not just a TXT -> PDF converter. (The sample program
only saves text.)

[csvand...@gmail.com]

Op vrijdag 11 januari 2013 16:28:34 UTC+1 schreef Mayayana het volgende:

That's enough, only saving code..

[CoderX]

I use the Acrobat PDF Writer plug in for Word. Easy-peasy, Japanesey.

<csvand...@gmail.com> wrote in message
news:26840ffe-6af6-43d1...@googlegroups.com...

[csvand...@gmail.com]

Op vrijdag 11 januari 2013 18:06:56 UTC+1 schreef CoderX het volgende:

Then you depend on Microsoft and you do not let open the possible use of Open Office

[csvand...@gmail.com]

Op donderdag 10 januari 2013 13:47:42 UTC+1 schreef csvand...@gmail.com het volgende:
> Hello my friends

>
>
>
> I use the following code to open a pdf-file
>
>
>
> Shell "RUNDLL32.EXE URL.DLL,FileProtocolHandler " & filename, vbMaximizedFocus
>
>
>
> That works fine,but when I want to close it (x-button in the right upper corner)
>
> the program asks me wether or not I want to save it. That's not what I expect.
>
>
>
> Any idea??
>
>
>

> Thanks in advance
>
>
>
> Catharinus van der Werf
>
> plan...@plantech.nl

Anybody???

[Eduardo]

"Mayayana" <maya...@invalid.nospam> escribió en el mensaje

news:kcpama$1hi$1...@dont-email.me...

The only advantage of sending you paper that I see is that you don't need to
have a printer.
The disadvantages are:
it last longer to arrive a document by mail than by email.
It cost more.

Once I had to fill a form and to send it filled, it was in pdf.
I found several web sites were you can do it online, I did that at that
time.

But the normal case is that you do not need to fill anything in a pdf, and
if you do, the usual thing is to print it and send it physically.

I didn't like pdfs at first, I didn't understand the need of another format,
but now I see some advantages:
you'll see the same on any computer, even in non Windows systems (I didn't
test that)
you'll see the document exactly as it would be printed (correct me if I'm
wrong)
it's not too easy to modify for normal users (at least for now).

[Eduardo]

<csvand...@gmail.com> escribió en el mensaje
news:ee582eb5-6ecf-4004...@googlegroups.com...

> Anybody???

If you are not ready/willing to mess with the code of the pdf creators,
you'll need help from someone that already did (not my case at this moment).
Or use a library. Olaf's library Cairo has the ability to create pdf files
with it.

[CoderX]

I don't 'depend' on anything. I use it because it's what I've used since
its inception. I see no reason to change. I could easily say the same of
you and OO, now couldn't I?

@@

<csvand...@gmail.com> wrote in message
news:016340ea-bde4-4669...@googlegroups.com...

[Eduardo]

"CoderX" <co...@x.com> escribi� en el mensaje
news:kcqa2a$779$1...@dont-email.me...

>I don't 'depend' on anything. I use it because it's what I've used since
>its inception. I see no reason to change.

Hello,
How the plugin gets installed?
With Word? (version 2010+?)
With the Adobe Reader?
It's an independent package to be installed?

In any case I guess you need Word installed for this to work.

[ObiWan]

>> you aren't guaranteed
>> that your generated PDF will be "up to date" with the latest specs

> And the problem would be...?

well ... older PDF formats may not be allowed in some cases
and in any case, having an external "known to work" engine
won't be a bad idea; see, ghostscript also comes as a DLL
and calling the exposed API from VB isn't difficult, so putting
together some code picking (say) a postscript file and turning
it into a PDF (with whatever setting you may want/need) won't
be so difficult :)

[Mayayana]

| >> you aren't guaranteed
| >> that your generated PDF will be "up to date" with the latest specs
|
| > And the problem would be...?
|
| well ... older PDF formats may not be allowed in some cases

If it were me I'd do just the opposite. A new PDF parser
should be able to parse a PDF written to old specs. It would
be a sorry PDF program that can't read a 10-year-old PDF just
because it conforms to an older spec. There's never any reward
but incompatibility in updating the dependency beyond what's
necessary, and in this case the OP only wants to save plain text.

Having studied the PDF spec somewhat, I wouldn't want to
spend the time to master it, but that's no reason to discourage
others from doing so. It's true, though, that the code linked
is very rudimentary. It only manages to insert plain text into
a PDF wrapper. As written it can't even handle the wrapping of
long lines.

[Eduardo]

"ObiWan" <obi...@mvps.org> escribi� en el mensaje
news:kcug4q$anp$1...@news.albasani.net...

Do you mean basically the technique of installing a (new) virtual printer
and writing to it?
Can it be done "transparently", I mean, the user not seeing the virtual
printer in Windows at all?

[ObiWan]

> > won't be a bad idea; see, ghostscript also comes as a DLL
> > and calling the exposed API from VB isn't difficult, so putting
> > together some code picking (say) a postscript file and turning
> > it into a PDF (with whatever setting you may want/need) won't
> > be so difficult :)

> Do you mean basically the technique of installing a (new) virtual
> printer and writing to it?

well, that's ONE possible approach, see, the the usual way of
leveraging ghostscript is by passing it the pathname to a PS
(postscript) file and the parameters to convert it to whatever desired
output format (not just PDF, it also does multipage TIF and then some
more); so you won't need to use a "virtual printer" ... as long as
you're able to generate a postscript file, but that basically brings us
back to the same point all in all, in this case, instead of generating
a PDF you'll be generating a PS/EPS file

> Can it be done "transparently", I mean, the user not seeing the
> virtual printer in Windows at all?

I doubt it will work; all in all, if the user doesn't "see" the
printer, I doubt your app will be able to write to it; on the other
hand, going for the virtual printer approach (e.g. using "redmon") the
code handling jobs sent to such a printer will be your code so it would
be relatively easy to refuse jobs which don't come from your app; on
the other hand, the virtual printer approach eases the task of
generating "good files" since it will then be just a matter of printing
whatever you want to your virtual printer (be it an HTML page, a report
or whatever else)

[Eduardo]

"ObiWan" <alb.20.t...@spamgourmet.com> escribi� en el mensaje
news:20130114122...@deathstar.mil...

Then there is an advantage of generating the PDF files directly, you don't
need to add a printer to the system.
If you do (add a printer), the user should be notified of this issue and in
my opinion to be able to print to it from any application.
That's why I don't like this approach.

[ObiWan]

> Then there is an advantage of generating the PDF files directly, you
> don't need to add a printer to the system.
> If you do (add a printer), the user should be notified of this issue
> and in my opinion to be able to print to it from any application.
> That's why I don't like this approach.

Well... up to you; personally I don't think that adding a printer (ok,
telling the user you're about to do so :D) to the system is a big
issue; not just that, consider that using "redmon" and setting up such
a "printer" you won't only be able to generate PDF but you may use your
virtual printer for other purposes... from sending faxes or cellphone
messages to... well, whatever and then, in case the user will try to
directly print to such a printer it won't be so difficult to raise an
error like "This printer can only be used ..."

[Eduardo]

"ObiWan" <alb.20.t...@spamgourmet.com> escribi� en el mensaje

news:20130114142...@deathstar.mil...

And if you want to distribute your program without the need to install it, I
mean with a MMM package, I guess you cannot install the printer because the
process needs to run as administrator to be able to do that. That's another
consideration.

I really don't see anything wrong in generating the PDF with the current
specifications. If in the future they make a new specification that adds new
capabilities to the PDF format, the program won't be able to use them
anyway, unless it is updated. But if you update the program, you can add new
features using the new specs also.

[ObiWan]

> I really don't see anything wrong in generating the PDF with the
> current specifications. If in the future they make a new

I was unclear; let's say that a given older PDF spec gets updated due
to security reasons; now, in some environments or under certain
conditions older PDF files will be "forbidden" and that may (and
probably will) cause issues to your app; on the other hand, using an
external generator you may just update the generator to the latest
version and go on w/o too much hassle

[Eduardo]

"ObiWan" <alb.20.t...@spamgourmet.com> escribi� en el mensaje

news:20130114164...@deathstar.mil...

But in that rare case you'll have to update the external generator, so you
have a similar problem.
It said "rare" not because there are not new exploits, but because I think
it would be rare that the "normal" things one (me) would do with PDFs could
become forbidden in the future due to security reasons. In most of those
cases the readers are the ones to be updated, not the file formal
specifications.

[csvand...@gmail.com]

Op donderdag 10 januari 2013 14:45:33 UTC+1 schreef CoderX het volgende:
> Don't use RUNDLL32. It's depreciated technology. There's an API to do
>
> this, but I can't remember it off the top of my head. Ralph'll know. <g>
>
>
>
> <csvand...@gmail.com> wrote in message
>
> news:eb07fced-4afd-4970...@googlegroups.com...
>
> > Hello my friends
> Hello Coder
could you try to find the Api you are talking about???
That would be wonderfull
Thanks in advance

Catharinus

[Eduardo]

<csvand...@gmail.com> escribi� en el mensaje
news:fd961331-7677-4c5f...@googlegroups.com...

> Op donderdag 10 januari 2013 14:45:33 UTC+1 schreef CoderX het volgende:
>> Don't use RUNDLL32. It's depreciated technology. There's an API to do
>>
>> this, but I can't remember it off the top of my head. Ralph'll know.
>> <g>
>>
>>
>>
>> <csvand...@gmail.com> wrote in message
>>
>> news:eb07fced-4afd-4970...@googlegroups.com...
>>
>> > Hello my friends
>> Hello Coder
> could you try to find the Api you are talking about???
> That would be wonderfull
> Thanks in advance

ShellExecuteEx:
http://www.tech-archive.net/Archive/VB/microsoft.public.vb.general.discussion/2012-02/msg00071.html

[csvand...@gmail.com]

Op woensdag 16 januari 2013 02:03:56 UTC+1 schreef Eduardo het volgende:

Thanks Eduardo
I tried the tool, but I got the message: cannot find file...
I will try again later
Catharinus

[Eduardo]

<csvand...@gmail.com> escribi� en el mensaje

news:089c28f2-12e9-4724...@googlegroups.com...

> http://www.tech-archive.net/Archive/VB/microsoft.public.vb.general.discussion/2012-02/msg00071.html

> Thanks Eduardo
> I tried the tool, but I got the message: cannot find file...

1) Is adobe reader installed?
2) Are you sending the full path of the pdf file in the parameter
nFileFullPath?

[Deanna Earley]

On 10/01/2013 16:37, Ulrich Korndoerfer wrote:
> Mike Williams schrieb:
>> <csvand...@gmail.com> wrote in message
>> news:5c4a3580-8e8b-4a9d...@googlegroups.com...
>>> So the piece of code should be edited by me. Sorry for taking your
>>> time and thanks a lot for the good suggestion and help.
>>>
>>> Catharinus
>>
>> Okay.
>>
>>
>
> Me too :-)
>

*sighs*...

Thankfully my NNTP host is sensible :)
> A News (NNTP) error occured: Too many quoted lines

--
Deanna Earley (dee.e...@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the
group.)

[csvand...@gmail.com]

Op donderdag 10 januari 2013 13:47:42 UTC+1 schreef csvand...@gmail.com het volgende:
> Hello my friends
>
>
>

> I use the following code to open a pdf-file
>
>
>
> Shell "RUNDLL32.EXE URL.DLL,FileProtocolHandler " & filename, vbMaximizedFocus
>
>
>
> That works fine,but when I want to close it (x-button in the right upper corner)
>
> the program asks me wether or not I want to save it. That's not what I expect.
>
>
>
> Any idea??
>
>
>
> Thanks in advance
>
>
>
> Catharinus van der Werf
>
> plan...@plantech.nl

Oke Leonardo

I succeeded with your code. Thanks.
But the problem is not how to show a pdf
the problem is how to create a PDF that can
be opened without adobe asking me whether or not

I want to save it.

Catharinus

[Ulrich Korndoerfer]

Deanna Earley schrieb:

> On 10/01/2013 16:37, Ulrich Korndoerfer wrote:
>> Mike Williams schrieb:
>>> <csvand...@gmail.com> wrote in message
>>> news:5c4a3580-8e8b-4a9d...@googlegroups.com...
>>>> So the piece of code should be edited by me. Sorry for taking your
>>>> time and thanks a lot for the good suggestion and help.
>>>>
>>>> Catharinus
>>>
>>> Okay.
>>>
>>>
>>
>> Me too :-)
>>
>
> *sighs*...
>
> Thankfully my NNTP host is sensible :)
>> A News (NNTP) error occured: Too many quoted lines
>

So you should switch to a better host that is able to handle those
visually appealing posts with TUFO ("Text unten, Fullquote oben" = "text
below, full quote above") :-))

Also TUFO is seemingly better than TOFU ("Text oben, Fullquote unten" =
"text above, full quote below"), because with TUFO you are forced to
read the posts full text history ;-)

--
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.prosource.de/Downloads/
MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html

[Eduardo]

<csvand...@gmail.com> escribi� en el mensaje

news:44452ce3-70cb-4416...@googlegroups.com...

> Oke Leonardo
>
> I succeeded with your code. Thanks.
> But the problem is not how to show a pdf
> the problem is how to create a PDF that can
> be opened without adobe asking me whether or not
> I want to save it.
> Catharinus

I would give a second try to
http://www.luigimicco.altervista.org/doku.php/en/download
Try to find how to add a new page or why you can't add a page.

[csvand...@gmail.com]

Op donderdag 17 januari 2013 23:58:20 UTC+1 schreef Eduardo het volgende:
> <csvand...@gmail.com> escribió en el mensaje

I guess you're right. But can't get the text good on the pages.
open "test.txt"for input as #1
for i=0 to lastline
Input #1, text
.DrawText 1, 20 - i * sngRowHeight, tekst, "Fnt3", 7.5, 0
next line
etc

but annot get it proberly on a page

Catharinus

[Eduardo]

<csvand...@gmail.com> escribi� en el mensaje

news:75ce14ec-69ce-46c8...@googlegroups.com...

>> I would give a second try to
>>
>> http://www.luigimicco.altervista.org/doku.php/en/download
>>
>> Try to find how to add a new page or why you can't add a page.

>I guess you're right. But can't get the text good on the pages.
>open "test.txt"for input as #1
>for i=0 to lastline
> Input #1, text
> .DrawText 1, 20 - i * sngRowHeight, tekst, "Fnt3", 7.5, 0
>next line
>etc

>but annot get it proberly on a page

I'm sorry I can't help more because I've only tested these pdf writers so
far, but never worked with any of them.

The only one from the group that I know that has knowledge on this subject
is Olaf, but he's absent lately.

Some time ago he had post a link to a sample code for generating PDFs here:
https://groups.google.com/forum/?fromgroups=#!topic/microsoft.public.vb.general.discussion/IW23i-7FLQk
Unfortunately, the site www.datenhaus.de is gone, so you can't download the
sample. This is a demo project of how to write pdf files using Olaf's
library RichClient4.

There is another thread with subject "Olaf Schmidt - Datenhaus/TheCommon
Sites Down?" where someone is trying to contact him.

PS: I have the files, but I think it's better if the author give them to you
(or to have his permission).

[ObiWan]

> Unfortunately, the site www.datenhaus.de is gone, so you can't

Or ... maybe you can :) try this

http://web.archive.org/web/*/http://www.datenhaus.de/

select the year to which the post refers and then drill to the needed
URL ... or either go here http://archive.org/web/web.php and directly
enter the full URL

;-)

[csvand...@gmail.com]

Op vrijdag 18 januari 2013 17:30:47 UTC+1 schreef Eduardo het volgende:

Oke Eduardo

thank you very much
I will reconsider all this

Catharinus

[Eduardo]

"ObiWan" <alb.20.t...@spamgourmet.com> escribi� en el mensaje
news:20130118183...@deathstar.mil...

Thanks, but I already had checked that, it isn't there.
http://web.archive.org/web/*/http://www.datenhaus.de/Downloads/IVBDrawing.zip

[Schmidt]

Am 18.01.2013 17:30, schrieb Eduardo:

[Generating PDF-Files with VB6 reliably]

> I'm sorry I can't help more because I've only tested these pdf writers so
> far, but never worked with any of them.
>
> The only one from the group that I know that has knowledge on this subject
> is Olaf, but he's absent lately.

Sorry, not that much time recently for newsgroup-activities,
but will try to better the frequency again over the next weeks... :-)

> Some time ago he had post a link to a sample code for generating PDFs here:
> https://groups.google.com/forum/?fromgroups=#!topic/microsoft.public.vb.general.discussion/IW23i-7FLQk
> Unfortunately, the site www.datenhaus.de is gone, so you can't download the
> sample. This is a demo project of how to write pdf files using Olaf's
> library RichClient4.

Here's a new, alternative link for the PDF-Demo in question:
www.vbRichClient.com/Downloads/IVBDrawing.zip

The Demo has two dependencies (check the Project-References):
1. the vbRichClient4-BaseDlls need to be in place
(Download available on www.thecommon.net ...
one needs to unzip the contents of the BaseDlls-archive
into a free choosable locale Folder - and from the 3 Dlls
only vbRichClient4.dll needs to be registered beforehand).
2. The example achieves its output over the "classic" VB-Drawing-
Functions (Print, Line, PSet, PaintPicture etc.) ... and this
requires the usage of a small Typelib (IVBDrawing.tlb), which
is contained in the above IVBDrawing.zip - and needs to be
checked in as the second reference in the Demo-Project

> There is another thread with subject "Olaf Schmidt - Datenhaus/TheCommon
> Sites Down?" where someone is trying to contact him.

See my reply to the latest posting (from Jason Peter Brown) there...

> PS: I have the files, but I think it's better if the author give them
> to you (or to have his permission).

Anybody who has downloaded Demos or RichClient-Dll-packages
from the former datenhaus.de-Site, can upload and (re)distribute
these Zip-Files anywhere - but will try to upload all the zips
which were formerly available under:
www.datenhaus.de/Downloads/...
to the new site:
www.vbRichClient.com/Downloads/...

So, that "as a rule" only the 'datenhaus.de' part will need to
be replaced to 'vbRichClient.com', to make an old Download-URL
work again.

Olaf

[Eduardo]

"Schmidt" <n...@vbRichClient.com> escribi� en el mensaje
news:kdc67l$te0$1...@dont-email.me...

>> PS: I have the files, but I think it's better if the author give them
>> to you (or to have his permission).
>
> Anybody who has downloaded Demos or RichClient-Dll-packages
> from the former datenhaus.de-Site, can upload and (re)distribute
> these Zip-Files anywhere - but will try to upload all the zips
> which were formerly available under:
> www.datenhaus.de/Downloads/...
> to the new site:
> www.vbRichClient.com/Downloads/...
>
> So, that "as a rule" only the 'datenhaus.de' part will need to
> be replaced to 'vbRichClient.com', to make an old Download-URL
> work again.

Thanks Olaf.

[Schmidt]

Am 18.01.2013 15:51, schrieb csvand...@gmail.com:

>>> But the problem is not how to show a pdf

>>> the problem is how to create a PDF ...

Please see my answer to Eduardos post.

In case the example (which generates PDFs over VBs
Standard-Drawing/Printing-commands) is too complex
for your taste, and you really want to create only
simple TextOutputs with different FontNames/FontSizes
with a kind of DrawText-API, then you can also use
the vbRichClient4/Cairo-functionality directly.

Here's a vers simple code-snippet, which demonstrates
this direct usage of the vbRichClient4.dll (which needs
to be checked in as a Project-reference, before using
the code below in an empty VB-Standard-Form):

Option Explicit

Private New_c As New cconstructor, Cairo As cCairo

Private Sub Form_Load()
Set Cairo = New_c.Cairo 'create a Cairo-BaseInstance, useable everywhere
End Sub

Private Sub Form_Click()
Dim i As Long, yOffs As Double, dx As Double, dy As Double, S As String

'create the PDF-Page-Surface in US-Letter-Size (8.5x11")
'...the default-scale-unit for such a surface is in "Points", which is
'...1/72 inch, therefore the xx * 72 factor in the Create-Call below
Dim PDFSrf As cCairoSurface
Set PDFSrf = Cairo.CreateSurface(8.5 * 72, 11 * 72, PDFSurface)

'now create a Cairo-Context (something like a hDC), to draw against
Dim CC As cCairoContext
Set CC = PDFSrf.CreateContext

'now the drawing-stuff, starting with some simple TextOut-calls

'we render everything on this page with a TopLeft-Offset of 72 (=1")
CC.TranslateDrawings 72, 72

'line-based Text-Rendering, using Cairos TextOut-Method
'...starting with the selection of FontName/Size/etc.
CC.SelectFont "Times New Roman", 11, vbBlack, True, True

For i = 0 To 19 'now we draw 20 lines of Text in a loop
CC.TextOut 0, i * CC.GetFontHeight, _
"Some Text-Output in 'Times New Roman' " & _
"(11pt, Bold, Italic) on Row " & i + 1
Next i


'now some Text in a different Font, using the DrawText-Method

'let's save the y-EndPoint of our last Drawing-Command first
yOffs = 20 * CC.GetFontHeight '<-the point directly below our 20 lines

'store the Width and Height of our "Text-Rectangle"
dx = PDFSrf.Width - 144 'Rect-Width = (Page-Width - 2") (144 points)
dy = 72 * 1.5 'and the Height of the Rectangle is 1.5"

'draw a "control-rectangle", just to visualize the Range, the
'DrawText-Command is working with...
CC.SetSourceColor vbBlue
CC.Rectangle 0, yOffs, dx, dy
CC.Stroke

'now let's select a different Font
CC.SelectFont "Arial", 11, vbBlack, False

'store the longer Text in a String-Variable...
S = "Some longer Text in 'Arial' (11pt), to be rendered with " & _
"Cairos DrawText Method, which is able to render Text within " & _
"a 'Box', supporting WordWrapping and different Alignments " & _
"(including vertical centering and an 'InnerSpace' Parameter)."

CC.DrawText 0, yOffs, dx, dy, S, False, vbLeftJustify, 2, True


'finally, to create a PDF-File from the PDF-Surface...
'...we close the (PDFSrf-"derived") CC first
Set CC = Nothing

'and now write the contents of the PDFSrf out to a File
PDFSrf.WriteContentToPDFFile "c:\my-test.pdf"

'and close the PDF-Surface, to clean up everything
Set PDFSrf = Nothing
End Sub


Private Sub Form_Terminate()
New_c.CleanupRichClientDll 'cleanup Dll-internal stuff, when the App
terminates
End Sub

Olaf

[csvand...@gmail.com]

Op donderdag 10 januari 2013 13:47:42 UTC+1 schreef csvand...@gmail.com het volgende:
> Hello my friends
>
>
>
> I use the following code to open a pdf-file
>
>
>
> Shell "RUNDLL32.EXE URL.DLL,FileProtocolHandler " & filename, vbMaximizedFocus

> thanks for the example, but I get the message ActiveX component can't create object.

[csvand...@gmail.com]

Op vrijdag 18 januari 2013 20:54:51 UTC+1 schreef Schmidt het volgende:

Thanks for the beautiful piece of code, but I get the error:

ActiveX component can't create object.

catharinus

[Schmidt]

Am 18.01.2013 23:13, schrieb csvand...@gmail.com:

I'm not sure, if the following was meant as a reply to my last post
here in this thread

> thanks for the example, but I get the message ActiveX component can't create object.

But if it was, then you need to lookup, what I wrote in my reply
to Eduardo (about the 2 dependencies you need to check into your
project-references, before trying to run the Demo in the Zip:
www.vbRichClient.com/Downloads/IVBDrawing.zip ).

The smaller Code-example which I've posted in a direct reply
to you, only depends on the vbRichClient4 project-reference,
which you need to make sure over the appropriate IDE-Dialog,
before Copy/Pasting the Code-snippet into a VB-Form, followed
by clicking on it.

The download for the RichClient4-BaseDlls is as said available
on www.thecommon.net...
direct Download-link:
http://www.thecommon.net/?syscmd=dl&ID=F6F70FF2A4364F818F72679C63C51905

You need to unzip the above BaseDll-content into a Folder on
your local Disk - leave the 3 Dlls together in one place -
then register only vbRichClient4.dll with your tool of choice
(e.g. over the VB-IDE, or per regsvr32.exe).

After that, start a new, empty VB-Standard-Exe-Project, select
the project-reference 'vbRichClient4' - then paste the Example
Code-Snippet into a new Form, run and click the Form -
this way a PDF-file will be created in "c:\my-test.pdf" -
if you don't like this location, then adjust the path in
the Code-snippet...

Olaf

[csvand...@gmail.com]

Op zaterdag 19 januari 2013 00:32:04 UTC+1 schreef Schmidt het volgende:

I still get the same error, it is at this point:

[csvand...@gmail.com]

Op zaterdag 19 januari 2013 00:47:03 UTC+1 schreef csvand...@gmail.com het volgende:

while registering:

regsvr32 vbrichtextclient4 gives this error:

module loaded ... with error code 0x80004005

[Schmidt]

Am 19.01.2013 00:57, schrieb csvand...@gmail.com:

> while registering:
>
> regsvr32 vbrichtextclient4 gives this error:
>
> module loaded ... with error code 0x80004005
>

I'm not sure, what you're trying in the line above...
(vbrichtextclient4 is definitely not the right FileName,
although the 0x80004005-error suggests, that you don't
have sufficient user-rights, to register successfully).

Maybe again in more detail:

After downloading the BaseDll-Zip, you need to unpack
the content into one single Folder...
Leave the 3 BaseDlls together within that Folder...
for example, in C:\RC4\ you will need the 3 Dlls:
DirectCOM.dll
vb_cairo_sqlite.dll
vbRichClient4.dll
unpacked and existing "side-by-side".


After that you can register vbRichClient4.dll e.g.
on the commandline:

regsvr32 C:\RC4\vbRichClient4.dll

But in case you run on Vista/Win7, then this register-attempt
needs to take place in a Cmd-Shell which was started "elevated"
(with admin-rights).

Alternatively you can use the VB-IDE, to register the
vbRichClient4.dll, by directly navigating to the appropriate
Folder, using the References-Dialogue - though on Vista/Win7
also the VB-IDE needs to be run in Admin-Mode, which
is usually the case, to avoid other problems with UAC.

So, before you run any RichClient4-based examples in the
VB-IDE, you will need to make sure, that the registering
was accomplished successfully.


Olaf

[csvand...@gmail.com]

Op zaterdag 19 januari 2013 01:29:22 UTC+1 schreef Schmidt het volgende:

This works!!
The registration worked and now the program works!!
Thank you very much and tomorrow I will take a closer look at it
It is 01.44 am at this moment
Thanks again
Catharinus

[Schmidt]

Am 19.01.2013 01:44, schrieb csvand...@gmail.com:

> This works!!
> The registration worked and now the program works!!
> Thank you very much and tomorrow I will take a closer look at it

Ah, finally! :-)

Just in case, you want to create more than one page within
a PDF-File, here comes the same example-code again - but
enhanced about a few lines of code, which demonstrate the
usage of PDFSrf.EmitPDFPage, to accomplish just that
(by changing the Width- and Height-Parameters, this
second Page is created in Landscape-Format, just to show
how to mix Portrait- and Landscape-Pages within the same
PDF-Document).

'***Into a Form, the click the Form

Option Explicit

Private New_c As New cconstructor, Cairo As cCairo

Private Sub Form_Load()

Set Cairo = New_c.Cairo 'create a Cairo-BaseInstance, useable everywhere

'now we draw the String S

CC.DrawText 0, yOffs, dx, dy, S, False, vbLeftJustify, 2, True

'**Ok first page finished, now let's create a second Page in the PDF**

'we exchange the Width and Height-Parameters here, to ensure LandScape
PDFSrf.EmitPDFPage False, 11 * 72, 8.5 * 72

'now we put out the blue rectangle again (with zero yOffs)
CC.SetSourceColor vbBlue
CC.Rectangle 0, 0, dx, dy
CC.Stroke

'and also draw the text within the above rectangle a second time
CC.DrawText 0, 0, dx, dy, S, False, vbLeftJustify, 2, True

'**Ok, our second (Landscape)-Page is finished here**

'finally, to create a PDF-File from the PDF-Surface...
'...we close the (PDFSrf-"derived") CC first
Set CC = Nothing

'and now write the contents of the PDFSrf out to a File
PDFSrf.WriteContentToPDFFile "c:\my-test.pdf"

'and close the PDF-Surface, to clean up everything
Set PDFSrf = Nothing
End Sub

Private Sub Form_Terminate()

'cleanup Dll-internal stuff, when the App terminates

New_c.CleanupRichClientDll
End Sub

Olaf

[csvand...@gmail.com]

Op donderdag 10 januari 2013 13:47:42 UTC+1 schreef csvand...@gmail.com het volgende:
> Hello my friends
>
>
>
> I use the following code to open a pdf-file
>
>
>
> Shell "RUNDLL32.EXE URL.DLL,FileProtocolHandler " & filename, vbMaximizedFocus
>
>
>

> That works fine,but when I want to close it (x-button in the right upper corner)
>
> the program asks me wether or not I want to save it. That's not what I expect.
>
>
>
> Any idea??
>
>
>
> Thanks in advance
>
>
>
> Catharinus van der Werf
>
> plan...@plantech.nl

Wonderfull, thanks I will use it in my program

[Catharinus van der werf]

Hello again

After having used the richclient dll for a while, I was not completely satified, because I found it too complex, so I looked at the demo of the class from Luigi Micco again (http://www.luigimicco.altervista.org/doku.php/download). That class looked very easy to understand. The problem I had with the class before was that it didn't work fast enough and the PDF that I created with it, was very big (2.6 Mg). So I contacted Luigi and asked him about the full-version (200 euro). He showed me that the full-version was fast and created a small pdf, so I bought it
and now I am completely satisfied. Thanks for all your help again.

Catharinus

[Mayayana]

Olaf, if you're reading this....

I just did a search for your DLLs and found this:

www.thecommon.net

The links there are faulty. I had to edit them to
get them to work. It looks like the webmaster is using
some sort of funky WYSIWYG editor. That page also
points here:

http://www.vbrichclient.com/

That page has no download links at all!

I went through 40-odd returns (at zapmeta) and didn't
find any more relevant links.

[Ulrich Korndoerfer]

Hi,

Mayayana schrieb:

> Olaf, if you're reading this....
>

Olaf is travelling until end of march, so I jump in for him.

> I just did a search for your DLLs and found this:
>
> www.thecommon.net
>

This domain is no longer owned by Olaf.

> The links there are faulty. I had to edit them to
> get them to work. It looks like the webmaster is using
> some sort of funky WYSIWYG editor. That page also
> points here:
>
> http://www.vbrichclient.com/
>

This is the new "official" site for all of Olafs rich client stuff.
Currently there are downloads for the current version of vbRichClient,
supporting dlls and some tutorials and demos.

> That page has no download links at all!
>

He uses a JavaScript Framework (jquery) to build the site. So JS should
be switched on, otherwise you will not see very much.

[Mayayana]

| > That page has no download links at all!

| He uses a JavaScript Framework (jquery) to build the site. So JS should
| be switched on, otherwise you will not see very much.
|

I see. I can't imagine why Olaf would have created
such a bloated, circuitous, superfluous, unsafe mess
of script and iframes.

The real download link, for anyone interested, is here:

http://www.vbrichclient.com/en/Downloads.htm

[Ulrich Korndoerfer]

Hi,

Mayayana schrieb:

> | > That page has no download links at all!
>
> | He uses a JavaScript Framework (jquery) to build the site. So JS should
> | be switched on, otherwise you will not see very much.
> |
>
> I see. I can't imagine why Olaf would have created
> such a bloated, circuitous, superfluous, unsafe mess
> of script and iframes.
>

No frames nor iframes, only divs, javascript and some css. It is not
bloated because the user interface is not bloated and the amount of data
to be transmitted over the wire is quite small (except the initial,
onetime transfer of the minified jquery framework). Superfluous may be
if you mean that building sites without JS is possible. Unsafe only in
that sense that you have to use JS.

Ok, for me I'm too somewhat split when it comes to wether to use JS or not.

> The real download link, for anyone interested, is here:
>
> http://www.vbrichclient.com/en/Downloads.htm
>
>

I already suggested to Olaf to at least make available the "real" links
instead of the AJAX suitable links. But as said he currently is on travel.

[Ulrich Korndoerfer]

I forgot to mention that Olaf created the site content quickly on demand
of a user request in one of the german ms newsgroups shortly before he
went off to travel. May be that the site design is not carved in stone :-)

[Carlos Rocha]

On Monday, April 15, 2013 9:47:14 PM UTC+1, Mayayana wrote:
> I see. I can't imagine why Olaf would have created
> such a bloated, circuitous, superfluous, unsafe mess
> of script and iframes.
>

I wonder if it's possible at all to live without women, coffee, cigars and JavaScript? one need at least four of them to be happy :P

[Mayayana]

| I wonder if it's possible at all to live without women, coffee, cigars and
JavaScript? one need at least four of them to be happy :P

:) I try to get by with just the first two, but it
keeps getting more difficult to operate without
script.

[Schmidt]

Am 15.04.2013 22:47, schrieb Mayayana:
> | > That page has no download links at all!
>
> | He uses a JavaScript Framework (jquery) to build the site.
> | So JS should be switched on, otherwise you will not see
> | very much.
>
> I see. I can't imagine why Olaf would have created
> such a bloated, circuitous, superfluous, unsafe mess
> of script and iframes.

As Ulrich was saying, aside from the initial loading of
the gzipped and minified jQuery.js, all the other content
should load pretty fast, because only the parts which really
need an update, are refreshed in a single Ajax-Roundtrip,
without re-loading other static content over and over again,
when it's already there in the Browser-View.

The site will get a lot of content (I hope) over the next
months - and that's why I've choosen a hierarchical Tree-
Menu in conjunction with jQuery and Ajax-RPCs, to ensure
easy (obvious) navigation and fast loading.

So what you see there (if you enable js for this site),
is the start of a very lightweight Content-Management-
System (a Wiki if you want, online-editable by "trusted
developers" later on ... but the implementation of the Auth-
Handling for that is not yet finished) ...
So the Tree-Menu to the left will contain much more
entries (information / documentation) in a year or so.

The Online-Editing-Mode already works at the clientside
(in your Browser), but the Save-Routine (when it reaches
the serverside) is enabled only for me currently.

So, much of the interaction and "logic" of the Site is already
ensured at the Browser-end ... at the serverside, there's
only a few small routines (implemented in "classic *.asp").

Really tried, not to create "bloat" - but a fast, small site,
which doesn't deny the existence of Javascript/Ajax... ;-)



Olaf

[Schmidt]

Am 15.04.2013 23:35, schrieb Ulrich Korndoerfer:

>> The real download link, for anyone interested, is here:
>>
>> http://www.vbrichclient.com/en/Downloads.htm
>>
>
> I already suggested to Olaf to at least make available
> the "real" links instead of the AJAX suitable links.

The site already contains code, to handle such
"Ajax suitable links" too (taking care of, that
the tree-menu to the left stays "in sync" then) ...
e.g. Ajax-links like:
http://www.vbrichclient.com/#/en/Downloads.htm
or
http://www.vbrichclient.com/#/en/Demos/GUI/

should work properly, even when pasted as shown above,
into an E-Mail or a Newsgroup-post - loading the
content-page together with the surrounding navigation-
stuff (a properly adjusted Tree-Menu) then.
(that is, if js is enabled in your Browser).

> But as said he currently is on travel.

I'm able to "come online" from time to time now... ;-)

Olaf

[Mayayana]

| Really tried, not to create "bloat" - but a fast, small site,
| which doesn't deny the existence of Javascript/Ajax... ;-)
|

I didn't think the site was slow-loading or bloated.
The unnecessary JS itself is the bloat. I find it unfortunate
that even experts like yourself don't help eliminate the
need for executable code in the browser by keeping it
server-side. But it's your site, after all. People like me,
who are concerned about security and privacy issues online,
simply have to accept a smaller Internet, as many webpages
gradually turn into what is essentially web-connected, multi-
media software that cannot realistically be made safe for
security, are usually not safe privacy-wise, and are entirely
dysfunctional without client-side executable code.

[Ulrich Korndoerfer]

Hi,

Schmidt schrieb:

> Am 15.04.2013 23:35, schrieb Ulrich Korndoerfer:
>
>>> The real download link, for anyone interested, is here:
>>>
>>> http://www.vbrichclient.com/en/Downloads.htm
>>>
>>
>> I already suggested to Olaf to at least make available
>> the "real" links instead of the AJAX suitable links.
>
> The site already contains code, to handle such
> "Ajax suitable links" too (taking care of, that
> the tree-menu to the left stays "in sync" then) ...
> e.g. Ajax-links like:
> http://www.vbrichclient.com/#/en/Downloads.htm
> or
> http://www.vbrichclient.com/#/en/Demos/GUI/
>

No, not that kind of links. I mean the links that point in direct to the
html that fills the right pane. Eg.

<http://www.vbrichclient.com/#/en/Downloads.htm>

will load the full site (with navigation pane, JS etc) into the browser.
However

<http://www.vbrichclient.com/en/Downloads.htm>

loads only the pure html of the content pane into the browser. This is
what I want to store local on my PC. Gets more important later when all
the documentastion will be present.

When storing <http://www.vbrichclient.com/#/en/Downloads.htm> local, I
am only interested in the content of the content/edit pane, which comes
from <http://www.vbrichclient.com/en/Downloads.htm>.

So it would be handy for the user to have a "deep" link on the site that
points to the currently displayed content: if one displays
<http://www.vbrichclient.com/#/en/Downloads.htm>, I would like to have a
link on the page that links to
<http://www.vbrichclient.com/en/Downloads.htm>. Then one or two clicks
in the browser would suffice to store this content. If such a "deep"
link is not present, I have to manually edit the link in the adress bar
of the browser (remove the "#/" part), then navigate to this url, and
then i can store the content. Much more work.

Also for the future you should bear in mind that some people will want
to store the documentation on their PCs. If the parts of the
documentation are only available by using the navigation tree, one would
have to store single doc pages that are not linked together. This would
make navigation in the downloaded doc pages very hard.

[Schmidt]

Well, I think the two of us had this discussion before ...
everything that reaches a certain Browser-engine (after
downloading it as a kind of resource from a WebServer),
needs to be "parsed" or "loaded" first by dedicated
Browser-internal routines.

That holds true for *.html-content - as well as for *.css-
content, and of course also for *.js-content.

Any of the above String-based Resources has to pass
through some Browser-internal parser-code first (at
the client-side).
And so for each of those 3 types of resources, there's
a potential for buffer-overflows in the Browsers parsing-
routines, where "bad code" (bad content) could be used,
to bring those parsing-routines out of step, make them
choke, and finally execute entirely unwanted "things".

A few years ago, there was even attack-vectors, which
were targetting (successfully) buffer-overflows (and
then executing "bad code") in the image-handler-routines,
responsible to load *.jpg or *.png-content, which was
coming in from the Webserver-end.

So there's not the least guarantee, that with a disabled
JS-engine, you'll end up "entirely safe".
I'm pretty sure, there's zero-day-exploits out there,
which target only the *.css-Parser or the *.html-parser
of the different Browser-engines, able to make those
engines choke and execute "hidden, bad code" which could
be contained in a simple, innocent looking *.css-resource.

So the rule is (as always), that you need to "trust the
vendor" (in this special case, the "domain where the
server is hosted").

If you trust, then you can also enable JS.

If you don't trust (a domain or a WebSite), then disabled
JS will not help you much, if there's really an intent
to "hack your Browser" - since attack-vectors are not
only possible against the JS-engines.

So, why should I force myself, to use only "the Form-
Designer" (so to say) to show "static content only",
when there's so much more possible with a clientside
Glue-Language, to bring some life into a static design
(and without the need, to do costly roundtrips for each
and every small visual-state-change, I want to achieve
on "my Form").

It's a web-site for developers - and those usually surf
with enabled JS and a modern Browser... <shrug>

Olaf

[Mayayana]

| A few years ago, there was even attack-vectors, which
| were targetting (successfully) buffer-overflows (and
| then executing "bad code") in the image-handler-routines,
| responsible to load *.jpg or *.png-content, which was
| coming in from the Webserver-end.
|

I remember that, but it was a rare case.

| I'm pretty sure, there's zero-day-exploits out there,
| which target only the *.css-Parser or the *.html-parser

I'd be surprised. I've never heard of that.
Nearly all exploits require script (or add-ons like Java
and ActiveX). Even most or all Flash and PDF exploits
are actually script exploits.

| So the rule is (as always), that you need to "trust the
| vendor" (in this special case, the "domain where the
| server is hosted").
|
| If you trust, then you can also enable JS.
|

Trust has little to do with it, aside from sites
providing porn, illegal software, etc. A lot of exploits
these days are put onto websites without the host's
knowledge. I get regular attacks on my own site
by parties (especially Chinese) testing for various
active exploitable bugs that might be used to infiltrate
the site. Paypal found an SQL bug on their site awhile
back that had been there for months. Wordpress has
had various attacks. A recent problem was with a
commonly used library known as timthumb, used for
image cropping, I think. For several weeks I was getting
attackers testing my site for the timthumb bug. 1/2
million Mac users even got hit last year by Flashback
malware that exploited Java. From what I read those
were mainly attacks from legitimate websites that had
been compromised. None of these problems is related
to whether the infecting website company or person is
trusted.

It is an awkward situation. People want interaction
and "rich" content. Corporate hosts want to track
visitors and show targetted ads. It's hard to give up
script with those kinds of requirements. But things could
be a lot better if people just took the approach of
not using script when it's not requisite. (I'm not clear
about exactly how your website is set up. I only see
a non-functioning comment textbox. But I don't see
why any site has to be entirely limited to script just
to have a treeview menu. If you expect it to grow
it can even be made dynamic with simple CSS. I'm
guessing that only the ability for people to log in and
edit really requires a scripted page.)

[Schmidt]

Am 16.04.2013 16:28, schrieb Ulrich Korndoerfer:

> Also for the future you should bear in mind that some people will
> want to store the documentation on their PCs. If the parts of the
> documentation are only available by using the navigation tree, one
> would have to store single doc pages that are not linked together.
> This would make navigation in the downloaded doc pages very hard.
>

Ok, then perhaps for the future I will just offer a download-
link, which contains the entire site-content behind a locally
running, small App which works against the RC5-cWebServer-class
(all InProcess and OffLine, including a Search-Function and
some other features which the "leading" public WebServer then
also contains).

But that's all stuff for the next months - depending a bit, how
the updating of the site-content will really happen in the end,
when the planned "workflow" is established (and used by
potential external contributors - or maybe not used at all).

Still all a bit in an "experimental stage" - but I think, the base-
layout (structure) of the site will remain as it is currently.

Olaf

[Schmidt]

Am 16.04.2013 18:21, schrieb Mayayana:
> | A few years ago, there was even attack-vectors, which
> | were targetting (successfully) buffer-overflows (and
> | then executing "bad code") in the image-handler-routines,
> | responsible to load *.jpg or *.png-content, which was
> | coming in from the Webserver-end.
> |
>
> I remember that, but it was a rare case.
>
> | I'm pretty sure, there's zero-day-exploits out there,
> | which target only the *.css-Parser or the *.html-parser
>
> I'd be surprised. I've never heard of that.

Just google for the terms [css exploit] and you will get
a lot of info.

> Nearly all exploits require script (or add-ons like Java
> and ActiveX). Even most or all Flash and PDF exploits
> are actually script exploits.

Yep, it's easier for an attacker to find vulnerabilities
in the scripting-engines, but as said, those other "active
parts" of the browsers are apparently also not 100% secure.

> | So the rule is (as always), that you need to "trust the
> | vendor" (in this special case, the "domain where the
> | server is hosted").
> |
> | If you trust, then you can also enable JS.
> |
>
> Trust has little to do with it, aside from sites
> providing porn, illegal software, etc. A lot of exploits
> these days are put onto websites without the host's
> knowledge. I get regular attacks on my own site
> by parties (especially Chinese) testing for various
> active exploitable bugs that might be used to infiltrate
> the site.

IMO also in this case, you will have to trust the site-
vendor, that he keeps his content clean, checking
periodically for infiltration and stuff.

> Paypal found an SQL bug on their site awhile
> back that had been there for months. Wordpress has
> had various attacks. A recent problem was with a
> commonly used library known as timthumb, used for
> image cropping, I think. For several weeks I was getting
> attackers testing my site for the timthumb bug. 1/2
> million Mac users even got hit last year by Flashback
> malware that exploited Java. From what I read those
> were mainly attacks from legitimate websites that had
> been compromised. None of these problems is related
> to whether the infecting website company or person is
> trusted.

I see your point, but as just written above - in the
end it again boils down to, that you need to trust the
vendor of a site... in this case, that any externally
forced compromising of a site, any infiltration is detected
early - and the content you get from this site-vendor
is clean(ed) as fast as possible again.

In case PayPal - (or whatever "legitimate website" we use
here as an example) - is not able to prevent such things
in the future, then I wouldn't count it among "trusted
sites" anymore (in "my book" or "personal whitelist").

> It is an awkward situation. People want interaction
> and "rich" content.

Yep - but I see Javascript only as an available tool,
which can (as any tool) be dangerous, when brought
into action, fulfilling demands of "the users".

It's quite useful for a developer these days, but in
its potential danger comparable to e.g. a knife.

If you like to eat in an argentine steak-house, and
you order "skewered meat", then you will have to
trust the wielder of the knife, who's serving and
slicing your portion, that he's using his tool properly.
In this case you trust "the House" or "the server".

General avoidance of things which are potentially dangerous
(as in: "...I don't use knifes anywhere, and will not go
to any places where knifes are in usage...") is getting
"uncomfortable" very fast - and somehow doesn't feel
right, since any human is used to live with "calculated
risks".

Where somebody draws the line, is a personal decision -
but tolerating the decisions of others, who may draw their
own personal "risk-line" at a different level, is important
also ...

So I don't really understand, why you came up with that
"as an experienced developer he should know better, than
to use JavaScript in a WebApp"-comment.

It's pretty much "standard" these days, a "broadly accepted
risk" (from the point of view of most of the "Web-Users").

So, yeah - that's why I'm using a knife, to slice the
meat I'm offering on my site... ;-)


Olaf

[Mayayana]

| > | I'm pretty sure, there's zero-day-exploits out there,
| > | which target only the *.css-Parser or the *.html-parser
| >
| > I'd be surprised. I've never heard of that.
|
| Just google for the terms [css exploit] and you will get
| a lot of info.
|

I found an "exploit" that uses CSS along with script to
check visited links in order to know whether people have
visited particular sites. CSS isn't really necessary for that
in most cases. It's just a simple scripting trick that checks
the color of visited links.

I also found an old bug for IE that wasn't actually CSS.
Rather, it was a method that uses recursive @import to
overload IE.

I didn't find anything else.

| I see your point, but as just written above - in the
| end it again boils down to, that you need to trust the
| vendor of a site... in this case, that any externally
| forced compromising of a site, any infiltration is detected
| early - and the content you get from this site-vendor
| is clean(ed) as fast as possible again.
|
| In case PayPal - (or whatever "legitimate website" we use
| here as an example) - is not able to prevent such things
| in the future, then I wouldn't count it among "trusted
| sites" anymore (in "my book" or "personal whitelist").
|

And you're hosted by 1and1. So who am I trusting?
You? Them? Both? What if I get to your site before you
find an intrusion? If you can't trust PayPal to keep their
site clean then who can you trust? As far as I'm concerned,
virtually all sites online are at about the same trust level:
They're generally safe as long as one doesn't enable
executable code. If one does enable it then all bets are off.
The levels of trustability (in privacy terms as well as security
terms) only come into play when one enables executable
code.

| General avoidance of things which are potentially dangerous
| (as in: "...I don't use knifes anywhere, and will not go
| to any places where knifes are in usage...") is getting
| "uncomfortable" very fast - and somehow doesn't feel
| right, since any human is used to live with "calculated
| risks".
|

You're dismissing the whole issue as all-or-nothing
again. That's very convenient. It makes the issue easy
for you to ignore and defines me as a reactionary. But it's
not all-or-nothing.
As I said earlier, a lot of the problem would be solved
if people would just accept that executable code is
risky and be mindful in using it. Don't base all pages on
script when only one, or maybe none, actually needs it.
That's all.

| Where somebody draws the line, is a personal decision -
| but tolerating the decisions of others, who may draw their
| own personal "risk-line" at a different level, is important
| also ...
|
| So I don't really understand, why you came up with that
| "as an experienced developer he should know better, than
| to use JavaScript in a WebApp"-comment.
|

You're putting others at risk unnecessarily. For the
most part they don't know it. I try to suggest to people
that they use two browsers -- one with script disabled
for most sites and one with it enabled for cases where
it's absolutely necessary. (Facebook, webmail, etc.)
That's still risky, but not as risky. Unfortunately, a lot
of people can't manage using two browsers. And each
person who creates a website that breaks without script
enabled makes it all the more difficult to help people
minimize risk.

I don't know what "skewered meat" is in an Argentine
steak-house but I think I get the gist of it. If I come
to your house for dinner I'll have to watch your flashy
knife tricks? OK. I trust you. I really do. And it sounds
like great fun. Allright if I watch through the window, from
the front lawn? :)

[ralph]

On Wed, 17 Apr 2013 12:51:22 +0200, Schmidt <n...@vbRichClient.com>
wrote:

>
>Where somebody draws the line, is a personal decision -
>but tolerating the decisions of others, who may draw their
>own personal "risk-line" at a different level, is important
>also ...
>

Websites, or more properly the technologies involved in creating them
are the new Fight Starters.

Over the last ten years or so I've had the opportunity to work with
numerious web developers - from high-quality, top-dollar, true
'artists', to some even worse than me (and trust me - that that is
Bad! <g>) - and it is extremely rare to find anything close to 75%
agreement even among his/her friends. <g>

-ralph

[ralph]

On Wed, 17 Apr 2013 10:06:52 -0400, "Mayayana"
<maya...@invalid.nospam> wrote:


> You're dismissing the whole issue as all-or-nothing
>again. That's very convenient. It makes the issue easy
>for you to ignore and defines me as a reactionary. But it's
>not all-or-nothing.
> As I said earlier, a lot of the problem would be solved
>if people would just accept that executable code is
>risky and be mindful in using it. Don't base all pages on
>script when only one, or maybe none, actually needs it.
>That's all.
>

Valid advice, make that excellent advice. However, as you are aware it
is advice that while is well-known, is equally well-ignored. <g>

-ralph

[Mayayana]

| >
| >Where somebody draws the line, is a personal decision -
| >but tolerating the decisions of others, who may draw their
| >own personal "risk-line" at a different level, is important
| >also ...
| >
|
| Websites, or more properly the technologies involved in creating them
| are the new Fight Starters.
|
| Over the last ten years or so I've had the opportunity to work with
| numerious web developers - from high-quality, top-dollar, true
| 'artists', to some even worse than me (and trust me - that that is
| Bad! <g>) - and it is extremely rare to find anything close to 75%
| agreement even among his/her friends. <g>
|

I don't think many website developers are arguing
over security. For the most part they don't think that
way. They think in terms of functionality and pizzazz.
The differences seem to come between the people
who want it all to work perfectly in all browsers (the
e-commerce types) vs the people who want to require
that you view their site at 1024x768, with specific
versions IE and Flash, and not in direct sunlight
(the "artists").

I had a realtor acquaintance
some time ago whose site was blank without Flash. I
mentioned it to him. He looked puzzled for a moment
and then said, "That's OK. It's supposed to be a high
end website for people with a lot of money, and those
people have high end computers." :)

He had no idea what I was talking about and didn't
care. Clearly his web designer didn't really care either.
He/she was probably a graphic artist trying to make a
beautiful site. It probably was beautiful ...at least on
their Macs.

Another difference developing may be the screen
size emphasis. Karl was recently talking about redoing
his site to accomodate phone visitors. I see that the
other way around: I want my site to be clear, helpful
and functional for all visitors; but people on phones? If
they're visiting my site on a phone it's probably
because they're trying to do too many things at once.
They're busy diddling their phones, in no shape to
concentrate on what they're doing, so I figure there's
no point in spending time catering to them.

[Schmidt]

Am 17.04.2013 16:06, schrieb Mayayana:

[different types of exploits]

> I found an "exploit" that uses CSS along with script to
> check visited links in order to know whether people have
> visited particular sites. CSS isn't really necessary for that
> in most cases. It's just a simple scripting trick that checks
> the color of visited links.
>
> I also found an old bug for IE that wasn't actually CSS.
> Rather, it was a method that uses recursive @import to
> overload IE.
>
> I didn't find anything else.

E.g. on this page:
http://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-124/hasexp-1/Microsoft-IE.html

you'll find two CSS-based vulnerabilities in 2010
(just googled for "CSS exploit IE").

If you go to the general page for the IE-Browser:
http://www.cvedetails.com/product/124/Microsoft-IE.html?vendor_id=26

You get some nice statistics and entry-points, to check the
different issues for different years.

Not sure, if each and every one of all those issues in 2011
2012, 2013 is only relevant in conjunction with "enabled JS".

> And you're hosted by 1and1. So who am I trusting?
> You? Them? Both? What if I get to your site before you
> find an intrusion?

In this case, you're vulnerable of course - (as on any
site you surf-to, before an intrusion was detected there
and properly cleaned up) - with or without enabled
JS (with disabled JS perhaps factor 10 less vulnerable,
but vulnerable still).

> If you can't trust PayPal to keep their site clean then
> who can you trust?

Nobody as it seems - if you put it this way...

But then, on the other hand - there's billions of
(successful) transactions done over all the different
banking-sites world-wide - most of them requiring an
enabled JS-engine in the Browser.

... and so we're back at square one: How much of a risk
is it "reasonable" to take nowadays, whilst surfing
the web?

Sure, there's thousands of users who are f***ed each day,
but on the other hand there's Billions of site-requests, where
no exploits are caused inside the browsers of those, who run
them with enabled JS by default.

> As far as I'm concerned, virtually all sites online are
> at about the same trust level:
> They're generally safe as long as one doesn't enable
> executable code.
> If one does enable it then all bets are off.

And here's perhaps, where we disagree - with your:
"all bets are off" you make it sound like "better not
go outside when it starts raining, because you could
be struck by lightning".
One could be hit of course ... according to wikipedia:
"An estimated 24,000 people are killed by lightning strikes
around the world each year and about 240,000 are injured"
but it's not very probable.
http://en.wikipedia.org/wiki/Lightning_strike

> You're dismissing the whole issue as all-or-nothing
> again. That's very convenient. It makes the issue easy
> for you to ignore and defines me as a reactionary. But it's
> not all-or-nothing.
> As I said earlier, a lot of the problem would be solved
> if people would just accept that executable code is
> risky and be mindful in using it.

I'm not trying to play anything down - there *is* thunderbolts
out there - and in case it's a real thunderstorm, with flashes
going down all over the neighbourhood, then there's perhaps
not many people who go out in this case, taking an unnecessary
risk (in the same way, as most people are aware, that certain
corners of the web are better not entered without "lightning rod").

What I'm saying is - anytime you drive in your car, you're
risking an accident. Then whilst driving, there's of course
a lot of things you can do on your own, to minimize the risk.

All well and fine and as it should be.

But your recommendation, to surf "by default" with a disabled
JS-engine these days, borders on the recommendation, to drive
not faster than 10mph (or use a Bus or a Train - or not use
any vehicle at all, but your feet and the side-walk instead,
to get somewhere...).

Some things just become very uncomfortable, not really doable
anymore, in case you want to minimize the risk to near zero.

> You're putting others at risk unnecessarily. For the
> most part they don't know it.

Oh, come on Maya...
As said further above - most of the online-banking-sites,
which nowadays nearly everybody is using, require an
enabled javascript-engine.

Most users are surfing by default with enabled javascript.

And then on my small experimental site, dedicated to developers,
(with more than "average web-knowledge") I should try to avoid it,
to not put my poor fellow colleagues at risk?
Nahhh... ;-)


> ...each person who creates a website that breaks without

> script enabled makes it all the more difficult to help
> people minimize risk.

As said, IMO "people" already surf by default with enabled
JS these days.
Web-Content is getting more an more dependent on "clientside
dynamics" (avoiding roundtrips over the server-side) - and
JS is the tool, which enables that in your Browser.

In my opinion, switching off JS when-ever possible can't
be the solution in the long run - it's the responsibility
of the Browser-vendors, to make those widely used (and
required) engines more and more bullet-proof, less
vulnerable to attacks.

For my part, I'm eager to see the first Pwn2Own-contest,
which comes up with a Browser-engine which was not hacked in
one way or another. Didn't happen in the last 2013-one, ...

http://www.computerworld.com/s/article/9237446/Pwn2Own_hacking_contest_winds_down_after_paying_a_record_480K

...but I'm sure in a few years Browsers will be hardened enough,
that some vendors won't have to pay any price-money.


Olaf

[Mayayana]

| > I also found an old bug for IE that wasn't actually CSS.
| > Rather, it was a method that uses recursive @import to
| > overload IE.
| >
| > I didn't find anything else.
|
| E.g. on this page:
|
http://www.cvedetails.com/vulnerability-list/vendor_id-26/product_id-124/hasexp-1/Microsoft-IE.html
|
| you'll find two CSS-based vulnerabilities in 2010
| (just googled for "CSS exploit IE").

Yes. One is the recursive @import I mentioned and
the other requires script:

http://technet.microsoft.com/en-us/security/bulletin/MS10-090

Virtually all exploits require script. The recursive @import
doesn't, but that's a browser bug, not a CSS vulnerability.
Since CSS and HTML only specify graphical display details
it's hard to see how they can be directly vulnerable. Script,
on the other hand, is executable code. It's nearly impossible
to make it reasonably safe. (Java and Flash have both
become big problems lately, despite years of claims that
they were safe.) *Executable code is not safe. Period.*

|
| > If you can't trust PayPal to keep their site clean then
| > who can you trust?
|
| Nobody as it seems - if you put it this way...
|
| But then, on the other hand - there's billions of
| (successful) transactions done over all the different
| banking-sites world-wide - most of them requiring an
| enabled JS-engine in the Browser.
|

You were saying that the reasonable
approach is to assign a level of trust to sites and
act accordingly. I'm just pointing out that such an
approach is more hopeful than practical.

| And here's perhaps, where we disagree - with your:
| "all bets are off" you make it sound like "better not
| go outside when it starts raining, because you could
| be struck by lightning".

No. Once again you're trying to cast my position as
all-or-nothing paranoia. All bets are off meant that once
script is involved there's no way to act safely. One can
keep updated with all security patches, run a firewall,
etc. All of that *might* help. But none can make for
dependable safety. The fact that a large percentage of
web pages are safe is a red herring.

| One could be hit of course ... according to wikipedia:
| "An estimated 24,000 people are killed by lightning strikes
| around the world each year and about 240,000 are injured"
| but it's not very probable.
| http://en.wikipedia.org/wiki/Lightning_strike
|

Again, a red herring. We're talking about browser use
online, not lightning strikes. (Though I should probably add
a disclaimer here: I have a brother who installs lightning
protection systems. :)

| But your recommendation, to surf "by default" with a disabled
| JS-engine these days, borders on the recommendation, to drive
| not faster than 10mph

I've never seen you so heated about a topic. I do
nearly all browsing with script blocked. I don't have
Flash or Java installed. I block 3rd-party images and
IFRAMES. While I deal with some ugly pages as a result,
I also avoid most tracking, 3rd-party ads, and risks.
And I don't see 3 videos playing while I'm trying to
read an article. To me those are all plusses.

The only page I regularly visit that requires script is
a TV schedule website. I use Firefox for that and Pale
Moon for all other browsing. I read lots of news and tech.
sites with no problem. I also visit virtually all programming
sites without problem, except for the ones that require
membership, like CodeProject. (One exception is Eduardo
Morcillo's website. His has been a dysfunctional mess of
frivolous script for years.... but he also no longer deals with
VB, so that doesn't really matter.) I occasionally go to Youtube,
but with DownloadHelper I can save a copy of video without
needing to play it or enable script. ...So why in the world
would I add unnecessary risk? (I should add, though, that
I also don't use webmail, Facebook, etc. For some people,
no script would, indeed, mean no Internet.)

| And then on my small experimental site, dedicated to developers,
| (with more than "average web-knowledge") I should try to avoid it,
| to not put my poor fellow colleagues at risk?
| Nahhh... ;-)
|

| Web-Content is getting more an more dependent on "clientside
| dynamics"

I think it's worth getting people to think about these
issues, and you're willing to talk about it. So I pursued
it. But it is, of course, up to you. For my part I'll never
see your website. I'm perfectly happy with an Internet
that works like a magazine with downloads. (And doesn't
require AV, Malwarebytes, or Microsoft's patch drip-feed.)
And to my mind most of what is out there with script and
Flash enabled looks like a garish TV playing the Crazy
Eddie Channel.

I think the future inevitability is the reverse
of the way you see it. Interactivity is heavily hyped and
marketed because it's a lucrative business model. But we
can't keep increasing interactivity and risk in an open
marketplace. There will have to be new security systems
that work privately. And as we head into a world that's
almost entirely electronic, where personal relationships and
reputation count for almost nothing, we're headed into
uncharted territory. If you want to venture into that
thunderstorm it wouldn't hurt to at least put some shoes on.

I saw an interesting comment recently from Ben Affleck
about making Argo. He said that he toured the CIA offices
and saw that each agent had 2 PCs. One for online and one
for internal. And there was an interesting piece on Slashdot
last week about a search engine that can lead to all sorts
of online, unsecured computers, including the controls for
nuclear power plants:

http://search.slashdot.org/story/13/04/09/1828230/the-search-engine-more-dangerous-than-google

This is not a case of increasing Internet interactivity being
inevitable. Rather, it's a case of a relatively new technology
that still has some very big wrinkles to be ironed out; a new
technology that people have been overly cavalier about.

[Deanna Earley]

On 18/04/2013 15:41, Mayayana wrote:
> Virtually all exploits require script. The recursive @import
> doesn't, but that's a browser bug, not a CSS vulnerability.
> Since CSS and HTML only specify graphical display details
> it's hard to see how they can be directly vulnerable. Script,
> on the other hand, is executable code.

Any data input can be vulnerable to buffer overflows, data parsing bugs,
etc.
Script engines just allow more scope to run stuff outside of their control.
(CSS allows the same with browser extensions)

Any script engine allowing something outside of its control is just as
buggy and "insecure" as a buffer overflow in a JPEG or HTML parser, and
equally as likely.

--
Deanna Earley (dee.e...@icode.co.uk)
iCatcher Development Team
http://www.icode.co.uk/icatcher/

iCode Systems

(Replies direct to my email address will be ignored. Please reply to the
group.)

[Mike Williams]

"Mayayana" <maya...@invalid.nospam> wrote in message
news:kkp0gn$65d$1...@dont-email.me...

> *Executable code is not safe. Period.*

So stop creating it. Get your money somewhere else ;-)

[Mayayana]

| > Virtually all exploits require script. The recursive @import
| > doesn't, but that's a browser bug, not a CSS vulnerability.
| > Since CSS and HTML only specify graphical display details
| > it's hard to see how they can be directly vulnerable. Script,
| > on the other hand, is executable code.
|
| Any data input can be vulnerable to buffer overflows, data parsing bugs,
| etc.
| Script engines just allow more scope to run stuff outside of their
control.
| (CSS allows the same with browser extensions)
|

So what are you trying to say? That all risks are
"data input" risks, and CSS is data, so CSS carries
the same risk as script? And by that logic text email
carries the same risk as HTML email? And ActiveX
controls with stolen certificates are exploiting "data
parsing bugs"? And with this logic you also hope to
define script as safe, by defining everything as
equally dangerous? That makes no sense. And this from
the person who always runs with restricted rights
in order to maximize security. Yet you don't concern
yourself with script? Or Java, Flash, or ActiveX, even?

I don't know for sure that it's absolutely impossible
to exploit CSS directly. There could be some oddball
bug like that setting line-height to 1000 and adding
an extra semi-colon exploits a quirky fault in parsing,
I suppose. But so far we have exactly one historic
CSS exploit, which could be called a data parsing bug
(the recursive @import attack in IE), but is not a CSS
parsing bug. CSS serves only to specify graphical layout.
Browsers are designed to ignore any invalid CSS.

Meanwhile, when Microsoft publishes security bulletins
for browser issues, under the category of temporary
fixes they often list disabling or limiting script. I don't
remember ever seeing such a bulletin that suggested
disabling styles. The @import attack and things like the
WMF attack of a few years ago are rare exceptions to
the rule. That doesn't change the fact that nearly all
online attacks -- even those involving other items like
ActiveX, Flash, PDFs, etc. -- require script enabled.

I'm forever amazed by how far people will go to
avoid accepting the simple fact that all of their
convenient online services and interactiveness come
at a price.

[Mike Williams]

"Mayayana" <maya...@invalid.nospam> wrote in message

news:kkpag6$kmr$1...@dont-email.me...

> I'm forever amazed by how far people will go to
> avoid accepting the simple fact that all of their
> convenient online services and interactiveness
> come at a price.

Almost everything you do in life comes at a price, Mayayana. If you lived
your life deliberately avoiding everything that carries a risk then you
might as well curl up and die right now.

Mike

[Deanna Earley]

On 18/04/2013 18:31, Mayayana wrote:
> | > Virtually all exploits require script. The recursive @import
> | > doesn't, but that's a browser bug, not a CSS vulnerability.
> | > Since CSS and HTML only specify graphical display details
> | > it's hard to see how they can be directly vulnerable. Script,
> | > on the other hand, is executable code.
> |
> | Any data input can be vulnerable to buffer overflows, data parsing bugs,
> | etc.
> | Script engines just allow more scope to run stuff outside of their
> control.
> | (CSS allows the same with browser extensions)
> |
>
> So what are you trying to say? That all risks are "data input" risks,
> and CSS is data, so CSS carries the same risk as script? And by that
> logic text email carries the same risk as HTML email?

Yes, any external input is a risk, severity depending on how its used.

> And ActiveX controls with stolen certificates are exploiting "data
> parsing bugs"?

No, that'd be social engineering, both for the people they stole it from
and the users they are lying to.
A stolen certificate again comes down to who you trust.
Most people blind trust the companies that pay Microsoft to be "trusted"
by default.
Have you reviewed your browser's certificate authority store?

> And with this logic you also hope to define script as safe, by
> defining everything as equally dangerous?

I'm not saying they're safe. They are all potential targets, just
varying levels of attack surface.

> And this from the person who always runs with restricted rights in
> order to maximize security. Yet you don't concern yourself with
> script? Or Java, Flash, or ActiveX, even?

Yes I do, but "trust" that the restricted access and keeping everything
up to date, along with common sense reduces (not removes) the threat
target of most issues.

Yes, I have had malware try and run through a not quite up to date Java
runtime which was stopped instantly when it tried asking for elevation.
That meant it only managed to drop a few files in my internet cache, and
not have any chance to go any further.

> I don't know for sure that it's absolutely impossible to exploit CSS
> directly.

You don't know because it's impossible to say.
If there is, then it just means that no one has found it yet.

> There could be some oddball bug like that setting line-height to 1000
> and adding an extra semi-colon exploits a quirky fault in parsing, I
> suppose. But so far we have exactly one historic CSS exploit, which
> could be called a data parsing bug (the recursive @import attack in
> IE), but is not a CSS parsing bug. CSS serves only to specify
> graphical layout.

And in some cases, call out to external scripts/objects.
http://webfx.eae.net/dhtml/pngbehavior/pngbehavior.html

> Browsers are designed to ignore any invalid CSS.

They're also designed to block any script that goes beyond its remit.

> Meanwhile, when Microsoft publishes security bulletins for browser
> issues, under the category of temporary fixes they often list
> disabling or limiting script. I don't remember ever seeing such a
> bulletin that suggested disabling styles. The @import attack and
> things like the WMF attack of a few years ago are rare exceptions to
> the rule. That doesn't change the fact that nearly all online attacks
> -- even those involving other items like ActiveX, Flash, PDFs, etc.
> -- require script enabled.

I'm not saying they exactly the same risk level, just that they are all
a risk to some extent.
As I said above, all external input is a risk.

> I'm forever amazed by how far people will go to avoid accepting the
> simple fact that all of their convenient online services and
> interactiveness come at a price.

Oh, everything comes at a price, you just need to be sensible about how
far you go to cripple your "experience".
The malware above is the only case of (unexpected) infection I've had on
any of my machines on over 2 decades, primarily down to common sense.

[Mayayana]

| > I'm forever amazed by how far people will go to
| > avoid accepting the simple fact that all of their
| > convenient online services and interactiveness
| > come at a price.
|
| Almost everything you do in life comes at a price, Mayayana. If you lived
| your life deliberately avoiding everything that carries a risk then you
| might as well curl up and die right now.
|

Yes, indeed. Perhaps I'm sacrificing too much
for security and privacy. Shall we all meet at
Olaf's house today for some barefoot bungie
jumping in a thunderstorm? :)

[Mayayana]

| > And ActiveX controls with stolen certificates are exploiting "data
| > parsing bugs"?
|
| No, that'd be social engineering, both for the people they stole it from
| and the users they are lying to.
| A stolen certificate again comes down to who you trust.

There's no social engineering at client level. IE defaults
to trusting ActiveX with a valid certificate. Until security
updates are in place, a stolen certificate will be seen as
valid. (There've been several cases of that in the past,
including at least one case where people impersonated
Microsoft to get certificates.)

| Have you reviewed your browser's certificate authority store?
|

No. I don't allow anything that needs such confirmation.
Even if one does, companies neglecting to renew certificates
is very common, so it's become standard practice to accept
outdated certificates. The point being that disallowing risky
code saves me from needing to fiddle with all that.

| Yes, I have had malware try and run through a not quite up to date Java
| runtime which was stopped instantly when it tried asking for elevation.
| That meant it only managed to drop a few files in my internet cache, and
| not have any chance to go any further.

I've never had any kind of malware attack despite no
regular updates and no bloated AV running constant scans.
I'm also not hobbled by restricted permissions requiring
me to deal with countless, inane elevation dialogues.
Yet my approach is paranoid silliness?

Actually I might do the same as you in certain
situations. If I wanted to use online services I'd
probably set up a locked down PC with no important
data on it for that purpose. But in general I don't find
there are online services, requiring script enabled, that
I want to use. If you're a gmailing facebookie who likes
to shop online then it does make sense to have a
dedicated, locekd-down PC that you use for that.

| > I don't know for sure that it's absolutely impossible to exploit CSS
| > directly.
|
| You don't know because it's impossible to say.
| If there is, then it just means that no one has found it yet.
|

| And in some cases, call out to external scripts/objects.
| http://webfx.eae.net/dhtml/pngbehavior/pngbehavior.html
|

That's a nonsensical fishing expedition that has little to do
with CSS. First, it requires using IE, which is unsafe by design.
Second, it loads an ActiveX via Microsoft's own CSS gobbledygook,
which is not recognized by other browsers. (They're loading an
ActiveX object in CSS!) Third, it requires script enabled. Fourth,
it requires enabling binary behaviors in IE -- something which is
itself just more script and should never be enabled in the first
place. ... You're making my case for me. My whole point is that
enabling those things is risky!

I'd be interested to know about any possible, real issues
with CSS. But you and Olaf are trying to dig up very
farfetched *possibilities* of attacks outside of executable
code as a way to make the case that all web content is of
equal risk. You're being irrational in order to hold on to your
premise that disabling script is pointless and unrealistic, at
best.... Which is really trying to hold on to the dream of
"rich" Web services and entertainment with no worries.

[Mike Williams]

"Mayayana" <maya...@invalid.nospam> wrote in message

news:kkrm10$5ua$1...@dont-email.me...

Yeah. And we'll go surfing and swimming and jogging and we'll have a few
drinks and maybe a fat loaded burger. Might even go for a drive or take in a
bit of sailing or yachting or other sport of some kind, perhaps football or
basketball, or we can just go for a walk or do a bit of hill climbing or
potholing or maybe hang gliding or something like that. We should find loads
of nice things to do. Might even cross the road if we are feeling a bit
adventurous. Gotta' keep away from that computer though, especially the
Internet where there are sites using Java Script. No point in taking silly
risks ;-)

Mike

[Larry Serflaten]

Mayayana wrote:
>
> I'm forever amazed by how far people will go to
> avoid accepting the simple fact that all of their
> convenient online services and interactiveness come
> at a price.

It seems to me more of a case of picking your battles.

You write code, so are aware, (keen) to notice the
vulnerabilities present in various forms of code. But
is it really that much to worry about? We are in a world
where risk is rampant; from putting on your socks in the
morning (triggering an allergy) to breakfast cereal (laced
with poison instead of sugar) to walking out the front
door and all the hazards that simple act exposes us to.

I certainly don't know for certain, but you might be limiting
your exposure on the web with due diligence and not give a
second thought to ordering up a plate of food from some
'less than sanitary' kitchen, or other common task that other
people might find frightening if not done 'properly'.

So, I can see your point of view, in fact there are common
sense warnings given out all the time on how to use the web
in a more safe manner, but you might appreciate that in this
one area, your level of acceptable risk lies a bit lower than
the main stream web user. I am just saying that it may be
based in whole or in part on your particular knowledge where
other people might simply regard it as the 'cost of doing
business' so to speak...

LFS

[Mayayana]

| > I'm forever amazed by how far people will go to
| > avoid accepting the simple fact that all of their
| > convenient online services and interactiveness come
| > at a price.
|
|
| It seems to me more of a case of picking your battles.
|
| You write code, so are aware, (keen) to notice the
| vulnerabilities present in various forms of code. But
| is it really that much to worry about? We are in a world
| where risk is rampant; from putting on your socks in the
| morning (triggering an allergy) to breakfast cereal (laced
| with poison instead of sugar) to walking out the front
| door and all the hazards that simple act exposes us to.
|
| I certainly don't know for certain, but you might be limiting
| your exposure on the web with due diligence and not give a
| second thought to ordering up a plate of food from some
| 'less than sanitary' kitchen, or other common task that other
| people might find frightening if not done 'properly'.

I don't see the Web as a special case. Is it paranoid to
pay attention to detail in one's life? There's an old
saying that you wouldn't eat sausage if you saw it made.
That says a lot about human nature and the prevalence of
"the ostrich strategy for a happy life". But there's a further
complication to that in recent times: It takes more to pay
attention to detail as things change quickly. Sausage and
ground meat used to come from the local butcher not so
long ago. Now they come from factories that take in
pallettes of meat scrap from all over the world and put out
packaged food products, often made by illegal immigrants
who are busy just trying to survive. Breakfast cereal is similar.
Factory food. Made *solely* for profit. You have no human
relationship with anyone in the line of production. So why do
you trust them? Does one need to be a crazed paranoiac to
self-educate about that and act accordingly? Does one need
to be in the food industry to think about proper nutrition?
(No, I don't buy Kelloggs or General Mills. Why on earth would I?
Just because they're on the supermarket shelf and on TV? Why
do you see common sense and paying attention as an
exhausting, time-consuming act of fear and paranoia?)

I think I've said what I can to make my point clear,
repeatedly, yet several people have responded as
though blocking script online is equivalent to avoiding
going outside during rainstorms and avoiding all use
of knives. At best, you see my view as excessive
concern resulting from "being in the business".

Yet, oddly, most of the same people who think I'm
overreacting by disabling script will also call me reckless
for not using Windows with extreme restrictions in place;
with AV and Malwarebytes running in the background;
with dozens of needless message windows every day
asking me to approve what I just did; with Windows and
AV going online daily for "critical" updates.

I don't find it terribly inconvenient to disable script online.
More importantly, I don't find it terribly inconvenient to
avoid unnecessary script and plugins on my own website.
I'm just advocating for people to pay attention in web
design because to a great extent the security problems
of executable code online could be avoided.

But as I said to Deanna, I understand that some people
have a very different experience of what the Internet is.
I think part of this issue is connected with that; a growing
divergence in what people do online. If you use Facebook,
Linked-In, webmail, Google maps, etc. then you've already
made a decision -- consciously or not -- that you want those
conveniences regardless of any privacy/security concerns
and that you don't mind being under constant corporate
surveillance. (Maybe you'd rather not know, but you've
accepted it.)

I saw Kara Swisher ask Charlie Rose last night, "When's the
last time you looked at a paper map?!" People like that already
can't imagine survival without constant use of online services,
which requires allowing constant surveillance and some degree
of security risk. For someone like Kara Swisher it will seem rational
for Olaf to liken disabling script to locking oneself indoors. In
fact, for her it would be literally the same thing! She's living in
a radically abstracted e-world.

Me, I know a lot about the inside of the sausage factory.
Some sausage lovers will want to think of me as Chicken
Little as part of their rationale, but the sausage eaters who
want to understand how the sausage is made deserve a little
help. If I were them I'd appreciate that help. :)