Re: TT6: High-quality custom logos and business identities

Re: TT6: High-quality custom logos and business identities

[Richard Cooper]

> Your business lacks visual identity?

No, not really, I think it looks just fine.

> Marketing efforts falling short?

Well, yes...

> Invisible among a sea of competitors?

Definately.

> You're on the right track for a solution - keep reading...

Whoohoo, I thought it was hopeless.

> Our professional designers specialize in the creation of custom logos and business/corporate identities. Our design needs to be seen only once to gain customer attention and recognition. With one of our unique, eye-catching mages you'll never have to introduce yourself twice!

Well, I don't think that's my problem.  You see, what's happened is I've made this awesome little web forum CGI script.  It's like WWWBoard, except that I designed it to prevent spam, you know, stuff like this email.  However, despite it's total awesomeness, and despite the fact that I'm giving it away free, I'm at a loss as to how to make it's existance known to people.  I tried listing it on freshmeat.net, but it's on the last of nine pages, where I know no one will see it because when I went looking for something like it, I got tired of looking once I hit page five and decided it'd be easier to write my own than to find one I liked.  So like you said, I'm invisible among a sea of competitors.  I've got a great easily customizable web forum script and yet everyone's still going over to Matt's Script Archive and downloading WWWBoard, only to find that it mixes up replies now and then, a
  bug that it's had for the last five years.  However, they try to make do, but eventually!
  have  
to shut the thing down because of spam robots.  I have the solution, but I can't think of a way to make it known to people.  It's so frustrating.

> We promise fast turnaround and 100% customer satisfaction. Choose from as any design ideas as necessary, select as many colors as you wish, order any modifications you like, and request any format. Our prices are affordable for any size of business, and get this: there are no hidden fees.

Well, that's nice and all, but I don't think that some new colors are going to fix my problem.  But thanks for your email anyway.

> To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Does anyone still read this list?

I can't help but feel like I'm responsible for all the spam.  A few years ago I was signed up, but I signed up with one email address and kept accidentally sending emails to the list with another address, and so I got those "your message has been queued for approval" messages, and the owner of the list kept getting "would you like to approve this message" emails.  I think he just got tired of dealing with me and set the list up to accept emails from anyone.  So now we have spam.

Anyone know if the owner of linuxassembly.com has resurfaced yet?  Oh, well, nevermind.  I just typed it in and I see it's no longer there.

I wonder where everyone's Assembly in Linux desires went.  This list used to have lots of messages, but I haven't seen anything besides spam lately.

Re: TT6: High-quality custom logos and business identities

[James Colannino]

Richard Cooper wrote:

> Does anyone still read this list?

I'm on the list :)

James
-- 
My blog: http://www.crazydrclaw.com/
My homepage: http://james.colannino.org/

" Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety." --Benjamin Franklin

Re: TT6: High-quality custom logos and business identities

[Steffen Solyga]

Citing James Colannino (Wednesday, 2005/06/29 18:13)...

> Richard Cooper wrote:
> 
> > Does anyone still read this list?
> 
> I'm on the list :)

So we're at least four :-p

Steffen

Re: TT6: High-quality custom logos and business identities

[Hendrik Visage]

On 7/2/05, Steffen Solyga <solyga@absinth.net> wrote:
> Citing James Colannino (Wednesday, 2005/06/29 18:13)...
> 
> > Richard Cooper wrote:
> >
> > > Does anyone still read this list?
> >
> > I'm on the list :)
> 
> So we're at least four :-p

It's always interesting to see questions ;^)

Anycase, Assembly does have it's place, but not necesarily the best
option/choice for any given program/project.

-- 
Hendrik Visage

Re: TT6: High-quality custom logos and business identities

[Frank Kotler]

Steffen Solyga wrote:
> Citing James Colannino (Wednesday, 2005/06/29 18:13)...
>>Richard Cooper wrote:
>>>Does anyone still read this list?
>>
>>I'm on the list :)
> 
> So we're at least four :-p

I'm awake! ... but I don't usually read the ones about high quality 
business logos :)

Anyone noticed anything strange about the newer 2.6 kernels? Gcc, even 
Gas users wouldn't notice it, but some of the very "simple" programs we 
can make with Nasm or Fasm (including the "elfexe" example with Fasm) - 
segfault on new kernels! In the loader, they never even get to run! The 
trick seems to be that you *must* have a writeable section last...

Best,
Frank

Re: TT6: High-quality custom logos and business identities

[Daniel Bonekeeper]

I am also on the list... it's 02:08am and look ! I readed the whole
message... =P
the funniest part is that there is not any URL of the web forum thing
in the whole email... (or Im so sleepy that I missed it.. )

Frank, they still segfaulting even if recompiled under a 2.6 kernel ?

[]'sss
Daniel

-- 
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil

Re: TT6: High-quality custom logos and business identities

[Richard Cooper]

> the funniest part is that there is not any URL of the web forum thing
> in the whole email... (or Im so sleepy that I missed it.. )

I didn't expect anyone to be interested, but if you want to have a look:

http://www.xersedefixion.com/forum/info.html

There's also my linux assembly project:

http://www.xersedefixion.com/softer/

And my assembly but not Linux project:

http://www.xersedefixion.com/sarcasm/

Re: Does anyone still read this list?

[Agner Fog]

Why don't you remove the spammers from this list?

Re: TT6: High-quality custom logos and business identities

[jko]

On 07/01/2005 03:31 pm, Steffen Solyga wrote:

> So we're at least four :-p

Most people just lurk on lists.  I suspect this list has
more than 4 people signed up <grin>.

I'm currently spending a lot of time writting assembly programs
and have a few close to release state.  The file manager (AsmMgr)
has had a major update and the library (AsmLib) has had lots
of bug fixes, it now has over 200 functions.  A disassembler engine
is close to completion.  The disassembler engine is designed for
reverse engineering and speed.  Hopefully it will be fast enough to
iterate over "c" programs and produce nasm source.  I'm hoping it
will identify data areas by brute force itteration.

In other areas the debugger Frank wrote has been a great help
and the latest kdbg now runs without crashing.

So... there is some activity in the assembly arena.  The problem
that probably reduces interest in assembly is lack of entry tools.
It is possible to solve many portability issues with tools and
also reduce the learning curve for new programmers.  At present
our tools are very limited when compared to "c" tools and some
of the IDE programs for other languages.  I wrote a help system
called AsmRef, but it only runs in x-terminals on x86 systems
with kernel 2.4+.  That's pretty limiting.  Oh well...  

I wonder what other programmers think the best path for
assembly portabilty would be?  There are two approaches
I know of:
  
  1. macros to translate kernel calls for each different platform
  2. library calls to interface with the kernel and work with each
      platform.

The macro approach has some additional portability issues but
has been implemented by linuxassembly.org.  HLA uses it's
own unique approach and tries to include some structure to
assembler.  What do assembly programmers want or prefer?

jeff
http://members.save-net.com/jko%40save-net.com/asm/
http://sourceforge.net/projects/asmref
http://sourceforge.net/projects/asmlib
http://sourceforge.net/projects/asmmgr
http://sourceforge.net/projects/asmedit
http://groups.yahoo.com/group/DesktopLinuxAsm

h

Re: TT6: High-quality custom logos and business identities

[Herbert Poetzl]

[zapped]
> Does anyone still read this list?

hmm yeah ...

> I wonder where everyone's Assembly in Linux desires went.

no idea ...

best,
Herbert

Re: TT6: High-quality custom logos and business identities

[Konstantin Boldyshev]

Richard Cooper ?????:

> Anyone know if the owner of linuxassembly.com has resurfaced yet? Oh, 
> well, nevermind. I just typed it in and I see it's no longer there.

Perhaps you've meant linuxassembly.ORG?
Well, I am here, still subscribed..
Still hoping to release new asmutils..
And still lacking time for this.. :(

--
Regards,
Konstantin.

linuxassembly.org - asmutils

[Frank Kotler]

Konstantin Boldyshev wrote:
> Perhaps you've meant linuxassembly.ORG?

What's the story with http://asm.sourceforge.net ? Just a mirror, or is 
there some difference?

...
> Still hoping to release new asmutils..

Great! There are a couple bugs in 0.17...

Makefile - insists on buggy 0.98 to build. Deleting the obvious 
offending lines fixes it. (we apologize for 0.98.37 - elf output was 
badly broken... but 0.98??? Jesus, it won't even assemble its own "test" 
directory!)

truss.asm - "pause" is an instruction nowadays. Speak to Intel, not 
Nasm's fault. I fixed it by changing to "$pause" (two places, IIRC), but 
any change would fix it...

Several of the utilities segfault on 2.6.10+ (this was first brought to 
my attention on 2.6.11, but the patch appears to have been applied to 
2.6.10 - still there in 2.6.12) This applies to those utilities with the 
(only) code section set to "R X", but those with "RWX" still work okay. 
I don't know if the proper fix is to make all code sections writeable 
(last lines in Brian's "elf.inc") or to make sure every program made 
this way has a "UDATASEG"...

Call it a "kernel bug" if you like (I do), but I don't think it's going 
to go away.

What are the security implications of making the code section writeable? 
Is this a "safe" thing to do?

> And still lacking time for this.. :(

So many bits,so little time... :) Huge thanks to you and others involved 
for what you've done. It's a *tremendous* help!

Best,
Frank

Re: linuxassembly.org - asmutils

[Konstantin Boldyshev]

Frank Kotler ?????:

> What's the story with http://asm.sourceforge.net ? Just a mirror, or 
> is there some difference? 

It's the original site. linuxassembly.org is a redirect, actually.

>> Still hoping to release new asmutils..
>
> Great! There are a couple bugs in 0.17...
>
> Makefile - insists on buggy 0.98 to build. Deleting the obvious 
> offending lines fixes it. (we apologize for 0.98.37 - elf output was 
> badly broken... but 0.98??? Jesus, it won't even assemble its own 
> "test" directory!) 

Oh, I guess now the latest 0.98.xx should work fine.. I will remove the 
check.

> truss.asm - "pause" is an instruction nowadays. Speak to Intel, not 
> Nasm's fault. I fixed it by changing to "$pause" (two places, IIRC), 
> but any change would fix it...

Thanks, fixed.

> Several of the utilities segfault on 2.6.10+ (this was first brought 
> to my attention on 2.6.11, but the patch appears to have been applied 
> to 2.6.10 - still there in 2.6.12) This applies to those utilities 
> with the (only) code section set to "R X", but those with "RWX" still 
> work okay. I don't know if the proper fix is to make all code sections 
> writeable (last lines in Brian's "elf.inc") or to make sure every 
> program made this way has a "UDATASEG"...
>
> Call it a "kernel bug" if you like (I do), but I don't think it's 
> going to go away. 

Okay, I'll see how this can be solved. Still haven't tried any 2.6 
kernel :-)

> What are the security implications of making the code section 
> writeable? Is this a "safe" thing to do?

 From a glance, I do not see any point in doing this. However, perhaps
study of linux-kernel archives may clarify why this was done.

>> And still lacking time for this.. :(
>
> So many bits,so little time... :) Huge thanks to you and others 
> involved for what you've done. It's a *tremendous* help! 

Well, we're just having fun... when time permits :-)

--
Regards,
Konstantin.

new asmutils are on the way

[Konstantin Boldyshev]

Hello everyone!

Now that everybody thinks they are dead, here they are... :)

asmutils are switching to the latest nasm (0.98.39 afaik) and will (try to)
use its features, so that version will be required to compile the project.

If there are any contributions, please send them asap (I hope
to release new version during next weekend), but first check
http://linuxassembly.org/asmutils/ChangeLog

-- 
Regards,
Konstantin.

Re: new asmutils are on the way

[Frank Kotler]

Konstantin Boldyshev wrote:
> Hello everyone!

Hi Konstantin!

Big thanks to you and your helpers for asmutils!

> Now that everybody thinks they are dead, here they are... :)

"They" say a lot of stuff is dead! :) Such as Nasm development (we're 
just in low gear!) You know it isn't true - we screwed up some of your 
code! Intel decided "pause" was a good name for an instruction, so Nasm 
added it. "truss.asm" uses (used) "pause" as an identifier... so that's 
broken - along with everybody else who used "pause". Blame Intel for 
that one!

The other thing we did, which breaks existing code, is the addition of 
'\' as a line-continuation character (0.98.25?). Any comment that ends 
with '\' causes the following line to be treated as a comment, too, 
introducing amusing and hard-to-find bugs. This is (they tell me) how 
the C equivalent works, and is "intended behavior". Sorry 'bout that. I 
don't recall if this is an issue with asmutils (I think not).

> asmutils are switching to the latest nasm (0.98.39 afaik) and will (try to)
> use its features, so that version will be required to compile the project.

About the only new "feature" in 0.98.39 is the removal of the 
(exploitable) buffer overruns. Perhaps this should be "required", but as 
a general rule, it would be nice if asmutils would build with "any 
version" (any "reasonable" version...). What new features are you 
actually counting on? I see the "cpu" directive (0.98.8, IIRC)... the 
"-g" switch (this was silently ignored prior to 0.98.37, our "first 
draft" of synbolic debug info - it was *royally* screwed up! You got 
debug info even without the "-g" switch, and it segfaulted at the drop 
of a hat. 0.98.37 was not a suitable version for *any* elf output!

> If there are any contributions, please send them asap (I hope
> to release new version during next weekend), but first check
> http://linuxassembly.org/asmutils/ChangeLog

I don't see any reference in the ChangeLog to "truss.asm" being fixed, 
but the CVS tree shows underscores being added (the day *after* 0.17 was 
released?). That'll fix the "pause" problem.

I've got a couple odds and ends that might be added to os_linux.inc - 
framebuffer stuff related to "VBLANK". It doesn't work on my machine - I 
don't think it's "supposed" to (matrox only?) - so it's untested. Want 
it anyway?

As you know, kernels <2.6.10 (or so) barf if they don't have a writeable 
section last. This affects asmutils that don't have a "UDATASEG". 
Perhaps add one, whether we need it or not, if KERNEL>??? ? Gas gives us 
a .data section, whether we asked for one or not... (towards the end of 
elf.inc, I guess?)

It's the *loader* that segfaults, not our program, when this happens. So 
we can claim it's a "kernel bug" and "not our problem" - but it'd be 
better to fix it. (IMO)

Anything else? That's all I can think of. I'm still a newbie to Linux, 
but I'm getting to know Nasm fairly well, and I'd be delighted to 
discuss any "version-related" problems you encounter. Thanks again for 
asmutils - even if it *were* dead, it'd be a tremendous help!

Best,
Frank

P.S. Here's what I've got. Untested - for "peer review". Can change 'em 
to "%assign", and maybe get a "diff" against 0.17 out of it, if you want...

; struct fb_vblank
struc fb_vblank
   .flags           resd 1    ; FB_VBLANK flags
   .count           resd 1    ; counter of retraces since boot
   .vcount          resd 1    ; current scanline position
   .hcount          resd 1    ; current scandot position
   .reserved        resd 4    ; reserved for future compatibility
endstruc    ; 32 bytes

%define FB_VBLANK_VBLANKING 0x001   ; currently in a vertical blank
%define FB_VBLANK_HBLANKING 0x002   ; currently in a horizontal blank
%define FB_VBLANK_HAVE_VBLANK 0x004 ; vertical blanks can be detected
%define FB_VBLANK_HAVE_HBLANK 0x008 ; horizontal blanks can be detected
%define FB_VBLANK_HAVE_COUNT 0x010  ; global retrace counter is available
%define FB_VBLANK_HAVE_VCOUNT 0x020 ; the vcount field is valid
%define FB_VBLANK_HAVE_HCOUNT 0x040 ; the hcount field is valid
%define FB_VBLANK_VSYNCING 0x080    ; currently in a vsync
%define FB_VBLANK_HAVE_VSYNC 0x100  ; vertical syncs can be detected

Re: new asmutils are on the way

[Konstantin Boldyshev]

Frank Kotler ?????:

> "They" say a lot of stuff is dead! :) Such as Nasm development (we're 
> just in low gear!) You know it isn't true - we screwed up some of your 
> code! 

As they say - "If you break a thing, it indicates that you use it!"

> The other thing we did, which breaks existing code, is the addition of 
> '\' as a line-continuation character (0.98.25?). Any comment that ends 
> with '\' causes the following line to be treated as a comment, too, 
> introducing amusing and hard-to-find bugs. This is (they tell me) how 
> the C equivalent works, and is "intended behavior". Sorry 'bout that. 
> I don't recall if this is an issue with asmutils (I think not). 

No, asmutils are not affected. However I guess DOS/Windows people admire 
this change :-)

> About the only new "feature" in 0.98.39 is the removal of the 
> (exploitable) buffer overruns. Perhaps this should be "required", but 
> as a general rule, it would be nice if asmutils would build with "any 
> version" (any "reasonable" version...). What new features are you 
> actually counting on? I see the "cpu" directive (0.98.8, IIRC)... the 
> "-g" switch (this was silently ignored prior to 0.98.37, our "first 
> draft" of synbolic debug info - it was *royally* screwed up! You got 
> debug info even without the "-g" switch, and it segfaulted at the drop 
> of a hat. 0.98.37 was not a suitable version for *any* elf output! 

They will build with any reasonable nasm (even 0.90 I guess) - as CPU 
directive can be disabled manually.
There will be just a warning suggesting to switch to the particular nasm 
version.

> I've got a couple odds and ends that might be added to os_linux.inc - 
> framebuffer stuff related to "VBLANK". It doesn't work on my machine - 
> I don't think it's "supposed" to (matrox only?) - so it's untested. 
> Want it anyway? 

Okay, I'll add it.

> As you know, kernels <2.6.10 (or so) barf if they don't have a 
> writeable section last. This affects asmutils that don't have a 
> "UDATASEG". Perhaps add one, whether we need it or not, if KERNEL>??? 
> ? Gas gives us a .data section, whether we asked for one or not... 
> (towards the end of elf.inc, I guess?) 

Already fixed - now .bss is forced for KERNEL=26 (only when ELF_MACROS 
are disabled).
Actually this started with 2.6.11 kernel. This is a bug, somone just 
needs to make patch and send it to Linus.

> Anything else? That's all I can think of. I'm still a newbie to Linux, 
> but I'm getting to know Nasm fairly well, and I'd be delighted to 
> discuss any "version-related" problems you encounter. Thanks again for 
> asmutils - even if it *were* dead, it'd be a tremendous help! 

Well, I am still wondering how -On works... If I get it right - it only 
produces
"byte" versions of instructions when possible (and does jump optimization)?

--
Regards,
Konstantin.

Re: new asmutils are on the way

[Frank Kotler]

Konstantin Boldyshev wrote:

...
[line continuation character]
> No, asmutils are not affected. However I guess DOS/Windows people admire 
> this change :-)

:) Well, I know what you mean. But I think Linux programmers might 
appreciate it too, when it comes to...

sys_open myfilename, O_RDRW | O_CREAT | O_TRUNCATE | O_LARGE ...

And X Windows... I think the asm file I possess with the most "\"s in it 
is an X Windows thing. They, too, suffer from "large name for small 
integer" syndrome! :)

...
> There will be just a warning suggesting to switch to the particular nasm 
> version.

That sounds good.

[new kernels]
> Already fixed - now .bss is forced for KERNEL=26 (only when ELF_MACROS 
> are disabled).

Good.

> Actually this started with 2.6.11 kernel. This is a bug, somone just 
> needs to make patch and send it to Linus.

I haven't got his address - you send it to him! :) Seriously, there are 
"channels" for bug reports... First off, what's the desired behavior 
here? Older kernels sent the last section off to be zero-filled, and the 
return from this operation was completely ignored. That isn't very 
sound, and I wouldn't want to argue for a return to it. Perhaps we check 
the flags for the last section, and send it off to be zero-filled only 
if it's intended to be writeable? Or do we need to "remember" the flags, 
make it writeable, zero-fill the end of it, and change the flags back? I 
don't fully understand the purpose of the function that's failing, so I 
don't know how it "should" be fixed. Issuing a better diagnostic than 
SIGSEGV (it was originally SIGKILL, I think) might be some help, but 
AFAIK, those "problem" files *do* fall within the ELF spec...

...
> Well, I am still wondering how -On works... If I get it right - it only 
> produces
> "byte" versions of instructions when possible (and does jump optimization)?

Right. The usage of the "signed byte" form of the instructions that have 
one, when the operand fits, *should* be the default - it is for most 
assemblers - but the original authors, for reasons unknown, made the 
dword (or word) form the default - and documented it so! The only 
program I'm *aware* of that would be bleeped up by changing the defaults 
is Brian's "true.asm"... and *it* would run if it would load, but it won't.

The "-O1" option gives the signed-byte forms where appropriate, but 
doesn't enable the multi-passes needed to do jump displacement 
optimizations. Conditional jumps to "forward" targets are made near, to 
be safe (no "jump out of range" errors). Jumps to targets that have been 
seen are "as needed".

Higher numbers enable that number of "optimization" passes. The original 
code had "-O2" and "-O3" special-cased to 10 and 15 passes (so "-O4" was 
actually less). Somewhere along the line, it was decided that 
special-casing these options was "bad practice" and it was removed. So 
now, you get the number of passes you specify. "-O2" and "-O3" are not 
*nearly* enough. "-O2" (at least) will silently produce bad code!!! The 
workaround to this bug is simply to use a good big number - I use 
"-O999" (when I use "-O" at all) - even bigger wouldn't hurt - it's a 
*maximum* number of extra passes - Nasm stops when it's done. If Nasm 
*can't* resolve all the jump displacements within the number of passes 
you specify, it burps up the "phase error" message. The appearance of 
this message when *any* symbol error occurs is a "bonus"... okay, that's 
a bug, too...

Adding "v" to the parameter - "-O999v" - causes Nasm to report how many 
passes it actually took (not that useful...).

Where asmutils is "hand optimized", it probably isn't much use - 
although you might use it as a "test" to see if Nasm can find anything 
you missed... sometimes finds things *I* miss...

I don't know what lies ahead for the "-O" switch (or when)... maybe 
we'll roll it back to special-case "-O2" and "-O3"... Maybe it should be 
a bit-flag, so you can turn signed-byte and jump displacement on and off 
seperately... No real need that I can see to specify a maximum number of 
passes - if your code doesn't resolve in... however long you're willing 
to wait... just hit control-c. The future's a mystery...

Best,
Frank

Re: new asmutils are on the way

[Konstantin Boldyshev]

Frank Kotler ?????:

>> Actually this started with 2.6.11 kernel. This is a bug, somone just 
>> needs to make patch and send it to Linus.
>
> I haven't got his address - you send it to him! :) Seriously, there 
> are "channels" for bug reports... First off, what's the desired 
> behavior here? Older kernels sent the last section off to be 
> zero-filled, and the return from this operation was completely 
> ignored. That isn't very sound, and I wouldn't want to argue for a 
> return to it. Perhaps we check the flags for the last section, and 
> send it off to be zero-filled only if it's intended to be writeable?

Yes, I think this would be the best solution. AFAIK ELF standard doesn't
force *any* section to be present, and does not force any section order.

But I discovered that ld starting from some version adds empty .bss section
even if was not present in the object file. So, it's also kind of a "fix" :)

> Higher numbers enable that number of "optimization" passes. The 
> original code had "-O2" and "-O3" special-cased to 10 and 15 passes 
> (so "-O4" was actually less). Somewhere along the line, it was decided 
> that special-casing these options was "bad practice" and it was 
> removed. So now, you get the number of passes you specify. "-O2" and 
> "-O3" are not *nearly* enough. "-O2" (at least) will silently produce 
> bad code!!! The workaround to this bug is simply to use a good big 
> number - I use "-O999" (when I use "-O" at all) - even bigger wouldn't 
> hurt - it's a *maximum* number of extra passes - Nasm stops when it's 
> done. If Nasm *can't* resolve all the jump displacements within the 
> number of passes you specify, it burps up the "phase error" message. 
> The appearance of this message when *any* symbol error occurs is a 
> "bonus"... okay, that's a bug, too...
>
> Adding "v" to the parameter - "-O999v" - causes Nasm to report how 
> many passes it actually took (not that useful...).

Thanks, this clarifies a lot of things.
During tests, all asmutils code was assembled in 4-5 passes :-)

>
> Where asmutils is "hand optimized", it probably isn't much use - 
> although you might use it as a "test" to see if Nasm can find anything 
> you missed... sometimes finds things *I* miss... 

Well, of course I would like to get rid of that "optimization macros",
since a macro can just can't handle all cases correctly.

As for jump displacements, I think it's a good idea to turn them on and 
off separately,
for instance add another switch for them with number of passes (-Jn ?). 
Just an idea.

--
Regards,
Konstantin.

asmutils 0.18 released

[Konstantin Boldyshev]

Hello,

asmutils 0.18 are available from http://linuassembly.org/asmutils.html

--
Regards,
Konstantin.

Re: asmutils 0.18 released

[Jan Wagemakers]

Konstantin Boldyshev <konst@linuxassembly.org> schreef:

> asmutils 0.18 are available from http://linuassembly.org/asmutils.html

That should be <http://linuxassembly.org/asmutils.html> ;-)

Great!, I'll take a look at it this weekend. 

Thanks!


-- 
Met vriendelijke groetjes         - Jan Wagemakers -

... I'm normally not a praying man, 
    but if you're up there, please save me Superman.       --Homer Simpson