dev-cpp-users Mailing List for Dev-C++

.asm files need an assembler.

the "tools" devpak contains both and assembler and disassembler which
you could try. the assembler will create an object file which the
linker can then use.

Cary


On Wed, 10 Nov 2004 18:45:33 +0100, Pascal <p.t...@ti...> wrote:
> Hello All,
> 
> I will build xvid.dll and vfw.dll,but there are .asm code for
> optimisation to pentium 4.
> How to build with this asm code under devcpp?
> Or how to make .asm a objet file?
> The build in static librairie are ok,but when i will build in dynamic
> librairie there a error compilation [Linker Error].
> 
> Thanks
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Hello All,

I will build xvid.dll and vfw.dll,but there are .asm code for 
optimisation to pentium 4.
How to build with this asm code under devcpp?
Or how to make .asm a objet file?
The build in static librairie are ok,but when i will build in dynamic 
librairie there a error compilation [Linker Error].

Thanks

Hey,

I was wondering if there was a way to define where Dev-Cpp stores all
of the config files.  I am trying to get dev-cpp to run off a flash
drive (which it does), but I have to set the settings on each new
computer I run it on as by deafult dev-cpp looks for these settings
within the c:\documents and settings\  folder.

thanks
Cary

Try again. www.random.org is working!

/Per W

On Tue, 9 Nov 2004, Roger Furer wrote:

> Aloha from Honolulu,
>    My browser (Mozilla) reports that it can't find that web site.  I
> also tried pasting http// ahead of the www, but got the same
> non-result.  Having followed this debate I'm curious.  I hope you can
> post a better URL.
> Mahalo (Thank You),
> Roger Furer
>
> Rob Lawless wrote:
>
> >  I am completely niave to this science of randomness but my college
> > lecturer
> > designed a program to generate true random numbers i am not aware of
> > the ins
> > & outs of how its done basically something to do with atmospheric noise
> > everything is explained on his website
> > www.random.org <http://www.random.org>
> > just thought i would mentions this seeing as you are getting into a pretty
> > heated debate :)
> > & as always have fun!
> > rob
> > ----- Original Message -----
> > From: "Per Westermark" <pw...@ia...
> > <mailto:pw...@ia...>>
> > To: "Aitor Moreno" <ait...@gm... <mailto:ait...@gm...>>
> > Cc: <dev...@li...
> > <mailto:dev...@li...>>
> > Sent: Tuesday, November 09, 2004 8:09 PM
> > Subject: Re: [Dev-C++] true random numbers.
> >
> >
> > > There are already good random number generators with immensely much
> > better
> > > randomnes and immensely much longer sequences making them evilishly hard
> > > to follow.
> > >
> > > With a good entrophy to seed them - some of which I discussed in my
> > > previous mail - even a quite simle application can use good
> > cryptographic
> > > strength random numbers.
> > >
> > > Why invent an octagonal wheel when there are already true round wheels
> > > available out there on the net?
> > >
> > > Let's play a bit with the time() function - even if repeated a large
> > > number of times - doesn't create hardly any entrophy. Let's say you
> > get 10
> > > bits of entrophy for the first call (i.e. a random time within a start
> > > window of 15 minutes). Each following call add an entrophy close to
> > zero.
> > > Let's say that you call time() on average every 60 seconds (2^6
> > > alternatives), which might give you 6 bits of entrophy. To get 256
> > bits of
> > > entrophy (a very lousy entrophy for encryption seed), you then need 40
> > > calls within a 40 minute interval... For real entrophy, you should
> > > probably have at least 1024 or 2048 bits, which in this case
> > translates to
> > > a smapling interval of 150 to 300 minutes.
> > >
> > > Let's then look a bit closer at the above alternative. You have
> > still not
> > > specified how you should manage to make the individual "random" delays
> > > between each time() sample. If this isn't true random (which it can't be
> > > since you haven't even managed to get a real seed yet) and instead
> > > generated by calls to rand() (which is using a known algorithm and
> > have a
> > > very short sequence) then your 6 bits of entrophy for each 60 second
> > > window actually gets multiplied by 0, i.e. you are still at your initial
> > > 10 bits of entrophy from the 15-minute uncertainty of when the first
> > call
> > > was made.
> > >
> > > A large number of people have tried your approach in a number of
> > variants.
> > > Every one of them who have had their results stressed have fallen
> > through,
> > > i.e. the "randomnes" has been quickly shot to pieces.
> > >
> > > We are not talking about world-class cryptographic analysis to pick the
> > > above methods to pieces. More like a suitable programming exercise for
> > > project Euler:
> > >   http://www.mathschallenge.net/index.php?section=project
> > > or maybe a home exercise for some courses at the university.
> > >
> > > - There are no ways to just algorithmically create randomnes.
> > > - There are good random number generators available freely.
> > > - For most environments, entrophy can be picked up from the system.
> > >
> > > Why then bother to try and do something that can't be done? Instead fix
> > > good random generator from the net. Fix reasonably good entrophy
> > from the
> > > system. Mix together and use. Takes less time than even thinking about
> > > inventing some smart methods for "garbling" the rand() sequence.
> > >
> > > time(), srand(), rand() etc are _only_ for selecting which attack a
> > moster
> > > should use, what color a screen saver should display etc. They can
> > not be
> > > used for anything where random quality or preditability (or actually
> > lack
> > > of) is important.
> > >
> > > With time() you get a few bits, but you have to look somewhere else to
> > > collect the rest of the bits to use. In an interactive environment, the
> > > user is a great source of entrophy. Else, you really have to dig in and
> > > look under every stone there is. Only remember that repeating the same
> > > operation twice doesn't double the entrophy. Most of the time it doesn't
> > > give a single bit extra...
> > >
> > > I don't write this to be difficult. It's just that there must be
> > > absolutely no misconception that rand() and time() may be used for
> > > cryptography or other fields where good random numbers and entrophy
> > > are needed.
> > >
> > > Note: more comments inlined below.
> > >
> > > /Per W
> > >
> > > On Tue, 9 Nov 2004, Aitor Moreno wrote:
> > >
> > > > Yes.. I agree with you. Since time() doesn't generate true random
> > > > numbers, with this EASY approach, better results are achieved... do
> > > > you agree with me?
> > >
> > > See comments above - no extra entrophy added.
> > >
> > > > >
> > > > Yes, of course this can happen.... but this introduces a noise in the
> > > > resulting sequence.
> > >
> > > Not noise - as in randomnes. It only adds predictability, i.e. "hooks"
> > > that may be used to figure out what extra code you are using to
> > garble the
> > > rand() function.
> > >
> > > > >
> > > > Obviously... it is like trying to encrypt a java applet.... it is
> > > > impossible, but with all the known techniques, you can make the attack
> > > > more difficult, only for those attacks that know how to do it....
> > > >
> > > > With this easy approach, you can add a real noise to the resulting
> > > > sequence that makes the analysis more difficult... or isn't it??
> > >
> > > As I mentioned above: A lot of people have tried obfuscation. I
> > don't know
> > > about anyone who have managed to survive a real hack attempt.
> > >
> > > > >
> > > > And if it is small set of random numbers, with the proposed function,
> > > > reseeding the sequence, and the interval between successive numbers is
> > > > not trivial....
> > > > do you think that is harder or easier to perform the analysis?
> > >
> > > You need a random generator to make this strategy work. Then, you still
> > > receive entrophy in a real slow way. And in the end, rand() in itself is
> > > too bad to be helped by good entrophy
> > >
> > > > >
> > > > and if it is used only for choose a random color for my background ?
> > > >
> > > > I know what you are comment... and all it is true... the true random
> > > > numbers are difficult to obtain...  And, like the topic was "true
> > > > random numbers", I have to agree with that, because I think in the
> > > > same way .
> > > >
> > > > But, a good approach for easy applications can be the proposed one in
> > > > the first post or in the second one....
> > > >
> > > > In all cryptographic books it is used to appear a chapter about
> > this ...
> > >
> > > A good approach for easy applications that are not limited to selecting
> > > the background color of a window is to pick the code available in these
> > > chapters of the cryptographic books, or to just google for a download
> > > site. Any other design decision either fails or requires extensive
> > > statistics and cryptographics knowledge and may still backfire.
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by:
> > > Sybase ASE Linux Express Edition - download now for FREE
> > > LinuxWorld Reader's Choice Award Winner for best database on Linux.
> > > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> > <http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click>
> > > _______________________________________________
> > > Dev-cpp-users mailing list
> > > Dev...@li...
> > <mailto:Dev...@li...>
> > > TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> > > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> > >
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>

Aloha from Honolulu,
   My browser (Mozilla) reports that it can't find that web site.  I 
also tried pasting http// ahead of the www, but got the same 
non-result.  Having followed this debate I'm curious.  I hope you can 
post a better URL.
Mahalo (Thank You),
Roger Furer

Rob Lawless wrote:

>  I am completely niave to this science of randomness but my college 
> lecturer
> designed a program to generate true random numbers i am not aware of 
> the ins
> & outs of how its done basically something to do with atmospheric noise
> everything is explained on his website
> www.random.org <http://www.random.org>
> just thought i would mentions this seeing as you are getting into a pretty
> heated debate :)
> & as always have fun!
> rob
> ----- Original Message -----
> From: "Per Westermark" <pw...@ia... 
> <mailto:pw...@ia...>>
> To: "Aitor Moreno" <ait...@gm... <mailto:ait...@gm...>>
> Cc: <dev...@li... 
> <mailto:dev...@li...>>
> Sent: Tuesday, November 09, 2004 8:09 PM
> Subject: Re: [Dev-C++] true random numbers.
>
>
> > There are already good random number generators with immensely much 
> better
> > randomnes and immensely much longer sequences making them evilishly hard
> > to follow.
> >
> > With a good entrophy to seed them - some of which I discussed in my
> > previous mail - even a quite simle application can use good 
> cryptographic
> > strength random numbers.
> >
> > Why invent an octagonal wheel when there are already true round wheels
> > available out there on the net?
> >
> > Let's play a bit with the time() function - even if repeated a large
> > number of times - doesn't create hardly any entrophy. Let's say you 
> get 10
> > bits of entrophy for the first call (i.e. a random time within a start
> > window of 15 minutes). Each following call add an entrophy close to 
> zero.
> > Let's say that you call time() on average every 60 seconds (2^6
> > alternatives), which might give you 6 bits of entrophy. To get 256 
> bits of
> > entrophy (a very lousy entrophy for encryption seed), you then need 40
> > calls within a 40 minute interval... For real entrophy, you should
> > probably have at least 1024 or 2048 bits, which in this case 
> translates to
> > a smapling interval of 150 to 300 minutes.
> >
> > Let's then look a bit closer at the above alternative. You have 
> still not
> > specified how you should manage to make the individual "random" delays
> > between each time() sample. If this isn't true random (which it can't be
> > since you haven't even managed to get a real seed yet) and instead
> > generated by calls to rand() (which is using a known algorithm and 
> have a
> > very short sequence) then your 6 bits of entrophy for each 60 second
> > window actually gets multiplied by 0, i.e. you are still at your initial
> > 10 bits of entrophy from the 15-minute uncertainty of when the first 
> call
> > was made.
> >
> > A large number of people have tried your approach in a number of 
> variants.
> > Every one of them who have had their results stressed have fallen 
> through,
> > i.e. the "randomnes" has been quickly shot to pieces.
> >
> > We are not talking about world-class cryptographic analysis to pick the
> > above methods to pieces. More like a suitable programming exercise for
> > project Euler:
> >   http://www.mathschallenge.net/index.php?section=project
> > or maybe a home exercise for some courses at the university.
> >
> > - There are no ways to just algorithmically create randomnes.
> > - There are good random number generators available freely.
> > - For most environments, entrophy can be picked up from the system.
> >
> > Why then bother to try and do something that can't be done? Instead fix
> > good random generator from the net. Fix reasonably good entrophy 
> from the
> > system. Mix together and use. Takes less time than even thinking about
> > inventing some smart methods for "garbling" the rand() sequence.
> >
> > time(), srand(), rand() etc are _only_ for selecting which attack a 
> moster
> > should use, what color a screen saver should display etc. They can 
> not be
> > used for anything where random quality or preditability (or actually 
> lack
> > of) is important.
> >
> > With time() you get a few bits, but you have to look somewhere else to
> > collect the rest of the bits to use. In an interactive environment, the
> > user is a great source of entrophy. Else, you really have to dig in and
> > look under every stone there is. Only remember that repeating the same
> > operation twice doesn't double the entrophy. Most of the time it doesn't
> > give a single bit extra...
> >
> > I don't write this to be difficult. It's just that there must be
> > absolutely no misconception that rand() and time() may be used for
> > cryptography or other fields where good random numbers and entrophy
> > are needed.
> >
> > Note: more comments inlined below.
> >
> > /Per W
> >
> > On Tue, 9 Nov 2004, Aitor Moreno wrote:
> >
> > > Yes.. I agree with you. Since time() doesn't generate true random
> > > numbers, with this EASY approach, better results are achieved... do
> > > you agree with me?
> >
> > See comments above - no extra entrophy added.
> >
> > > >
> > > Yes, of course this can happen.... but this introduces a noise in the
> > > resulting sequence.
> >
> > Not noise - as in randomnes. It only adds predictability, i.e. "hooks"
> > that may be used to figure out what extra code you are using to 
> garble the
> > rand() function.
> >
> > > >
> > > Obviously... it is like trying to encrypt a java applet.... it is
> > > impossible, but with all the known techniques, you can make the attack
> > > more difficult, only for those attacks that know how to do it....
> > >
> > > With this easy approach, you can add a real noise to the resulting
> > > sequence that makes the analysis more difficult... or isn't it??
> >
> > As I mentioned above: A lot of people have tried obfuscation. I 
> don't know
> > about anyone who have managed to survive a real hack attempt.
> >
> > > >
> > > And if it is small set of random numbers, with the proposed function,
> > > reseeding the sequence, and the interval between successive numbers is
> > > not trivial....
> > > do you think that is harder or easier to perform the analysis?
> >
> > You need a random generator to make this strategy work. Then, you still
> > receive entrophy in a real slow way. And in the end, rand() in itself is
> > too bad to be helped by good entrophy
> >
> > > >
> > > and if it is used only for choose a random color for my background ?
> > >
> > > I know what you are comment... and all it is true... the true random
> > > numbers are difficult to obtain...  And, like the topic was "true
> > > random numbers", I have to agree with that, because I think in the
> > > same way .
> > >
> > > But, a good approach for easy applications can be the proposed one in
> > > the first post or in the second one....
> > >
> > > In all cryptographic books it is used to appear a chapter about 
> this ...
> >
> > A good approach for easy applications that are not limited to selecting
> > the background color of a window is to pick the code available in these
> > chapters of the cryptographic books, or to just google for a download
> > site. Any other design decision either fails or requires extensive
> > statistics and cryptographics knowledge and may still backfire.
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Sybase ASE Linux Express Edition - download now for FREE
> > LinuxWorld Reader's Choice Award Winner for best database on Linux.
> > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click 
> <http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click>
> > _______________________________________________
> > Dev-cpp-users mailing list
> > Dev...@li... 
> <mailto:Dev...@li...>
> > TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> > https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
> >

 I am completely niave to this science of randomness but my college =
lecturer
designed a program to generate true random numbers i am not aware of the =
ins
& outs of how its done basically something to do with atmospheric noise
everything is explained on his website
www.random.org
just thought i would mentions this seeing as you are getting into a =
pretty
heated debate :)
& as always have fun!
rob
----- Original Message -----
From: "Per Westermark" <pw...@ia...>
To: "Aitor Moreno" <ait...@gm...>
Cc: <dev...@li...>
Sent: Tuesday, November 09, 2004 8:09 PM
Subject: Re: [Dev-C++] true random numbers.


> There are already good random number generators with immensely much =
better
> randomnes and immensely much longer sequences making them evilishly =
hard
> to follow.
>
> With a good entrophy to seed them - some of which I discussed in my
> previous mail - even a quite simle application can use good =
cryptographic
> strength random numbers.
>
> Why invent an octagonal wheel when there are already true round wheels
> available out there on the net?
>
> Let's play a bit with the time() function - even if repeated a large
> number of times - doesn't create hardly any entrophy. Let's say you =
get 10
> bits of entrophy for the first call (i.e. a random time within a start
> window of 15 minutes). Each following call add an entrophy close to =
zero.
> Let's say that you call time() on average every 60 seconds (2^6
> alternatives), which might give you 6 bits of entrophy. To get 256 =
bits of
> entrophy (a very lousy entrophy for encryption seed), you then need 40
> calls within a 40 minute interval... For real entrophy, you should
> probably have at least 1024 or 2048 bits, which in this case =
translates to
> a smapling interval of 150 to 300 minutes.
>
> Let's then look a bit closer at the above alternative. You have still =
not
> specified how you should manage to make the individual "random" delays
> between each time() sample. If this isn't true random (which it can't =
be
> since you haven't even managed to get a real seed yet) and instead
> generated by calls to rand() (which is using a known algorithm and =
have a
> very short sequence) then your 6 bits of entrophy for each 60 second
> window actually gets multiplied by 0, i.e. you are still at your =
initial
> 10 bits of entrophy from the 15-minute uncertainty of when the first =
call
> was made.
>
> A large number of people have tried your approach in a number of =
variants.
> Every one of them who have had their results stressed have fallen =
through,
> i.e. the "randomnes" has been quickly shot to pieces.
>
> We are not talking about world-class cryptographic analysis to pick =
the
> above methods to pieces. More like a suitable programming exercise for
> project Euler:
>   http://www.mathschallenge.net/index.php?section=3Dproject
> or maybe a home exercise for some courses at the university.
>
> - There are no ways to just algorithmically create randomnes.
> - There are good random number generators available freely.
> - For most environments, entrophy can be picked up from the system.
>
> Why then bother to try and do something that can't be done? Instead =
fix
> good random generator from the net. Fix reasonably good entrophy from =
the
> system. Mix together and use. Takes less time than even thinking about
> inventing some smart methods for "garbling" the rand() sequence.
>
> time(), srand(), rand() etc are _only_ for selecting which attack a =
moster
> should use, what color a screen saver should display etc. They can not =
be
> used for anything where random quality or preditability (or actually =
lack
> of) is important.
>
> With time() you get a few bits, but you have to look somewhere else to
> collect the rest of the bits to use. In an interactive environment, =
the
> user is a great source of entrophy. Else, you really have to dig in =
and
> look under every stone there is. Only remember that repeating the same
> operation twice doesn't double the entrophy. Most of the time it =
doesn't
> give a single bit extra...
>
> I don't write this to be difficult. It's just that there must be
> absolutely no misconception that rand() and time() may be used for
> cryptography or other fields where good random numbers and entrophy
> are needed.
>
> Note: more comments inlined below.
>
> /Per W
>
> On Tue, 9 Nov 2004, Aitor Moreno wrote:
>
> > Yes.. I agree with you. Since time() doesn't generate true random
> > numbers, with this EASY approach, better results are achieved... do
> > you agree with me?
>
> See comments above - no extra entrophy added.
>
> > >
> > Yes, of course this can happen.... but this introduces a noise in =
the
> > resulting sequence.
>
> Not noise - as in randomnes. It only adds predictability, i.e. "hooks"
> that may be used to figure out what extra code you are using to garble =
the
> rand() function.
>
> > >
> > Obviously... it is like trying to encrypt a java applet.... it is
> > impossible, but with all the known techniques, you can make the =
attack
> > more difficult, only for those attacks that know how to do it....
> >
> > With this easy approach, you can add a real noise to the resulting
> > sequence that makes the analysis more difficult... or isn't it??
>
> As I mentioned above: A lot of people have tried obfuscation. I don't =
know
> about anyone who have managed to survive a real hack attempt.
>
> > >
> > And if it is small set of random numbers, with the proposed =
function,
> > reseeding the sequence, and the interval between successive numbers =
is
> > not trivial....
> > do you think that is harder or easier to perform the analysis?
>
> You need a random generator to make this strategy work. Then, you =
still
> receive entrophy in a real slow way. And in the end, rand() in itself =
is
> too bad to be helped by good entrophy
>
> > >
> > and if it is used only for choose a random color for my background ?
> >
> > I know what you are comment... and all it is true... the true random
> > numbers are difficult to obtain...  And, like the topic was "true
> > random numbers", I have to agree with that, because I think in the
> > same way .
> >
> > But, a good approach for easy applications can be the proposed one =
in
> > the first post or in the second one....
> >
> > In all cryptographic books it is used to appear a chapter about this =
...
>
> A good approach for easy applications that are not limited to =
selecting
> the background color of a window is to pick the code available in =
these
> chapters of the cryptographic books, or to just google for a download
> site. Any other design decision either fails or requires extensive
> statistics and cryptographics knowledge and may still backfire.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>