29
Jun

progeCAD 8.0.18.18 software patch released

progeCAD 8.0.18.18 software patch releasedA new free upgrade for progeCAD Professional 2008 has been released:

Two bugs are fixed:

  • ALE: Fixed a general problem that could cause an error in the ALE library
  • DRAW: Fixed "Snap-From" commandIntelliCAD 6.4 DWG DXF design CAD Software - raster & OLE objects, r/w PDF & 3D…

AutoCAD functionality at less than tenth the cost. DWG DXF PDF read write. Similar icons, commands and interface. Raster image embedding, raster-to-vector software included. DWF publishing, IntelliCAD AutoLISP interpreter, ACIS 3D Solids modelling, temporary point snap (like oSnap), layers, blocks. Hatch, block and xref editing. 3D shading and rendering options. approx. 10000 Symbols library.

27
Jun

CAD Solutions of CAD Civil Engineering Services

CAD Design Services provides CAD diagram for construction of CADConstruction Diagram
The technology of CAD construction implies the development and the implementation of the Autocad designs of the engineers of transport, of expansion of site, hydraulics, environmental, structural and geodetics.
The CAD diagrams of construction facilitate a sequential description of each phase of construction.
more…

23
Jun

CAD Praise from a Rivals

CAD Praise from a rivalsWe don’t normally do this. But I had to laugh when I saw the newest content ad from ailing Chinese Intelligent CAD vendor, CAD. Maybe because they targeted a market outside Australia, they thought we wouldn’t see it here in Sydney.

Some background: CAD Asia-Pacific has been successfully raising awareness about a robust, low-cost AutoCAD Clone Software called progeCAD. One of the messages they have been doing this with for several months now is a paid image ad. This is our ad in question:

They say that imitation is the greatest flattery? Well, here is the new ad from Chinese competitor CAD (RM stands for Malaysian Ringgit, btw):

We first saw this ad at http://www.neofame.com.my/store291007/index.php . It looks like movies, software and patents aren’t the the only thing the Chinese like to pirate :). Judge for yourself.

 

22
Jun

History of CAD: X11 Port to MS-DOS

MS DOS CADMany of you are not possibly aware that CAD is also taking part in various projects. One of those is PythonD, a complete port of the python scripting language to the 32-bit DJGPP development platform for DOS. Another of these projects was a (yet another) failed attempt to port a functional X11 GUI framework to the same environment. A pasted IRC chat from the defunct #djgpp channel tells the story:

me: uhh… about 400K or so I think … somehow
cad: dare I ask how big the exe was?
me: I’m not sure what you propose…
ed: be really cool if it got itself worked directly into a DOS-OS kernel [hint]
me: yeah… if someone wants to play… this would be a fun toy I suppose
ed: could have interesting applications.
me: I have a hello world demo somewhere…
me: worked good
cad: could it actually display the graphics on DOS?
me: yeah
cad: so did the fvwm port somewhat work?
me: nobody had any real time to make a further go of it.
me: I brought it up once on the newsgroup
ed: If others picked up and worked with it…I wonder…
me: k
me: so that’s the story
me: that nobody, including me, could use
me: but new software
me: I realized my X11 port was hardly a port at all
me: or invent a hotkey that toggled between the two with some degree of stability
me: I realized that I would have to completely re-write the tcl-terminal from scratch to use a graphical-pseudo-terminal that co-dispayed inside the GRX session with the applet
me: I realized that I would have to write custom DJGPP-FVWM wrappers around the window applets.
me: but I ran into another snag
me: without requiring some third-party app like desqviewx or something
me: wish.exe running in DOS
me: I was able to finally compile tk-wish

ed: Ok.
me: The Port includes a version of the FVWM windowing manager
me: it took me ages to find his shim
me: The guy doing Kaffe-PC updated the mouse driver for GRX2
me: The DJGPP X11 port was still based on GRX1 IO using the old DJGPP V1 IO queue
me: The mouse IO no longer worked because things moved on to GRX2
me: that meant whiping away the coderot from the DJGPP X11 port
me: The original plan ages ago was to port tkinter
me: I just have 5.4 binaries
me: I didn’t keep it.
cad: can you please send me a source tree?
me: but it’s worth it
cad: or with configure scripts
cad: I’m not great with makefiles
me: that one takes a bit of patience
me: I had to tweak the makefile
me: yeah
cad: the ./configure script never really worked for me
me: dickey.his.com/ncurses/
cad: I had a lot of difficulty getting that to compile, and when it finally did, I got linking errors trying to link a prog with it
cad: btw, how did you port ncurses?
me: yeah
cad: –host=i386-pc-msdosdjgpp –target=i386-pc-msdosdjgpp –build=i386-pc-msdosdjgpp
me: I will not port every darn configure script that assumes I should have a /var or dynamic gcc linking
cad: and sometimes with:
cad: ./configure –prefix=/dev/env/DJDIR –disable-nls –disable-dependency-tracking
me: like hell!
me: the configure script should be ported if it didn’t
cad: I personally use:
me: one longtimer said ./configure should be enough
me: some fealt that some of the arguments were unecessary
ed: thats why god creates make files ;-)
me: the djgpp guys weren’t as enthused
ed: hehe
cad: command.com couldn’t handle that ever :-)
cad: wow
me: y-tracking –disable-libtool-lock –disable-nls –disable-dependency-tracking –disable-largfile
me: ell=bash.exe –disable-largefile –disable-gcc-pipe –enable-tcap-names –without-debug –with-fallbacks=ansi,ansi.sys,ansi80×30,dumb,wyse350,xterm,crt,gnome,vt200,cygwin,djgpp,djgpp204 –without-ada –program-suffix=.exe –without-x –enable-getcap –enable-termcap –enable-warnings –with-termpath=/dev/env/DJDIR/etc/termcap –with-md5-passwords –with-pid-dir=/dev/env/DJDIR/varq –disable-dev-random –disable-shared-handles –disable-dependenc
me: ./configure msdos-i386 –with-static –disable-shared –program-suffix=.exe –prefix=/dev/env/DJDIR –without-pic –bindir=/dev/env/DJDIR/bin –datadir=/dev/env/DJDIR/ –includedir=/dev/env/DJDIR/include –mandir=/dev/env/DJDIR/man –infodir=/dev/env/DJDIR/info –sysconfdir=/dev/env/DJDIR/etc –enable-networking –with-history –with-spooldir=/dev/env/DJDIR/var –disable-libtool-lock –with-pid-dir=/dev/env/DJDIR/var –with-cxx=gpp –with-exec-sh
ed: I may be getting busy around here, and not able to check in as often as I’d like.
me: Some black-porting-magic: I use the following configure command line if it helps:
cad: any other interesting DJGPP ports?
ed: ok.
me: ;-)
me: make install
me: make
me: configure
me: autoconf
me: just make sure the os stuff is right… directory and path deliminators
ed: if u say so.
me: maybe incidentals but porting swig isn’t rocket science
me: No not really
me: I mean
me: pythond
me: I modified the stack space to 2Meg using stubedit
ed: did you have to tweak it to work with PythonD ? swig source
cad: I have a 386
cad: that’s good
me: think so
me: yeah
me: hmmmmm
me: oh
cad: is pythond optimized for just 386?
me: www.swig.org
me: grrrrr….
ed: How big is the Binary?
cad: hey ben
ed: sounds about right.
ed: I’m using the latest version with python.org’s 2.3, 2.4.2
me: Compiled with gpp.exe [i686-pc-msdosdjgpp]
me: University of Chicago
me: Copyright (c) 1998-2003
me: University of Utah and the Regents of the University of California
me: Copyright (c) 1995-1998
me: SWIG Version 1.3.21
ed: which version of Swig is this based on ?
cad: [mcericicq] how about just using reactos or linux?
ed: How..do..I..get..it.
me: I know it works
me: I already use it a lot
ed: s/litt.e/little
ed: Let me test it a litt.e
ed: I’ll except the binary.
me: just too much hassel
ed: THAT I would test and get back to you on.
me: must release source with binary release of any port
me: terms of GPL ARE:
ed: :-)
ed: ok. fine. GIMME!
me: I just use it
me: I don’t support it
ed: gimme! GIMME!
ed: where?
me: already did it
ed: how about a DJGPP port of Swig !!
ed: I love swig. I use Swig with Python 2.3, and 2.4
ed: Oh! I got it!
me: I guess that could be done. Want to do it?
ed: but if it were built-in… since the djgpp port is already kinda unique.
me: TSR-hell was worse than DLL-hell
ed: of course.
me: I refuse to make these packages deppendent on more TSRs than absolutely neccessary
me: someone once suggested a /dev/random TSR available for DOS to improve the security in my GPG port
ed: python with its own scroll-back buffer and recall would be nice.
me: I was just thinking about TSRs
me: they might have some specioal DOS video driver
ed: plot-graphics… like scipy ?
me: and their own CDrom stuff
ed: video?
me: video
me: mouse?
me: maybe something else
me: Packet
ed: whether or not thats compatible with pythond, I have not tested.
me: my users already need LFN
me: please no more TSRs
ed: installing a tsr scroll-back buffer with copy/paste, is handy :)
me: PythonD is just a basic python port that works(for the most part) in DOS
ed: thats my only pet peeve with dos
me: those gooey environments are good for learning anyway
ed: actually… if the lines were number of something, you;d think we could recall previous lines or somehow
ed: pythonwin, if you want win32 extensions and debugging.
me: but I never get new demos, contributions to the code, or even comments
ed: it makes recalling previous lines easier.
me: a few play with the OpenGl stuff I went as far as releasing
ed: I rather like IDLE myself.
ed: you certainly learned alot working on it.
me: real pythond *users* just want basic python shell scripting and socket functionality in DOS
ed: might prove useful someday.
me: I killed the project and archived my X11 stuff, scared someone might ask me to support it
me: only one casually requested tkinter
me: of all the pythond users
me: hey ANYTHING is possible if you are prepared to sacrifice time for it
cad: well, if it worked it’d be great
cad: oh
me: it wasted time
me: not cool
cad: that’d be great
cad: cool
me: which I fooled with once, go as far as having a white screen up, but that is as far as that went
me: itt could prove useful… if tweaked a bit.. for something like the X11 ghostscript driver
me: on the other hand
me: Now
me: sort of defeats the purpose
cad: ic
me: but the true client-server multitasking window-manager you think of with X11 simply isn’t there.
cad: so have you done any other exotic ports?
me: there is a libX11, libfvwm, etc
me: the headers are the same
me: but under the hood, it is *anything* but X11
me: it is, for arguments sake, a DOS windowing environemnt that very much looks like the old days of sunOS 1.x
cad: oh :-)
me: there is NO SOCKET to connect to
me: my DJGPP-X11 is *NOT* a client-server app
me: missing the point here
me: yeeessh
cad: so what about WATT-32 for the socket layer?
me: the shell is called in a fork and signalled remotely using … drum roll… the X11 UNIX socket layer!
cad: but that’s simply the point where it would stop being DOS and start being UNIX
me: the terminal provides a text environment for a shell
cad: a port of GNOME would be cool :-)
me: see in unix
cad: hmm
me: for real-unix
cad: oic
me: couldn’t find any simple enough to port just using fvwm and djgpp functionality. They were all multitasking socket oriented terminals.
cad: and?
cad: or rxvt?
me: I looked at xterm sources
ed: windows 3.11, lol
cad: why not just XTerm?
ed: anyways, I wonder if windows got its start like this?
me: ergo my tkwish port
me: Someone has to write it
ed: hmmm…
ed: single-thread.
ed: it need only display a terminal (ie. console) box.
cad: but it’s single-tasking
me: that was the problem I was trying to describe
cad: GEM is a 16-bit DOS GUI that has lots of progs written for it
me: there is no console support
ed: I’m not as advanced as you two…
me: uh RadSurfer…
cad: or GEM for that matter
cad: well, if you want that then you can use SEAL2 or OzoneGUI
ed: A graphic "dos" (ie. 32-bit console) environment. Cool.
cad: that’s pretty tiny
cad: wow

By the way, for those interested in antiquities, the results of this and related work are kept on sourceforge as part of the uDOS project.

18
Jun

We are playing catch-up in India

We are playing catch-up in IndiaThe $380-million SolidWorks Corporation, part of the French industrial group Dassault Systemes, has started operations in India. The computer-aided design (CAD) company delivers software that helps customers design better products. Jeff Ray, CEO, SolidWorks Corporation, discusses his growth strategy.

more…

11
Jun

AutoCAD Architecture/Architectural Desktop

November is all about Autodesk University (AU)! It’s only two weeks away and in less than that I’ll be on my way there. Excitement is in the air.

There are many changes and new ideas associated with AU this year. They vary from the handouts being handled differently to the Unconference at the Conference. (In my mind I can hear the Uncola CAD commercial from decades past.)

You can visit the Unconference site and read about the idea and sessions scheduled as well as take part in discussions. It is an unconference because it is not an instructor teaching students, but a leader leading a discussion on the particular unconference topic.

more…

04
Jun

AU 07 is Over

What an experience! The surprising thing was really just how fast it went. I found myself sitting at the airport for my flight home and it felt as if I’d just arrived the day before.

Friday I spent the entire morning learning about Windows Vista. Being that I’d never truly seen it, I was happy to be able to expand my knowledge about what I know I need to learn.

The class was very helpful and was professionally done even though it was the last class on the last day. I learned about installation, security, and saw many ins and outs and pros and cons. I’m feeling pretty excited about it now.

more…

01
Jun

Travel Woes

Are you sick of hearing all the media reports about how bad the airlines are or how busy travel is this time of year? I certainly am.

I’m getting ready to leave for Autodesk University on Friday. Why Friday? Well it seemed like it might be the least busy time of the Thanksgiving weekend to travel. Also, that gives me the weekend before AU to see some sites and relax before the big week.

more…