Codewright Failure

Newsgroups are my last ditch resource for bugs with old software. I know Codewright is old and no longer supported. But I have it and I'm not ready to switch. Meanwhile, something happend while I was running in safe mode and now Codewright is messed up when running in standard windows mode.

I can open files, but I can't select anything in them or do any edits. I can't even position the cursor with the mouse. All the great chroma formatting is gone.

Any ideas? Is it finally time to bail on Codewright and switch to Emacs? I tried that once and the initial Emacs screen scared me! It was totally non-intuitive.

--

Rick C
Reply to
rickman
Loading thread data ...

Den torsdag den 16. februar 2017 kl. 23.17.49 UTC+1 skrev rickman:

I like ultraedit but it is not free

Reply to
Lasse Langwadt Christensen

I haven't used Codewright since the 20th century. I use Eclipse. It's free. It's what TI built their Code Composer on.

Reply to
Wanderer

Maybe restore from backup?

(I feel your pain--my fave editor exists only as a 32-bit Linux executable. Sure is great though.)

Cheers

Phil Hobbs

Reply to
pcdhobbs

Eclipse. There's still things that CodeWright could do that Eclipse can't, but it's good enough, it's supported, there's packages out there for language-specific support of nearly every computer language known to man, and it's a solid product.

And, it's free and open source.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

Same here. VERY powerful editor. I don't of any other editor that can match UltraEdit for converting HSpice device libraries to PSpice, etc. ...Jim Thompson

--
| James E.Thompson                                 |    mens     | 
| Analog Innovations                               |     et      | 
 Click to see the full signature
Reply to
Jim Thompson

Slippery typing :-( ...Jim Thompson

--
| James E.Thompson                                 |    mens     | 
| Analog Innovations                               |     et      | 
 Click to see the full signature
Reply to
Jim Thompson

I'm a CW user too. My version is 4.0e from 1996 (Win95 days). Over the past year, I've seen my version having problems starting in 64-bit windows. Occasionally it will self corrupt some of its binaries. I keep a zip file of my entire CW32 tree, basically a known good restore archive. When I suspect a corruption problem, I save the cwright.ini file somewhere else. Then I delete the CW32 directory tree (safer to rename and delete later). Then I unzip my restore archive and copy in the saved cwright.ini file only after I've verified that it's not corrupted too (which hasn't happened yet). Then things always work.

Of course, you might be experiencing a different set of problems. I hope I was able to help.

Now I digress:

My CW seems to have some problem starting with 64 bit windows. It will just freeze on the splash screen. I'd love to know why that happens. Experimenting with various compatibility modes doesn't solve the problem.

CW hates long directory paths and very long file names. I am certain that long names cause internal memory corruption. When it happens, CW reports an out-of-memory error and then disappears. Sometimes after the same stressing, the edit windows show garbage and I need to restart it. I find I need to treat her gently occasionally.

I have a bunch of custom DLLs that I use that makes it hard to switch editors. I haven't found an editor yet that gives me the same productivity I get with CW. A 20 year relationship with an editor is hard to walk away from.

I acknowledge that there are many great editors with many advanced features. But my productivity in keyboard-to-code is always way better with CW.

JJS

Reply to
John Speth

I've got the latest, 7.5. You used to be able to find it on the web because it was orphaned. But it seems someone bought the rights and is selling it for $300+. Not sure who would be buying it, but it was popular with mainframe support people (meaning it was sold with their other tools so they just bought it too) and maybe there are still those who just buy the package in order to support some ancient systems (meaning 20 years old).

If you'd like to update to 7.5, contact me offline. snipped-for-privacy@yahoo.com. I'm in the middle of a web site port... a terrible time for my editor to be down. I may need to dig out my backups.

--

Rick C
Reply to
rickman

I tried 7.5 when it came out. Premia changed the API that custom DLLs would use in that version. It made upgrading impossible for me.

I'm glad to finally find out that somebody else is using ancient CW. I thought I was the only person in the world.

JJS

Reply to
John Speth

Codewright 3.0 is in this ancient software cd bundle in the internet archive.

formatting link

Reply to
Wanderer

Things aren't looking so good for Codewright. I figured my issue was file corruption, so I finally dug up my old laptop disk. I copied the CW directory over to the new laptop and it runs the same. So I guess the problem is in the registry maybe? Anyone know how to figure that out?

--

Rick C
Reply to
rickman

I wonder if the registry is even used with CW 7.5. I know for certain that my older 4.0e version does not touch the registry.

JJS

Reply to
John Speth

Then what else could it be? I found a number of web pages telling you how to uninstall CW including deleting registry entries. But then when I bring up Programs and Features I don't see it at all. Maybe my problem is it has been removed from the registry?

I don't think it is an .ini file problem as it still opens all the files it had open before the problem started.

I would like to work with Emacs, but it seems so hard to learn. I'll give it another go today.

--

Rick C
Reply to
rickman

If the problem is on 64-bit, it could be address space randomization - particularly if you use any home-grown extensions.

You might try turning it off:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\MoveImages=dword:00000000.

and reboot.

But be aware that doing so lessens overall system security and could cause kittens to be harmed.

The latest CW I had was 5.0d. I haven't used it since switching to Win7, but AFAI recall, by default the only use of the registry is for file associations.

I also recall there being an option to put INI settings into the registry rather than a file - but if you didn't do that the CW key was empty (or nearly so - some useless empty subkey).

SlickEdit is [intentionally] very like CW and even has tools to convert CW projects.

formatting link

UltraEdit also is quite similar to CW functionally, though its keyboard bindings are different.

formatting link

If you are willing to go to Emacs - that is learn a new IDE:

Microsoft has released the Visual Studio editor as a stand-alone product. It's cross platform too: available for Windows, Mac or Linux.

formatting link
IMHO, it's much more usable than Eclipse - but take with salt because I often use VisualStudio on Windows anyway.

YMMV, George

Reply to
George Neuner

I'm not big on lessening system security, I would *never* do anything to harm a kitten and I'm not sure what "turning it off" would mean exactly.

I want to work with Linux, even if only on the Raspberry Pi. So I really should get a new editor that runs on both platforms. It's just such a painful thing to do though. It's almost like having body parts replaced (and I did that last summer).

--

Rick C
Reply to
rickman

Address space layout randomization (ASLR) is a guard against some types of memory based exploits - particularly certain types of buffer overruns.

When a process is executed under ASLR, the various segments of the executable - code, data, stack, etc. - are placed at randomly selected locations within the virtual address space of the process. [i.e. 2 (or 3) GB for 32-bit, 2**52 bytes for 64-bit].

Note that ASLR affects only the *virtual* addresses used by program code - physical addresses used by the CPU still are at the whim of VMM page mapping.

If you disable ALSR globally, or an executable doesn't support it (more below), then the OS falls back on contiguous placement of the load segments. [On Windows, ASLR requires that all the program's load segments must be placed dynamically. If any segment needs an absolute address, the program can't use ASLR. If you require ASLR globally (as a policy) then such programs can't be run.]

ASLR makes it unlikely that any two runs of a program will use the same addresses, so the locations of exploitable code (if any) with respect to something a hacker can access - like an I/O buffer - will be different every time the program executes.

On Windows, unless you enable ASLR globally, it affects only those executables that were specifically compiled for it. However, it is the default for 64-bit compilers, and has been available as an option for 32-bit compilers for a long time [since 2002, IIRC]. Most commercial 32-bit software uses it.

The problem with ASLR is that a program may depend on assumptions such as "all heap addresses will be lower than any stack addresses". Under ASLR, these assumptions may be violated: program segments may be located anywhere in the address space.

Or a program may have a bug that is normally hidden, but if by chance ASLR reorders its load segments in a particular way, the seemingly innocuous bug turns into something fatal.

For 32-bit programs, ASLR also can impact sharing memory among multiple processes because a particular needed address range may not always be available. This can affect 64-bit programs too, but the vastly larger address space makes it much more likely that a reasonably sized block can be placed wherever you need it.

On the whole, ASLR is a good thing - but it isn't without warts.

George

Reply to
George Neuner

If you want to work directly with a Pi, get a Pi 3 - the earlier ones are a bit too slow for using as a desktop. (They are great for running specific programs, but it gets painful when it takes a few seconds to open a new large program.) I find it is easier to do most stuff from a PC, and only occasionally edit things directly on a Pi. But that is easier if the desktop is Linux, since it gives you several convenient ways to swap files and work together with the Pi.

So for an editor that works on the Pi, I usually use nano. It is a simple command-line editor - fine for making small fixes, and works well over ssh even on very limited connections. Unlike other popular command-line editors such as vi and emacs, it works as you would expect it to.

As for an editor for Linux and/or Windows, I am afraid you are in trouble - there are vast numbers of them, with a broad range from light and simple to large and complex. They are all somewhat different from Codewright - and it is always hard for a "power user" to switch editors. No matter which editor you pick, you will go through a period where you feel there are missing features, bad layouts, counter-intuitive interfaces, etc., simply because it is not the editor you are so familiar with.

Personally, I use eclipse as my main editor these days, on Linux and Windows. It works well for what I need, I am used to it, and it is by far the most common IDE delivered with microcontroller toolchains. But I would not run it on a Pi, and I fully understand how some people don't like it.

Reply to
David Brown

Another vote for Eclipse, but it is large to huge, depending on how many features are included.

Hardcore Unix people swear by Emacs. It seems to include everything but a kitchen sink.

--

-TV
Reply to
Tauno Voipio

Hardcore unix people are divided into three camps here. Those who live entirely within emacs (including for email, and as their Usenet reader), those who think emacs is the work of the devil and the only real editor is vim, and those who believe there were perfectly usable gui desktops for *nix by the late 1980's, and believe they can give you more productive editors than a 80x40 terminal screen.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.